From oleg_gryb@yahoo.com Sun Aug 1 10:59:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EE003A6994 for ; Sun, 1 Aug 2010 10:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv6jSKRAad-G for ; Sun, 1 Aug 2010 10:59:27 -0700 (PDT) Received: from web37606.mail.mud.yahoo.com (web37606.mail.mud.yahoo.com [209.191.87.89]) by core3.amsl.com (Postfix) with SMTP id 991E53A690F for ; Sun, 1 Aug 2010 10:59:27 -0700 (PDT) Received: (qmail 82382 invoked by uid 60001); 1 Aug 2010 17:59:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280685594; bh=JVgwOoEVofF+lzqXD157L/TxNyJOI7SIHPU1joSJISA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ZSXEanB8fn9HLfLLG9dRxh8z0sOd4R4P8N4vaKMfq4cIjeof40btCTEKdfHhMwEc5yy3sg09WjMdPhVGBrJ0QSGyzsVUjX5r0IEdHqcGDKuzXEoDJBAip2dQqOfWw+D2RWyxsVLJHz+5W1RCm9981UCFs5buXswUTK7uSC87m1Q= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=YuBnBD1kUhZ48fmt4uB7oeii08nJ4L25AlOnS05EfD5RH8CYXCFPnvbD4Ek0CVDv5kZ6xKzoWTPyiWWuaF+szVIQiNPat3uE4MF/bfg5nGCeDPu5rkg8hVcjSV5R0uS7J22r7clEiZGIIaqEzd6Ll5gE3EI9rnL6WUW+UetGl98=; Message-ID: <187812.82146.qm@web37606.mail.mud.yahoo.com> X-YMail-OSG: QZsYAN0VM1n42FAAD63U34jn0gynTsnZod.gYnB061UAyuv xywiNtImgRufiWuppVq0mnNtlFexBekY9YsrzZLmL6mzizyzxhP4R7eUknaF T459Q7SfBqmLHTj4_EwCPr4gwyJ26vjQEd9S59wpVJ7vKhJWizcT9oMBAt63 C21bjRlLGyUIVaFDaqUUqmHcjYY5ncx7z4EFLUAjPAPe8ab8Si_SHUHSjVSv mF5VxoedR0DuTCrAdu8BbBQWsOqEuktMTyXj9XEDHaHbdaJ04HflHvZ6S8pW syoVrxcfLOudZVYsh7DArky48spRrSPYue37u7e941y3189Jzl5anJzdS9kI m33rXHvYKjYJ9oAMXmwySDv4B Received: from [67.119.192.108] by web37606.mail.mud.yahoo.com via HTTP; Sun, 01 Aug 2010 10:59:54 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 Date: Sun, 1 Aug 2010 10:59:54 -0700 (PDT) From: Oleg Gryb To: oauth@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 18:01:06 -0000 I think OAuth 2.0 (http://tools.ietf.org/html/draft-ietf-oauth-v2-10) User Agent profile is not very secure. Please let me know where/if I'm wrong. Let us take a look at step C in Figure 5 : "Redirect URI with access token in fragment." It's written everywhere that one should not really put secrets to a URL. Access token and that URL are all I need to get an access to the protected resource, right? Let us assume that somebody copy/pasted that URL from a web server's access log file or from a Proxy log file and then replayed it 1000 times. If an action behind the protected resource was to buy a book at Amazon, does it mean that a victim will be charged for 1000 books? Also, is there any protection against CSRF or replay attacks in this case? Thanks, Oleg. From mscurtescu@google.com Sun Aug 1 11:52:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C82EB3A6784 for ; Sun, 1 Aug 2010 11:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.81 X-Spam-Level: X-Spam-Status: No, score=-101.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPRJQKb1odyL for ; Sun, 1 Aug 2010 11:52:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 5E9913A681E for ; Sun, 1 Aug 2010 11:52:21 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o71IqmMO024239 for ; Sun, 1 Aug 2010 11:52:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280688768; bh=JV+gC7fr38TXer8SemfJa+BrwPY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=SI0F037kyW3Lh97CJwjDEiZwAYYK57VFMdfwuwef6jc4yLTN5AR4ttHFHFzUtvKi/ V1w8ZEDB4iENYjxiqGDJQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=aZdaAWHMf/WFumNbNidUucr/bvoVEhMknNNf9A8qr7plrla3c/DykSOWAW/wC5MHP fZwiQuB/ZZ5sKAwFww6hQ== Received: from gyg10 (gyg10.prod.google.com [10.243.50.138]) by hpaq7.eem.corp.google.com with ESMTP id o71Iqk0q030233 for ; Sun, 1 Aug 2010 11:52:47 -0700 Received: by gyg10 with SMTP id 10so1359442gyg.33 for ; Sun, 01 Aug 2010 11:52:46 -0700 (PDT) Received: by 10.100.93.7 with SMTP id q7mr5199879anb.116.1280688762124; Sun, 01 Aug 2010 11:52:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.119.15 with HTTP; Sun, 1 Aug 2010 11:52:22 -0700 (PDT) In-Reply-To: <187812.82146.qm@web37606.mail.mud.yahoo.com> References: <187812.82146.qm@web37606.mail.mud.yahoo.com> From: Marius Scurtescu Date: Sun, 1 Aug 2010 11:52:22 -0700 Message-ID: To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 18:52:23 -0000 On Sun, Aug 1, 2010 at 10:59 AM, Oleg Gryb wrote: > I think OAuth 2.0 (http://tools.ietf.org/html/draft-ietf-oauth-v2-10) > User Agent profile is not very secure. Please let me know where/if I'm > wrong. > > Let us take a look at step C in Figure 5 : > > "Redirect URI with access token in fragment." > > It's written everywhere that one should not really put secrets to a > URL. Access token and that URL are all I need to get an access to the > protected resource, right? > > Let us assume that somebody copy/pasted that URL from a web server's > access log file or from a Proxy log file and then replayed it 1000 > times. The fragment is not sent by the browser to the server, so it cannot end up in log files. Marius From oleg_gryb@yahoo.com Sun Aug 1 12:14:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEABE3A6987 for ; Sun, 1 Aug 2010 12:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abb2ojjaWoHs for ; Sun, 1 Aug 2010 12:14:32 -0700 (PDT) Received: from web37605.mail.mud.yahoo.com (web37605.mail.mud.yahoo.com [209.191.87.88]) by core3.amsl.com (Postfix) with SMTP id BC8CA3A67A4 for ; Sun, 1 Aug 2010 12:14:28 -0700 (PDT) Received: (qmail 18556 invoked by uid 60001); 1 Aug 2010 19:14:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280690091; bh=HMHRnTnQBesvGnNRkRYGPwkPNH1ffGsa8g4s7JnAzAQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AN/YtSSXCR5ZrfdD9HK0ehzd4YjtfBiS5+g7LYJ0V+FxthBs8VlV3vvs/sUCxw15Y0uKgch+QRffkIxW/v2W5MDHTRkmsCSFt391owpNHNX5+JdOgJdC/XJ8Yov4Fx28pcs0ugi+OydxzOfDLtKsYyhZsqmZAkQQZyzCQG1drKU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=S0sfmhpdn2gOiIOuJROP30Zp1WCXAhweBbcIpd/4yGJDPvXJcqb3GfvvjEwTTtZbr0HvF0vFdclQOFYLhHmuklqlvg5HMuVr6nU3kP14VcwDeYgAfqgLXt0PxciIXkCHY1C2TizFHqAS8oGUu6sJQnP7NkfY3nvdpDNh2qW0QMA=; Message-ID: <819264.18140.qm@web37605.mail.mud.yahoo.com> X-YMail-OSG: EJH0ty4VM1lkwQiMvmn2EBPnmUsT8ghx_2vpQGthB9ZUTTq y_xS89faFVmPOO3lMWawHr3DDw__JvVen03e16kc6rjASSaPOFoATP4cx369 K4E.zT2fPH9SW.G34ue9eOOyBVf1CF9iTAiMwG5viWkHLKGVB3ePXh6RrkQy 7gOrwR6DLTRw.SoUlQ5P1usVih8UeTeZxNAt2iGIiHemN2n9eN4Ia5CLVmj9 tkDrtLk.xs0mBk6M1WWC578_5WwYZ_6DckE1ZJWkmhURvm9htVl9uICqST9. 6qKlM8IwxFab8xQgkx5IeM7XuOij6Nl2eElzJQvAiTMkzh5wEaWA6ev0CpTC sw69W7s_P2Nmh Received: from [67.119.192.108] by web37605.mail.mud.yahoo.com via HTTP; Sun, 01 Aug 2010 12:14:51 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <187812.82146.qm@web37606.mail.mud.yahoo.com> Date: Sun, 1 Aug 2010 12:14:51 -0700 (PDT) From: Oleg Gryb To: Marius Scurtescu , Oleg Gryb In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 19:14:44 -0000 "Redirect URI" below means HTTP response code 302, right? Will not browser follow? ----- Original Message ---- From: Marius Scurtescu To: Oleg Gryb Cc: oauth@ietf.org Sent: Sun, August 1, 2010 11:52:22 AM Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? On Sun, Aug 1, 2010 at 10:59 AM, Oleg Gryb wrote: > I think OAuth 2.0 (http://tools.ietf.org/html/draft-ietf-oauth-v2-10) > User Agent profile is not very secure. Please let me know where/if I'm > wrong. > > Let us take a look at step C in Figure 5 : > > "Redirect URI with access token in fragment." > > It's written everywhere that one should not really put secrets to a > URL. Access token and that URL are all I need to get an access to the > protected resource, right? > > Let us assume that somebody copy/pasted that URL from a web server's > access log file or from a Proxy log file and then replayed it 1000 > times. The fragment is not sent by the browser to the server, so it cannot end up in log files. Marius From bouiaw@gmail.com Sun Aug 1 12:22:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6206E3A67A4 for ; Sun, 1 Aug 2010 12:22:00 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+cV4J4ZGEIl for ; Sun, 1 Aug 2010 12:21:51 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 13DE93A6784 for ; Sun, 1 Aug 2010 12:21:49 -0700 (PDT) Received: by pwj1 with SMTP id 1so1284571pwj.31 for ; Sun, 01 Aug 2010 12:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SaS6IsQHqRmei73F83r/sk7Sr2djbYSqvZnmYEYdZv0=; b=KorE7eUcc6uC0cPB92QoOvyUGarv/Of9UWuVIxPYKA/GV5bz7ZkjJWzjtkYqsjOjJ4 136hLFE3lADRjqSKnUJBGBFNL1d4dUyjttTmjy+Dg9vFKoyme4BIRfp2kK6v9zw7mfB+ XS53RAjQtFrfczCYA98MH9A6Jx5XEtA17MWFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N5pyNKqVbZrTIPNu1SDSUydZI16ORpNo8Ois5YI+AlDMJaZOaQSRAgdUXDVyyNr7Hn ssX68XQicYnMgy2kEdySnJkb4I0KPhPpAfjduR2DEaCwuOGWQrsUa4dxCvXvMFz4Itto 8P3ygl02PYERiUxXGb1jNGPK7wu+tLNICRUKY= MIME-Version: 1.0 Received: by 10.142.142.1 with SMTP id p1mr4429793wfd.250.1280690536305; Sun, 01 Aug 2010 12:22:16 -0700 (PDT) Received: by 10.142.49.6 with HTTP; Sun, 1 Aug 2010 12:22:16 -0700 (PDT) In-Reply-To: <819264.18140.qm@web37605.mail.mud.yahoo.com> References: <187812.82146.qm@web37606.mail.mud.yahoo.com> <819264.18140.qm@web37605.mail.mud.yahoo.com> Date: Sun, 1 Aug 2010 21:22:16 +0200 Message-ID: From: Bouiaw To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 19:22:02 -0000 Does the redirect with fragment in URL without sending it to the server have been tested with all main browsers ? On Sun, Aug 1, 2010 at 9:14 PM, Oleg Gryb wrote: > "Redirect URI" below means HTTP response code 302, right? Will not browser > follow? > > > > ----- Original Message ---- > From: Marius Scurtescu > To: Oleg Gryb > Cc: oauth@ietf.org > Sent: Sun, August 1, 2010 11:52:22 AM > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > > On Sun, Aug 1, 2010 at 10:59 AM, Oleg Gryb wrote: >> I think OAuth 2.0 (http://tools.ietf.org/html/draft-ietf-oauth-v2-10) >> User Agent profile is not very secure. Please let me know where/if I'm >> wrong. >> >> Let us take a look at step C in Figure 5 : >> >> "Redirect URI with access token in fragment." >> >> It's written everywhere that one should not really put secrets to a >> URL. Access token and that URL are all I need to get an access to the >> protected resource, right? >> >> Let us assume that somebody copy/pasted that URL from a web server's >> access log file or from a Proxy log file and then replayed it 1000 >> times. > > The fragment is not sent by the browser to the server, so it cannot > end up in log files. > > Marius > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From oleg_gryb@yahoo.com Sun Aug 1 12:47:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8667E3A698C for ; Sun, 1 Aug 2010 12:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3eAKW+wASel for ; Sun, 1 Aug 2010 12:47:13 -0700 (PDT) Received: from web37606.mail.mud.yahoo.com (web37606.mail.mud.yahoo.com [209.191.87.89]) by core3.amsl.com (Postfix) with SMTP id EA2073A6782 for ; Sun, 1 Aug 2010 12:47:11 -0700 (PDT) Received: (qmail 39761 invoked by uid 60001); 1 Aug 2010 19:47:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280692054; bh=QqcQgRyrnCSCoZlpUzlHOXwZGPWJne8RoI0Zo/Xv/6U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=DutwgQ5LRxOzqRzXRhoHShScDZSpBzHFZis1zwL5DQulY0Zmt3tT6wbn6mlIlbKPJIsO0Ya5VWHz8a/lITg9VOO0I0eR3KzlkllmOsiUxvS2FlDSWorin8XA4cWZkZBDys8CrbiJycPkzcSaZHvEgKxPlJJoan2+cZ/cViuK0u0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hpByX5YGJnnaajyfJBMzoIdCfmV9+IKRckpRsEKlbByiihvS+gZTC3ywfMW2zRPQ2oUQhwJANyBDPSThAsIb5B4reXH1zkeTFREYly4PJ80CtsK5yA1c6/Xh560fu1GIpiZB5pfpwAJV0xAm11UOpyvXmnUUkSxzfqXbVTdrNvI=; Message-ID: <354834.39147.qm@web37606.mail.mud.yahoo.com> X-YMail-OSG: CEe_5S0VM1ktX3WdveZe.EFn5eyS2D.wqqgsi9gcdAGqFwo 6qxjPAa7nByYqrSwWR3f9UitT9if.VpTDD_oo9sb3JmDRGcQHmcqLFi1.x7A XbMCF4Iiia97mzYuOKFDZrFZ9S9VztAPvJUu5ddnXKnzmEKAiNiX7WJ4oFGK L4NDMjLKVvrxveF2XFLmSNja_5tuZRxRP6wNCAUAQRoXDkOAtjxFqa2GXm_N bkE.05aHUwrLaeEbL.Pv54MOEUXKtgy1sVTtCL5v1VU31szAFVoI.LWjY3f4 hByFqHoBJxmIjivzRbMUnMAT0ZVTq7TZ7KuBjrhnSnRgFA9fP.TYXAPldj8G 6qIlA.NBJPtc- Received: from [67.119.192.108] by web37606.mail.mud.yahoo.com via HTTP; Sun, 01 Aug 2010 12:47:34 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <187812.82146.qm@web37606.mail.mud.yahoo.com> Date: Sun, 1 Aug 2010 12:47:34 -0700 (PDT) From: Oleg Gryb To: Marius Scurtescu , Oleg Gryb In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 19:47:24 -0000 Let me explain my qs a little bit. It's written in the very beginning of section 1.4.2: "typically implemented in a browser using a scripting language such as JavaScript". That phrase, step C and knowledge about how browser redirects are usually implemented made me think that: 1. A server sends a redirect to a browser using something like this in response: HTTP/1.x 301 Moved Permanently Location: http://www.google.com? access_token=123 2. When the browser sees the response, it will go to the URI provided in the Location header without asking any further questions. At want point and how are you going to get rid of access token? ----- Original Message ---- From: Marius Scurtescu To: Oleg Gryb Cc: oauth@ietf.org Sent: Sun, August 1, 2010 11:52:22 AM Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? On Sun, Aug 1, 2010 at 10:59 AM, Oleg Gryb wrote: > I think OAuth 2.0 (http://tools.ietf.org/html/draft-ietf-oauth-v2-10) > User Agent profile is not very secure. Please let me know where/if I'm > wrong. > > Let us take a look at step C in Figure 5 : > > "Redirect URI with access token in fragment." > > It's written everywhere that one should not really put secrets to a > URL. Access token and that URL are all I need to get an access to the > protected resource, right? > > Let us assume that somebody copy/pasted that URL from a web server's > access log file or from a Proxy log file and then replayed it 1000 > times. The fragment is not sent by the browser to the server, so it cannot end up in log files. Marius From mscurtescu@google.com Sun Aug 1 13:02:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DA873A67B4 for ; Sun, 1 Aug 2010 13:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.854 X-Spam-Level: X-Spam-Status: No, score=-104.854 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_URI_EQUALS=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+4DgQOO4xpq for ; Sun, 1 Aug 2010 13:02:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 249D13A6784 for ; Sun, 1 Aug 2010 13:02:12 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o71K2cPj010459 for ; Sun, 1 Aug 2010 13:02:39 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280692959; bh=nZ39Hl+a8vmMk3R9kHl2STHFvBU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=KpbgcKl7uE77hrXYbSmuR12mqlan/29e+ZBR+jQu/BNbGlnMgU4mUQKk2FeKshuBO X0MAJ+lkaprOBx3X+lSaQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=DG8QKm9AmIqZO192aaU4WV0i+mscy17FZQOa5F1z0glky+T3eho43P8Eu1VW01T2W 4xIWntG9YjGA+jLXBoFTg== Received: from ywf7 (ywf7.prod.google.com [10.192.6.7]) by kpbe20.cbf.corp.google.com with ESMTP id o71K2bia025960 for ; Sun, 1 Aug 2010 13:02:37 -0700 Received: by ywf7 with SMTP id 7so1676681ywf.2 for ; Sun, 01 Aug 2010 13:02:37 -0700 (PDT) Received: by 10.100.99.12 with SMTP id w12mr5209404anb.157.1280692957178; Sun, 01 Aug 2010 13:02:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.119.15 with HTTP; Sun, 1 Aug 2010 13:02:17 -0700 (PDT) In-Reply-To: <354834.39147.qm@web37606.mail.mud.yahoo.com> References: <187812.82146.qm@web37606.mail.mud.yahoo.com> <354834.39147.qm@web37606.mail.mud.yahoo.com> From: Marius Scurtescu Date: Sun, 1 Aug 2010 13:02:17 -0700 Message-ID: To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 20:02:14 -0000 On Sun, Aug 1, 2010 at 12:47 PM, Oleg Gryb wrote: > Let me explain my qs a little bit. It's written in the very beginning of = section > 1.4.2: "typically implemented in a browser using a scripting =A0 language= such as > JavaScript". > > That phrase, step C and knowledge about how browser redirects are usually > implemented made me think that: > > 1. A server sends a redirect to a browser using something like this in re= sponse: > > HTTP/1.x 301 Moved Permanently > Location: http://www.google.com? access_token=3D123 The token is in the fragment, not in the query string. The location would look like: Location: http://www.google.com#access_token=3D123 > 2. When the browser sees the response, it will go to the URI provided in = the > Location header without asking any further questions. Based on the above location the browser fetches just: http://www.google.com The page that is returned must have JavaScript code that can extract the fragment (it is still present in the browser address bar) and then either use it direct (I guess the most common case) or send it back to the server. Marius From mscurtescu@google.com Sun Aug 1 13:03:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36D83A69D6 for ; Sun, 1 Aug 2010 13:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.638 X-Spam-Level: X-Spam-Status: No, score=-105.638 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2edDTh+lVAU for ; Sun, 1 Aug 2010 13:03:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A9A0A3A6970 for ; Sun, 1 Aug 2010 13:03:30 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id o71K3v4n011540 for ; Sun, 1 Aug 2010 13:03:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280693037; bh=/OnCVPzJ9PH/cri4hnWB4RTPHJU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=j2ME7PZizaxDm/RdYxCiCqGvkDKlRZ5K8a5LvfpXjt4RK06JtRKz/ZNKDHc+shOhJ h/kdFztRc7agwnlB8Ogaw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=gtFLknuOKvLML45zWm9aAymrQlubr+Z/vR1yTJpry3XG6NLxCcYvaZfnP6lk9hKVO OiWa/t1We0o1nzhkC4W+A== Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by wpaz1.hot.corp.google.com with ESMTP id o71K3uwP009783 for ; Sun, 1 Aug 2010 13:03:56 -0700 Received: by gxk2 with SMTP id 2so1200548gxk.20 for ; Sun, 01 Aug 2010 13:03:56 -0700 (PDT) Received: by 10.100.152.5 with SMTP id z5mr5267524and.197.1280693036182; Sun, 01 Aug 2010 13:03:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.119.15 with HTTP; Sun, 1 Aug 2010 13:03:36 -0700 (PDT) In-Reply-To: References: <187812.82146.qm@web37606.mail.mud.yahoo.com> <819264.18140.qm@web37605.mail.mud.yahoo.com> From: Marius Scurtescu Date: Sun, 1 Aug 2010 13:03:36 -0700 Message-ID: To: Bouiaw Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Oleg Gryb , oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 20:03:31 -0000 On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw wrote: > Does the redirect with fragment in URL without sending it to the > server have been tested with all main browsers ? AFAIK this is how all major browsers behave. Does anyone know otherwise? Browsers that don't respect this? Marius From oleg_gryb@yahoo.com Sun Aug 1 16:18:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEA43A699A for ; Sun, 1 Aug 2010 16:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlK+ePqQgUpj for ; Sun, 1 Aug 2010 16:18:21 -0700 (PDT) Received: from web37601.mail.mud.yahoo.com (web37601.mail.mud.yahoo.com [209.191.87.84]) by core3.amsl.com (Postfix) with SMTP id E3E6B3A693E for ; Sun, 1 Aug 2010 16:18:20 -0700 (PDT) Received: (qmail 74966 invoked by uid 60001); 1 Aug 2010 23:18:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280704724; bh=swRj5GGn8wuOLh1pjVFV9YrmUs3VXnAl/J0TvIWL1lw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aDWjvdnQXISAz7/DBFNjDJpRtEBTuOj7WvMSxw6lAVyyaXC3DGoxY9iG5bumN24PJkLo7xp0Q923y9tnbtCf8xwuMsw0+RSrgGMOdPBbk0+njboRrj7ODuK+Quzs/FdFQ2j1dPG8X05s2oa1IjZLPi8hJFDYu8Q9OwQChAZ9HSg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VAuY1aEZCt1WP3//OikS2Y4mIGj14x9VbE9dVBG3esEdxJ/beorcsgwuRXCVws7VY2H6fMEIx6jR9T+2m1R83jlNmTwyg43AH+gd/GzoESSpsmEGoiTcCm7fcQ8G0M84nddHEvipRLt5RoC+nZ5xwlD2XmNDvoaUaCxFVxFPUNY=; Message-ID: <737718.73496.qm@web37601.mail.mud.yahoo.com> X-YMail-OSG: 68vVHAsVM1mcwGae_.d4yx5sDHnZUAlgYIGZEXxKNw8c4On s9MItzB4VIn2DBnWGKPc1XNBNKg00SlUpvsv8_rCX5kQjoPnwkRK34Sz_Cbv zivu74Il1tgWsAdY37mc12Ma_s6KLvsLVF2b9qiTCEdCktycaSZc3uY4lJIX 8A0_bZ1aLq8jk6SGFxfUE1neJaFXMvEw3hTI7PeOdoD3qvALZxJ0fBhtMTcN xSgUQhKYeWyZT9WWmjVkjws8oIoG9TkM0DpffgtKBCrzH5AGE2m9kCowcvnK ukl6LRapf4_wkirZcg5XpoRA3sMRh_b4KTLsO7Ou3TtpL2NH.LTRGnIp3Ff9 cA5SiNM0.28cG Received: from [67.119.192.108] by web37601.mail.mud.yahoo.com via HTTP; Sun, 01 Aug 2010 16:18:44 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <187812.82146.qm@web37606.mail.mud.yahoo.com> <819264.18140.qm@web37605.mail.mud.yahoo.com> Date: Sun, 1 Aug 2010 16:18:44 -0700 (PDT) From: Oleg Gryb To: Marius Scurtescu , Bouiaw In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 23:18:22 -0000 I'll need to check if it's true for dynamic redirects that use Location header, but right now I can provide an example where JavaScripts are used for redirects in which case access token is send in a URL. Let us assume that you've implemented an endpoint on your authz server as a JSP that populates access token dynamically: After JSP container expanded the variable, the response that browser will see looks as follows: To test the page above, I put it to my local Apache web server and then accessed it using Iceweasel browser. I've used HTTP Live Headers to see all redirects. The trace is below. Please let me know what I'm missing. The last GET has access token in it. http://localhost/red.html GET /red.html HTTP/1.1 Host: localhost User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009032018 Mozilla/3.0.12 (Debian-3.0.12-1) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip HTTP/1.x 200 OK Date: Sun, 01 Aug 2010 23:16:17 GMT Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT Etag: "dfa53-67-48ccb4133b4c0"-gzip Accept-Ranges: bytes Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 110 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html ---------------------------------------------------------- http://www.google.com/#access_token=123 GET / HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009032018 Mozilla/3.0.12 (Debian-3.0.12-1) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost/red.html Cookie: PREF=ID=0f1fa5297d3f9d6a:U=f5ef3a217b0cd5bf:TM=1277864220:LM=1278796823:GM=1:S=j8uhrMH9ofdi5YZo; NID=37=J2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkHOqiMUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd; ; SID=DQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG9_YxNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6cW1gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ; HSID=ASoUGayYF7At1XErl ----- Original Message ---- From: Marius Scurtescu To: Bouiaw Cc: Oleg Gryb ; oauth@ietf.org Sent: Sun, August 1, 2010 1:03:36 PM Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw wrote: > Does the redirect with fragment in URL without sending it to the > server have been tested with all main browsers ? AFAIK this is how all major browsers behave. Does anyone know otherwise? Browsers that don't respect this? Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From oleg_gryb@yahoo.com Sun Aug 1 17:12:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A54D3A68E7 for ; Sun, 1 Aug 2010 17:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0PMOJu18ny1 for ; Sun, 1 Aug 2010 17:12:28 -0700 (PDT) Received: from web37608.mail.mud.yahoo.com (web37608.mail.mud.yahoo.com [209.191.87.91]) by core3.amsl.com (Postfix) with SMTP id D8AAD3A6839 for ; Sun, 1 Aug 2010 17:12:27 -0700 (PDT) Received: (qmail 71470 invoked by uid 60001); 2 Aug 2010 00:12:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280707972; bh=VhEXzJ3PdkvuX4WCcZV7UMMEuounzTal55QqZOV4tBc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UH62OKIf8v8eA2y8ppEmyOP0+IYcsnM2HT1KNsGS8xq1pRXuin7+5tIuVwMUS4Y5w9wsVt8ZdMdgi0H4hhk55VBlBxXx+eM/Uw9Bk4FHmjqPZ8XR15H9hiip+n0ykrPMWUKMKv9tCPGOpZzh0kVGOpRB+bWaNRjtdyk85HmSyxA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tFQvxSi8F7YjMQgUh0J17Zhd32cBVObYaJKbMkMhJvU9l9LqdZ4n2fJxXCDX9qdLa6KfxwCVe8xtsOPR4sFQqFGcOtFcyu5S/+EytJOsFuPUYWp016+LJDrptBr6yZZrdBDJdNT4ppJCJYEsZfSVPY5Fwtq5kyMayR6+37KNe1o=; Message-ID: <43493.71016.qm@web37608.mail.mud.yahoo.com> X-YMail-OSG: oyILmNkVM1nWayoYvFohsvWeANz.DO_YzhLx_OXRZ.U_UeA 7QP2hIAUbOYBoFAdTXPxpfMXVu860KAbxFhEHWmoUy4QZRo6Jaz0kQpr9WSn lTodvxxVwJYAIhMLr8vWSexR7Kt7uPOb_j0qRU2RayYPN6QXkAl8fWkYrqFo P7l5feIE.d7hkI8yA3qMWCW.zWxbzw2g8Ye0aB9uXgHZLcKnUv1HleUiq7xe rN4cKFAjkuQni_zA58z4puglsJSe1omisakaq4N3GvyGckDq11cSVrLplnkN T_tHQy7kSe4wOyYN6RRJK3Duc0.K._zWbkXa9sRpLgjgu Received: from [67.119.192.108] by web37608.mail.mud.yahoo.com via HTTP; Sun, 01 Aug 2010 17:12:51 PDT X-Mailer: YahooMailClassic/11.2.4 YahooMailWebService/0.8.105.279950 Date: Sun, 1 Aug 2010 17:12:51 -0700 (PDT) From: Oleg Gryb To: Marius Scurtescu , Bouiaw MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: oleg@gryb.info List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 00:12:29 -0000 Here is an example with Location header. I don't see URI with access token = been truncated. See Location header generated by JSP and actual redirect th= at browser followed below. red.jsp (Running on local Tomcat): <% String url =3D "http://www.google.com#access_token=3D123"; response.send= Redirect(url); %>=20 Live HTTP headers trace for Iceweasel Browser: http://localhost:8080/red.jsp GET /red.jsp HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/20090= 32018 Mozilla/3.0.12 (Debian-3.0.12-1) Accept: text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 Accept-Language: en-us,en;q=3D0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 302 Moved Temporarily Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=3D236DAD3EA6288BDC6A780CFFFB9F83E2; Path=3D/ Location: http://www.google.com#access_token=3D123 Content-Type: text/html;charset=3DISO-8859-1 Content-Length: 0 Date: Mon, 02 Aug 2010 00:18:01 GMT ---------------------------------------------------------- http://www.google.com/#access_token=3D123 GET / HTTP/1.1 Host: www.google.com --- On Sun, 8/1/10, Oleg Gryb wrote: > From: Oleg Gryb > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > To: "Marius Scurtescu" , "Bouiaw" > Cc: oauth@ietf.org > Date: Sunday, August 1, 2010, 7:18 PM > I'll need to check if it's true for > dynamic redirects that use Location header,=20 > but right now I can provide an example where JavaScripts > are used for redirects=20 > in which case access token is send in a URL. >=20 > Let us assume that you've implemented an endpoint on your > authz server as a JSP=20 > that populates access token dynamically: >=20 > > 'http://www.google.com#access_token=3D<%=3Dvar_with_token%>'"> > > >=20 > After JSP container expanded the variable, the response > that browser will see=20 > looks as follows: >=20 >=20 > > > > >=20 > To test the page above, I put it to my local Apache web > server and then accessed=20 > it using Iceweasel browser. I've used HTTP Live Headers to > see all redirects.=20 > The trace is below. Please let me know what I'm missing. > The last GET has access=20 > token in it. >=20 > http://localhost/red.html >=20 > GET /red.html HTTP/1.1 > Host: localhost > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:1.9.0.7) Gecko/2009032018=20 > Mozilla/3.0.12 (Debian-3.0.12-1) > Accept: > text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7 > Keep-Alive: 300 > Connection: keep-alive > If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT > If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip >=20 > HTTP/1.x 200 OK > Date: Sun, 01 Aug 2010 23:16:17 GMT > Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with > Suhosin-Patch=20 > mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 > Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT > Etag: "dfa53-67-48ccb4133b4c0"-gzip > Accept-Ranges: bytes > Vary: Accept-Encoding > Content-Encoding: gzip > Content-Length: 110 > Keep-Alive: timeout=3D15, max=3D100 > Connection: Keep-Alive > Content-Type: text/html > ---------------------------------------------------------- > http://www.google.com/#access_token=3D123 >=20 > GET / HTTP/1.1 > Host: www.google.com > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:1.9.0.7) Gecko/2009032018=20 > Mozilla/3.0.12 (Debian-3.0.12-1) > Accept: > text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7 > Keep-Alive: 300 > Connection: keep-alive > Referer: http://localhost/red.html > Cookie:=20 > PREF=3DID=3D0f1fa5297d3f9d6a:U=3Df5ef3a217b0cd5bf:TM=3D1277864220:LM=3D12= 78796823:GM=3D1:S=3Dj8uhrMH9ofdi5YZo; > NID=3D37=3DJ2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkHOqi= MUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd; > ;=20 > SID=3DDQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG9_Y= xNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6cW1= gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ; > HSID=3DASoUGayYF7At1XErl >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ----- Original Message ---- > From: Marius Scurtescu > To: Bouiaw > Cc: Oleg Gryb ; > oauth@ietf.org > Sent: Sun, August 1, 2010 1:03:36 PM > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in > OAuth 2.0? >=20 > On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw > wrote: > > Does the redirect with fragment in URL without sending > it to the > > server have been tested with all main browsers ? >=20 > AFAIK this is how all major browsers behave. Does anyone > know > otherwise? Browsers that don't respect this? >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > =A0 =A0 =A0=20 > =0A=0A=0A From eve@xmlgrrl.com Sun Aug 1 17:16:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CEC03A6A03 for ; Sun, 1 Aug 2010 17:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-Z6EqqkrYTs for ; Sun, 1 Aug 2010 17:16:15 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id B748F3A68E7 for ; Sun, 1 Aug 2010 17:16:15 -0700 (PDT) Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o720GfLM024311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Aug 2010 17:16:42 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-970--394192727 From: Eve Maler In-Reply-To: <4C512095.5050802@lodderstedt.net> Date: Sun, 1 Aug 2010 17:16:41 -0700 Message-Id: References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <4C48C116.9000609@lodderstedt.net> <4C4FE913.9030508@lodderstedt.net> <4C512095.5050802@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 00:16:18 -0000 --Apple-Mail-970--394192727 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm not sure if you mean "address" as in "handle", or "address" as in = "uniquely label", but... UMA's first step involves a user-delegated = introduction of a resource server to an authorization server as a = special kind of client of it, using an OAuth2 web server flow with = dynamic client registration as necessary. As part of this overall = process, the resource server can tell the authorization server = specifically which resource URLs are protected thereby (one way to do = this is to wield its just-acquired access token at a protected resource = registration endpoint at the authz server). Access tokens given to = requesters (the real end-of-the-line clients) for accessing these = resources are currently assumed to be given out on a per-resource-server = basis, and each resource is uniquely associated with a single resource = server and uniquely protected by a single authorization server, so there = is no ambiguity. I suppose a resource server namespace could allow for = higher-order aggregation as discussed below but I would personally = prefer baby steps when it comes to the amount of dynamicism we're = already assuming... If you want to follow along with the UMA work, we have floated a number = of spec drafts for these portions of our Step 1, and should shortly = (within a day or so) have a more fleshed-out resource registration draft = ready. We're not just cataloguing the resource URLs, but also the = possible methods for accessing them; our assumption to date, as noted = previously on this list, has been that the simple set of HTTP methods = can get everyone really far -- but mindful of the need in OAuth-land for = arbitrary "space-delimited list of strings" for scope, the current = nascent draft allows for this. Eve On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote: > Eve, >=20 > how does UMA plan to address resource servers during the OAuth = end-user authorization process? >=20 > regards, > Torsten. >=20 > Am 29.07.2010 02:37, schrieb Eve Maler: >>=20 >> Belatedly... Sorry if I sound like a broken record on this, but: = Most of UMA's use involve letting a user introduce their various hosts = (UMA-flavored resource servers) to their single chosen "authorization = manager" (UMA-flavored authorization server), by treating the former as = a dynamically introduced OAuth client of the latter. This sounds an = awful lot like the question originally posed in this thread. We have = exactly the problem of figuring out how the host can tell the AM what = resources the AM should be protecting and what can be done to them, = which we've begun to solve with what we're calling a "resource = registration API" (RRAPI). >>=20 >> (BTW, we're also working on an I-D to submit here that proposes a = solution for discovery/dynamic registration that meets our needs. Hoping = it can feed into Eran's discovery work.) >>=20 >> Eve >>=20 >> On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote: >>=20 >>> thanks for sharing your thoughts. >>>=20 >>> Differentiating resource servers by using different end-user = authorization endpoint URLs is an option. I dont't know how this will = work in conjunction with discovery, especially since this = differentiation might by required on other endpoints, too. For example, = if a client wants to obtain an access token for the end-user's = credentials, it has to identify the resource server also on the tokens = endpoint. There might be additional endpoint for other flows with = similar requirements, e.g. the device flow. >>>=20 >>> Based on your proposal, a derived solution could be to define a = standard parameter "resourceserver" and to state how clients should use = this parameter on the different endpoints. On the coding level, there = would be no difference to your proposal :-) But the client would be able = to construct such a URL on its own. >>>=20 >>> Authorizing access for different resource servers is indeed an issue = for me. How would you propose to add the namespace? Shall the scope = obtained from the resource server already contain such a namespace are = shall there be a rule to construct such namespaced-ed scopes in the = spec? >>>=20 >>> regards, >>> Torsten. >>>=20 >>> Am 25.07.2010 19:11, schrieb Andrew Arnott: >>>>=20 >>>> It seems to me that if one auth server can create tokens for a = diverse set of resource servers, then why not have different user = authorization endpoint URLs for each type of resource server, as an = added differentiator for the scope (a namespace, if you will)? >>>>=20 >>>> So suppose one auth server serves two different photo services, = both using overlapping scopes such that a client requesting access of = some scope is otherwise ambiguous between which resource server the = client needs access to. The auth server that serves both resource = servers could have two end user authorization endpoints: >>>> http://auth.server.org/authorize?resourceserver=3D1 >>>> http://auth.server.org/authorize?resourceserver=3D2 >>>>=20 >>>> And that way the auth server knows exactly what the client needs. >>>>=20 >>>> The only scenario this doesn't allow for is for a user to authorize = a client's access to both resource servers in one redirect. If this = were an issue, perhaps you can apply a namespace-like prefix to each = scope substring: >>>>=20 >>>> rs1:photo:read rs2:photo:read >>>>=20 >>>> Which would serve a similar purpose. >>>>=20 >>>> -- >>>> Andrew Arnott >>>> "I [may] not agree with what you have to say, but I'll defend to = the death your right to say it." - S. G. Tallentyre >>>>=20 >>>>=20 >>>> On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt = wrote: >>>> no one else in the group having an opinion on this topic? >>>>=20 >>>>=20 >>>>=20 >>>> Am 15.07.2010 20:14, schrieb Marius Scurtescu: >>>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt >>>> wrote: >>>> As I have written in my reply to Marius's posting. I'm fine with = including >>>> server ids in scopes. But this requires a definition of the scope's = syntax >>>> and semantics in the spec. Otherwise, scope interpretation (and = server >>>> identification) will be deployment specific. >>>> Sure, it is deployment specific, but why is that an issue? >>>>=20 >>>> In your case, the authz server and all the resource servers are >>>> managed by the same organization, right? >>>>=20 >>>> Do clients need to be aware of the actual resource server? >>>>=20 >>>> You can probably create a separate spec that defines scope syntax = for >>>> this purpose, if really needed. Does it have to be in core? >>>>=20 >>>> Marius >>>>=20 >>>> Solving the challenge I described in a deployment specific way is = not an issue. But the consequence is that authz server, resource servers = and clients are tight together. >>>>=20 >>>> Let me ask you one question: Why are we working together towards a = standard protocol? I can tell you my expectations: I hope there will be = broad support not only by libraries, but also by ready-to-use services = and clients, so we could integrate such services into our deployment = easily. Moreover, I would like to see OAuth to be included in = application/service protocols like PortableContacts, SIP, WebDAV, IMAP, = ... >>>>=20 >>>> So what if I would like to use standard clients to access our = services? Using scopes for specifying resource server id's in this case = is also simple - if you take an isolated view. But since scopes may be = used to specifiy a lot of other things, like resources, permissions, and = durations, handling w/o a more detailed spec will in practice be = impossible. >>>>=20 >>>> Suppose a WebDAV service for media data access. Any WebDAV client = knows the WebDAV protocol (=3D=3D interface), e.g. the supported methods = (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So = it is sufficient to configure the client with the URL of my personal web = storage. To start with let's assume, scopes are used to designate = resource servers only. So the server's scope could be "webstorage". >>>>=20 >>>> WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage" >>>>=20 >>>> The client could just pass this parameter to the authz server and = everything is fine. >>>>=20 >>>> On the next level, let's assume the (future) WebDAV standard with = OAuth-support uses one permission per method type. So the full scope = could be as follows: >>>>=20 >>>> WWW-Authenticate OAuth realm=3D'webstorage' = scope=3D"webstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE = webstorage:COPY webstorage:MOVE" >>>>=20 >>>> Passing this scope w/o any unmodified to the authz server is not an = issue. But this implies the client asks for full access to the users = media storage. Since our client is a gallery application, it requires = the "GET" permission only. How does the client know which of the scope = values to pick for the end-user authorization process? It must somehow = select "webstorage:GET". >>>>=20 >>>> But how? >>>>=20 >>>> In my personal opinion, clients should be enabled to interpret, = combine and even create scopes. And yes, this should go to the core of = the spec. >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> Eve Maler >> http://www.xmlgrrl.com/blog >> http://www.twitter.com/xmlgrrl >> http://www.linkedin.com/in/evemaler >>=20 Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler --Apple-Mail-970--394192727 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

If you want to follow along = with the UMA work, we have floated a number of spec drafts for these portions of our Step 1, and should = shortly (within a day or so) have a more fleshed-out resource = registration draft ready. We're not just cataloguing the resource URLs, = but also the possible methods for accessing them; our assumption to = date, as noted previously on this list, has been that the simple set of = HTTP methods can get everyone really far -- but mindful of the need in = OAuth-land for arbitrary "space-delimited list of strings" for scope, = the current nascent draft allows for = this.

Eve

On 28 Jul = 2010, at 11:32 PM, Torsten Lodderstedt wrote:

Eve,

how does UMA plan to address resource servers during the OAuth end-user authorization process?

regards,
Torsten.

Am 29.07.2010 02:37, schrieb Eve Maler:
Belatedly...  Sorry if I sound like a broken record on this, but: Most of UMA's use involve letting a user introduce their various hosts (UMA-flavored resource servers) to their single chosen "authorization manager" (UMA-flavored authorization server), by treating the former as a dynamically introduced OAuth client of the latter. This sounds an awful lot like the question originally posed in this thread. We have exactly the problem of figuring out how the host can tell the AM what resources the AM should be protecting and what can be done to them, which we've begun to solve with what we're calling a "resource registration API" (RRAPI).

(BTW, we're also working on an I-D to submit here that proposes a solution for discovery/dynamic registration that meets our needs. Hoping it can feed into Eran's discovery work.)

= Eve

On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:

thanks for sharing your thoughts.

Differentiating resource servers by using different end-user authorization endpoint URLs is an option. I dont't know how this will work in conjunction with discovery, especially since this differentiation might by required on other endpoints, too. For example, if a client wants to obtain an access token for the end-user's credentials, it has to identify the resource server also on the tokens endpoint. There might be additional endpoint for other flows with similar requirements, e.g. the device flow.

Based on your proposal, a derived solution could be to define a standard parameter "resourceserver" and to state how clients should use this parameter on the different endpoints. On the coding level, there would be no difference to your proposal :-) But the client would be able to construct such a URL on its own.

Authorizing access for different resource servers is indeed an issue for me. How would you propose to add the namespace? Shall the scope obtained from the resource server already contain such a namespace are shall there be a rule to construct such namespaced-ed scopes in the spec?

regards,
Torsten.

Am 25.07.2010 19:11, schrieb Andrew Arnott:
It seems to me that if one auth server can create tokens for a diverse set of resource servers, then why not have different user authorization endpoint URLs for each type of resource server, as an added differentiator for the scope (a namespace, if you will)?

So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to.  The auth server that serves both resource servers could have two end user authorization endpoints:

And that way the auth server knows exactly what the client needs.

The only scenario this doesn't allow for is for a user to authorize a client's access to both resource servers in one redirect.  If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring:

rs1:photo:read rs2:photo:read

Which would serve a similar purpose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Thu, Jul 22, 2010 at 3:07 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
<torsten@lodderstedt.net>  wrote:
As I have written in my reply to Marius's posting. I'm fine with including
server ids in scopes. But this requires a definition of the scope's syntax
and semantics in the spec. Otherwise, scope interpretation (and = server
identification) will be deployment specific.
Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax = for
this purpose, if really needed. Does it have to be in core?

Marius

Solving the challenge I described in a deployment specific way is not an issue. But the consequence is that authz server, resource servers and clients are tight together.

Let me ask you one question: Why are we working together towards a standard protocol? I can tell you my expectations: I hope there will be broad support not only by libraries, but also by ready-to-use services and clients, so we could integrate such services into our deployment easily. Moreover, I would like to see OAuth to be included in application/service protocols like PortableContacts, SIP, WebDAV, IMAP, ...

So what if I would like to use standard clients to access our services? Using scopes for specifying resource server id's in this case is also simple - if you take an isolated view. But since scopes may be used to specifiy a lot of other things, like resources, permissions, and durations, handling w/o a more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV client knows the WebDAV protocol (=3D=3D interface), e.g. the supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is sufficient to configure the client with the URL of my personal web storage. To start with let's assume, scopes are used to designate resource servers only. So the server's scope could be "webstorage".

   WWW-Authenticate OAuth realm=3D'webstorage' = scope=3D"webstorage"

The client could just pass this parameter to the authz server and everything is fine.

On the next level, let's assume the (future) WebDAV standard with OAuth-support uses one permission per method type. So the full scope could be as follows:

   WWW-Authenticate OAuth realm=3D'webstorage' = scope=3D"webstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY webstorage:MOVE"

Passing this scope w/o any unmodified to the authz server is not an issue. But this implies the client asks for full access to the users media storage. Since our client is a gallery application, it requires the "GET" permission only. How does the client know which of the scope values to pick for the end-user authorization process? It must somehow select "webstorage:GET".

But how?

In my personal opinion, clients should be enabled to interpret, combine and even create scopes. And yes, this should go to the core of the = spec.

regards,
Torsten.




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

_______________________________________________
OAuth mailing 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-970--394192727-- From recordond@gmail.com Sun Aug 1 17:23:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2213E3A6A6D for ; Sun, 1 Aug 2010 17:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.003 X-Spam-Level: X-Spam-Status: No, score=-1.003 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_47=0.6, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4uCSFrqQqMP for ; Sun, 1 Aug 2010 17:23:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 679403A6A65 for ; Sun, 1 Aug 2010 17:23:46 -0700 (PDT) Received: by iwn38 with SMTP id 38so3746866iwn.31 for ; Sun, 01 Aug 2010 17:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6PkjX75MW9Sv9eIldI9PdN5GtxkWgqLyKhB3boPAorE=; b=hBvyv9ugrMuNxp/2YKHt4Jk2qZkq1UHC8DMoGcBi0FrO2FVE7Q3Hx8o9V5igDxZ1Jo 2Hp/xI6JMewP3KvY5srFJ1I7wfIzoYdHRKDGA5NGSUiQVi5ZeCGRz1nzX75K7D7KGIc3 QQxmS4z206tzOAA9nkeGVHDZ5VGq4LRnHGiQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sa2xiURTK/FDVExhb45/iICn2WoNT1szyqgsyS70exZEsWJLZjadldi3FIQPfZZYgL 6jDYJ8+f/VCzc4/4QSTX2pS9Ia7VdGARswBH0eTujezq4qXDvTt1rycKVcD9NmYd/xru Ik1cDZRbJLN1EU2ycZJc0L0xOsTPFDnwKJWP4= MIME-Version: 1.0 Received: by 10.231.145.1 with SMTP id b1mr6171353ibv.69.1280708653265; Sun, 01 Aug 2010 17:24:13 -0700 (PDT) Received: by 10.231.174.2 with HTTP; Sun, 1 Aug 2010 17:24:13 -0700 (PDT) In-Reply-To: <43493.71016.qm@web37608.mail.mud.yahoo.com> References: <43493.71016.qm@web37608.mail.mud.yahoo.com> Date: Sun, 1 Aug 2010 17:24:13 -0700 Message-ID: From: David Recordon To: oleg@gryb.info Content-Type: multipart/alternative; boundary=001485eba79856b2aa048ccc382d Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 00:23:48 -0000 --001485eba79856b2aa048ccc382d Content-Type: text/plain; charset=ISO-8859-1 Yes, the HTTP request that the browser finally made was: > GET / HTTP/1.1 Host: www.google.com The fragment wasn't sent by the browser to the server. --David On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb wrote: > Here is an example with Location header. I don't see URI with access token > been truncated. See Location header generated by JSP and actual redirect > that browser followed below. > > red.jsp (Running on local Tomcat): > > <% String url = "http://www.google.com#access_token=123"; > response.sendRedirect(url); %> > > Live HTTP headers trace for Iceweasel Browser: > > http://localhost:8080/red.jsp > > GET /red.jsp HTTP/1.1 > Host: localhost:8080 > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) > Gecko/2009032018 Mozilla/3.0.12 (Debian-3.0.12-1) > Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > Accept-Language: en-us,en;q=0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > Keep-Alive: 300 > Connection: keep-alive > > HTTP/1.x 302 Moved Temporarily > Server: Apache-Coyote/1.1 > Set-Cookie: JSESSIONID=236DAD3EA6288BDC6A780CFFFB9F83E2; Path=/ > Location: http://www.google.com#access_token=123 > Content-Type: text/html;charset=ISO-8859-1 > Content-Length: 0 > Date: Mon, 02 Aug 2010 00:18:01 GMT > ---------------------------------------------------------- > http://www.google.com/#access_token=123 > > GET / HTTP/1.1 > Host: www.google.com > > > --- On Sun, 8/1/10, Oleg Gryb wrote: > > > From: Oleg Gryb > > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > > To: "Marius Scurtescu" , "Bouiaw" < > bouiaw@gmail.com> > > Cc: oauth@ietf.org > > Date: Sunday, August 1, 2010, 7:18 PM > > I'll need to check if it's true for > > dynamic redirects that use Location header, > > but right now I can provide an example where JavaScripts > > are used for redirects > > in which case access token is send in a URL. > > > > Let us assume that you've implemented an endpoint on your > > authz server as a JSP > > that populates access token dynamically: > > > > > > > > > > > > > > After JSP container expanded the variable, the response > > that browser will see > > looks as follows: > > > > > > > > > > > > > > > > To test the page above, I put it to my local Apache web > > server and then accessed > > it using Iceweasel browser. I've used HTTP Live Headers to > > see all redirects. > > The trace is below. Please let me know what I'm missing. > > The last GET has access > > token in it. > > > > http://localhost/red.html > > > > GET /red.html HTTP/1.1 > > Host: localhost > > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; > > rv:1.9.0.7) Gecko/2009032018 > > Mozilla/3.0.12 (Debian-3.0.12-1) > > Accept: > > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > > Accept-Language: en-us,en;q=0.5 > > Accept-Encoding: gzip,deflate > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > Keep-Alive: 300 > > Connection: keep-alive > > If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT > > If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip > > > > HTTP/1.x 200 OK > > Date: Sun, 01 Aug 2010 23:16:17 GMT > > Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with > > Suhosin-Patch > > mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 > > Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT > > Etag: "dfa53-67-48ccb4133b4c0"-gzip > > Accept-Ranges: bytes > > Vary: Accept-Encoding > > Content-Encoding: gzip > > Content-Length: 110 > > Keep-Alive: timeout=15, max=100 > > Connection: Keep-Alive > > Content-Type: text/html > > ---------------------------------------------------------- > > http://www.google.com/#access_token=123 > > > > GET / HTTP/1.1 > > Host: www.google.com > > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; > > rv:1.9.0.7) Gecko/2009032018 > > Mozilla/3.0.12 (Debian-3.0.12-1) > > Accept: > > text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 > > Accept-Language: en-us,en;q=0.5 > > Accept-Encoding: gzip,deflate > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > Keep-Alive: 300 > > Connection: keep-alive > > Referer: http://localhost/red.html > > Cookie: > > > PREF=ID=0f1fa5297d3f9d6a:U=f5ef3a217b0cd5bf:TM=1277864220:LM=1278796823:GM=1:S=j8uhrMH9ofdi5YZo; > > > NID=37=J2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkHOqiMUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd; > > ; > > > SID=DQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG9_YxNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6cW1gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ; > > HSID=ASoUGayYF7At1XErl > > > > > > > > > > > > > > > > ----- Original Message ---- > > From: Marius Scurtescu > > To: Bouiaw > > Cc: Oleg Gryb ; > > oauth@ietf.org > > Sent: Sun, August 1, 2010 1:03:36 PM > > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in > > OAuth 2.0? > > > > On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw > > wrote: > > > Does the redirect with fragment in URL without sending > > it to the > > > server have been tested with all main browsers ? > > > > AFAIK this is how all major browsers behave. Does anyone > > know > > otherwise? Browsers that don't respect this? > > > > Marius > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001485eba79856b2aa048ccc382d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, the HTTP request that the browser finally made was:
GET / HTTP/1.1=A0
Host:= =A0www.google.com

The fragment wasn't sent by the browser to the serv= er.

--David


On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb &l= t;oleg_gryb@yahoo.com>= wrote:
Here is an example with Location header. I = don't see URI with access token been truncated. See Location header gen= erated by JSP and actual redirect that browser followed below.

red.jsp (Running on local Tomcat):

<% String url =3D "http://www.google.com#access_token=3D123"; = response.sendRedirect(url); %>

Live HTTP headers trace for Iceweasel Browser:

http://localhos= t:8080/red.jsp

GET /red.jsp HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.= 9.0.7) Gecko/2009032018 Mozilla/3.0.12 (Debian-3.0.12-1)
Accept: text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8=
Accept-Language: en-us,en;q=3D0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 302 Moved Temporarily
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=3D236DAD3EA6288BDC6A780CFFFB9F83E2; Path=3D/
Location: http://www.google.com#access_token=3D123
Content-Type: text/html;charset=3DISO-8859-1
Content-Length: 0
Date: Mon, 02 Aug 2010 00:18:01 GMT
---------------------------------------------------------= -
htt= p://www.google.com/#access_token=3D123

GET / HTTP/1.1
Host: www.google.com


--- On Sun, 8/1/10, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

> From: Oleg Gryb <oleg_gryb@y= ahoo.com>
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure= in OAuth 2.0?
> To: "Marius Scurtescu" <mscurtescu@google.com>, "Bouiaw" <bouiaw@gmail.com>
> Cc: oauth@ietf.org
> Date: Sunday, August 1, 2010, 7:18 PM
> I'll need to check if it's t= rue for
> dynamic redirects that use Location header,
> but right now I can provide an example where JavaScripts
> are used for redirects
> in which case access token is send in a URL.
>
> Let us assume that you've implemented an endpoint on your
> authz server as a JSP
> that populates access token dynamically:
>
> <html>
> <body onload=3D"window.location.href =3D
> 'http://www.google.com#access_token=3D<%=3Dvar_with_token%>'= ;">
> </body>
> </html>
>
> After JSP container expanded the variable, the response
> that browser will see
> looks as follows:
>
>
> <html>
> <body onload=3D"window.location.href =3D 'http://www.google.co= m#access_token=3D123'">
> </body>
> </html>
>
> To test the page above, I put it to my local Apache web
> server and then accessed
> it using Iceweasel browser. I've used HTTP Live Headers to
> see all redirects.
> The trace is below. Please let me know what I'm missing.
> The last GET has access
> token in it.
>
> http://localho= st/red.html
>
> GET /red.html HTTP/1.1
> Host: localhost
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7
> Keep-Alive: 300
> Connection: keep-alive
> If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT
> If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip
>
> HTTP/1.x 200 OK
> Date: Sun, 01 Aug 2010 23:16:17 GMT
> Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with
> Suhosin-Patch
> mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0
> Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT
> Etag: "dfa53-67-48ccb4133b4c0"-gzip
> Accept-Ranges: bytes
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 110
> Keep-Alive: timeout=3D15, max=3D100
> Connection: Keep-Alive
> Content-Type: text/html
> ----------------------------------------------------------
> http://www.google.com/#access_token=3D123
>
> GET / HTTP/1.1
> Host: www.google.c= om
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http:= //localhost/red.html
> Cookie:
> PREF=3DID=3D0f1fa5297d3f9d6a:U=3Df5ef3a217b0cd5bf:TM=3D1277864220:LM= =3D1278796823:GM=3D1:S=3Dj8uhrMH9ofdi5YZo;
> NID=3D37=3DJ2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkH= OqiMUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd;
> ;
> SID=3DDQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG= 9_YxNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6= cW1gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ;
> =A0HSID=3DASoUGayYF7At1XErl
>
>
>
>
>
>
>
> ----- Original Message ----
> From: Marius Scurtescu <ms= curtescu@google.com>
> To: Bouiaw <bouiaw@gmail.com>
> Cc: Oleg Gryb <oleg@gryb.info= >;
> oauth@ietf.org
> Sent: Sun, August 1, 2010 1:03:36 PM
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in
> OAuth 2.0?
>
> On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw <bouiaw@gmail.com>
> wrote:
> > Does the redirect with fragment in URL without sending
> it to the
> > server have been tested with all main browsers ?
>
> AFAIK this is how all major browsers behave. Does anyone
> know
> otherwise? Browsers that don't respect this?
>
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> =A0 =A0 =A0
>



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

--001485eba79856b2aa048ccc382d-- From oleg_gryb@yahoo.com Sun Aug 1 17:42:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98FF93A6A8D for ; Sun, 1 Aug 2010 17:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2hD9kdqFJ-4 for ; Sun, 1 Aug 2010 17:42:27 -0700 (PDT) Received: from web37601.mail.mud.yahoo.com (web37601.mail.mud.yahoo.com [209.191.87.84]) by core3.amsl.com (Postfix) with SMTP id CF9863A6A6A for ; Sun, 1 Aug 2010 17:42:26 -0700 (PDT) Received: (qmail 19917 invoked by uid 60001); 2 Aug 2010 00:42:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280709773; bh=jJ+bGZzO0jvRpm4Oxk8T511cP8REoB0pbZSbTZiAt9A=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hAMyJi+ThzwFi8MumpTT/qxOo80DYLL0QBH1CJVKUg9JKtSGubhnrGHGuYxouPQLgqPmF8B6oiy8yJ7wQrM3Wp/lJ1cWZ/pL3md5i3St7LOg6m+4R09PyaJLQsc+XTkQykNZnLTVaxI+XjEaOV07Xehb/5CQp+GV1QQMdh2xW+4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FyZDKDIcLyeUCN7Kgwo0ehBkwKb75cWU/0xtIuS9HMrQZXT1iDf1JPCCNV6uIkJKBWocamQD8abchcOKFupinp6CMyBLD9TnWmLsrI1x0e+ApMgo0d52X1orNXmOBzhPdkqwB8quwn26I0iGQGnG7OiR01WWzYHJRiQa5UtfVls=; Message-ID: <583401.18530.qm@web37601.mail.mud.yahoo.com> X-YMail-OSG: sFm8RhoVM1nuPaQY4GBw1Ck1wkK.fmEOasHxcLrIm2nCeS4 fdWjBtgkgc4SettbC7qUxL85rBk6kCxfqC1kWJ4ZOV0t3USYtZoB4YJhWuTY VLKp9pRSDeqRxYxFs0mfzbPvPB8aJBvZJrnPAd5S3sKLgheNcIC0Ym4aKsbe vpMzcpseN4E4dkJcSCZQWjNixs4TxIo6kaxJHb8KrkNu3.OB5C99bdJzh6mv s1qi5PNRsSRyu3MZmTKFrLzWd22t.Q2FE_zffI7WAwFd7.a7Mn0LfaKj778V hKX9dINGygtd3gBMAxtte6deF2YrVU6vQBVDNxcGS.NM3ZehtvMR4h05szKm 7keK_oPuqQmM- Received: from [67.119.192.108] by web37601.mail.mud.yahoo.com via HTTP; Sun, 01 Aug 2010 17:42:53 PDT X-Mailer: YahooMailClassic/11.2.4 YahooMailWebService/0.8.105.279950 Date: Sun, 1 Aug 2010 17:42:53 -0700 (PDT) From: Oleg Gryb To: oleg@gryb.info, David Recordon In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-68003295-1280709773=:18530" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: oleg@gryb.info List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 00:42:29 -0000 --0-68003295-1280709773=:18530 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable David, Yes, you're right, I've should have paid attention to the GET line, not to = the URL above. Browser honors fragment sent in Location, but it's not on th= e GET line.=20 I've also enabled Tomcat access log and could not find the fragment there. My apologies.=20 --- On Sun, 8/1/10, David Recordon wrote: From: David Recordon Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? To: oleg@gryb.info Cc: oauth@ietf.org Date: Sunday, August 1, 2010, 8:24 PM Yes, the HTTP request that the browser finally made was: GET / HTTP/1.1=A0 Host:=A0www.google.com The fragment wasn't sent by the browser to the server. --David On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb wrote: Here is an example with Location header. I don't see URI with access token = been truncated. See Location header generated by JSP and actual redirect th= at browser followed below. red.jsp (Running on local Tomcat): <% String url =3D "http://www.google.com#access_token=3D123"; response.send= Redirect(url); %> Live HTTP headers trace for Iceweasel Browser: http://localhost:8080/red.jsp GET /red.jsp HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/20090= 32018 Mozilla/3.0.12 (Debian-3.0.12-1) Accept: text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 Accept-Language: en-us,en;q=3D0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 302 Moved Temporarily Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=3D236DAD3EA6288BDC6A780CFFFB9F83E2; Path=3D/ Location: http://www.google.com#access_token=3D123 Content-Type: text/html;charset=3DISO-8859-1 Content-Length: 0 Date: Mon, 02 Aug 2010 00:18:01 GMT ---------------------------------------------------------- http://www.google.com/#access_token=3D123 GET / HTTP/1.1 Host: www.google.com --- On Sun, 8/1/10, Oleg Gryb wrote: > From: Oleg Gryb > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > To: "Marius Scurtescu" , "Bouiaw" > Cc: oauth@ietf.org > Date: Sunday, August 1, 2010, 7:18 PM > I'll need to check if it's true for > dynamic redirects that use Location header, > but right now I can provide an example where JavaScripts > are used for redirects > in which case access token is send in a URL. > > Let us assume that you've implemented an endpoint on your > authz server as a JSP > that populates access token dynamically: > > > 'http://www.google.com#access_token=3D<%=3Dvar_with_token%>'"> > > > > After JSP container expanded the variable, the response > that browser will see > looks as follows: > > > > > > > > To test the page above, I put it to my local Apache web > server and then accessed > it using Iceweasel browser. I've used HTTP Live Headers to > see all redirects. > The trace is below. Please let me know what I'm missing. > The last GET has access > token in it. > > http://localhost/red.html > > GET /red.html HTTP/1.1 > Host: localhost > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:1.9.0.7) Gecko/2009032018 > Mozilla/3.0.12 (Debian-3.0.12-1) > Accept: > text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7 > Keep-Alive: 300 > Connection: keep-alive > If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT > If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip > > HTTP/1.x 200 OK > Date: Sun, 01 Aug 2010 23:16:17 GMT > Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with > Suhosin-Patch > mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 > Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT > Etag: "dfa53-67-48ccb4133b4c0"-gzip > Accept-Ranges: bytes > Vary: Accept-Encoding > Content-Encoding: gzip > Content-Length: 110 > Keep-Alive: timeout=3D15, max=3D100 > Connection: Keep-Alive > Content-Type: text/html > ---------------------------------------------------------- > http://www.google.com/#access_token=3D123 > > GET / HTTP/1.1 > Host: www.google.com > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:1.9.0.7) Gecko/2009032018 > Mozilla/3.0.12 (Debian-3.0.12-1) > Accept: > text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7 > Keep-Alive: 300 > Connection: keep-alive > Referer: http://localhost/red.html > Cookie: > PREF=3DID=3D0f1fa5297d3f9d6a:U=3Df5ef3a217b0cd5bf:TM=3D1277864220:LM=3D12= 78796823:GM=3D1:S=3Dj8uhrMH9ofdi5YZo; > NID=3D37=3DJ2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkHOqi= MUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd; > ; > SID=3DDQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG9_Y= xNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6cW1= gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ; > =A0HSID=3DASoUGayYF7At1XErl > > > > > > > > ----- Original Message ---- > From: Marius Scurtescu > To: Bouiaw > Cc: Oleg Gryb ; > oauth@ietf.org > Sent: Sun, August 1, 2010 1:03:36 PM > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in > OAuth 2.0? > > On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw > wrote: > > Does the redirect with fragment in URL without sending > it to the > > server have been tested with all main browsers ? > > AFAIK this is how all major browsers behave. Does anyone > know > otherwise? Browsers that don't respect this? > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > =A0 =A0 =A0 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =0A=0A=0A --0-68003295-1280709773=:18530 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
David,

Yes, you're right, I've should = have paid attention to the GET line, not to the URL above. Browser honors f= ragment sent in Location, but it's not on the GET line.

I've also e= nabled Tomcat access log and could not find the fragment there.

My a= pologies.

--- On Sun, 8/1/10, David Recordon <recordond@gm= ail.com> wrote:

From: David Reco= rdon <recordond@gmail.com>
Subject: Re: [OAUTH-WG] Is User Agent P= rofile Secure in OAuth 2.0?
To: oleg@gryb.info
Cc: oauth@ietf.org
= Date: Sunday, August 1, 2010, 8:24 PM

Yes,= the HTTP request that the browser finally made was:
GET / HTTP/1.1 
Host: ww= w.google.com

The fragment wasn't sent by the browser to the server.<= /div>

--David


On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb <oleg_gryb@yaho= o.com> wrote:
Here= is an example with Location header. I don't see URI with access token been= truncated. See Location header generated by JSP and actual redirect that b= rowser followed below.

red.jsp (Running on local Tomcat):

<% String url =3D "http://www.google.com#access_token=3D123= "; response.sendRedirect(url); %>

Live HTTP headers trace for Iceweasel Browser:

http://localhost:8080/red.jsp

GET /red.jsp HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686;= en-US; rv:1.9.0.7) Gecko/2009032018 Mozilla/3.0.12 (Debian-3.0.12-1)
Accept: text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8=
Accept-Language: en-us,en;q=3D0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 302 Moved Temporarily
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=3D236DAD3EA6288BDC6A780CFFFB9F83E2; Path=3D/
Location: http://www.google.com#access_token=3D123
Content-Type: text/html;charset=3DISO-8859-1
Content-Length: 0
Date: Mon, 02 Aug 2010 00:18:01 GMT
--------------------------------------------= --------------
http://www.google.com/#access_token=3D123

GET / HTTP/1.1
Host: = www.google.com


--- On Sun, 8/1/10, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

> From: Oleg Gryb <ol= eg_gryb@yahoo.com>
> Subject: Re: [OAUTH-WG] Is User Agent P= rofile Secure in OAuth 2.0?
> To: "Marius Scurtescu" <mscurtescu@google.com>, "Bouiaw" <bouiaw@gmail.com>
> Cc: oauth@ietf.org
> Date: Sunday, August 1, 2010, 7:18 PM
> I'll need to check if i= t's true for
> dynamic redirects that use Location header,
> but right now I can provide an example where JavaScripts
> are used for redirects
> in which case access token is send in a URL.
>
> Let us assume that you've implemented an endpoint on your
> authz server as a JSP
> that populates access token dynamically:
>
> <html>
> <body onload=3D"window.location.href =3D
> 'http://www.google.com#access_token=3D<%=3Dvar_with_t= oken%>'">
> </body>
> </html>
>
> After JSP container expanded the variable, the response
> that browser will see
> looks as follows:
>
>
> <html>
> <body onload=3D"window.location.href =3D 'http://www.g= oogle.com#access_token=3D123'">
> </body>
> </html>
>
> To test the page above, I put it to my local Apache web
> server and then accessed
> it using Iceweasel browser. I've used HTTP Live Headers to
> see all redirects.
> The trace is below. Please let me know what I'm missing.
> The last GET has access
> token in it.
>
> http://localhost/red.html
>
> GET /red.html HTTP/1.1
> Host: localhost
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7
> Keep-Alive: 300
> Connection: keep-alive
> If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT
> If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip
>
> HTTP/1.x 200 OK
> Date: Sun, 01 Aug 2010 23:16:17 GMT
> Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with
> Suhosin-Patch
> mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0
> Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT
> Etag: "dfa53-67-48ccb4133b4c0"-gzip
> Accept-Ranges: bytes
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 110
> Keep-Alive: timeout=3D15, max=3D100
> Connection: Keep-Alive
> Content-Type: text/html
> ----------------------------------------------------------
> http://www.google.com/#access_token=3D123
>
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://localhost/red.html
> Cookie:
> PREF=3DID=3D0f1fa5297d3f9d6a:U=3Df5ef3a217b0cd5bf:TM=3D1277864220:LM= =3D1278796823:GM=3D1:S=3Dj8uhrMH9ofdi5YZo;
> NID=3D37=3DJ2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkH= OqiMUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd;
> ;
> SID=3DDQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG= 9_YxNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6= cW1gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ;
>  HSID=3DASoUGayYF7At1XErl
>
>
>
>
>
>
>
> ----- Original Message ----
> From: Marius Scurtescu <mscurtescu@google.com>
> To: Bouiaw <bouiaw@gmail.= com>
> Cc: Oleg Gryb <oleg@gryb.info= >;
> oauth@ietf.org
> Sent: Sun, August 1, 2010 1:03:36 PM
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in
> OAuth 2.0?
>
> On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw <bouiaw@gmail.com>
> wrote:
> > Does the redirect with fragment in URL without sending
> it to the
> > server have been tested with all main browsers ?
>
> AFAIK this is how all major browsers behave. Does anyone
> know
> otherwise? Browsers that don't respect this?
>
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>      
>



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


-----Inline Attachment Follows-----

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

=0A=0A=0A=0A=0A=0A=0A=0A --0-68003295-1280709773=:18530-- From oleg_gryb@yahoo.com Sun Aug 1 19:47:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FCBC3A682A for ; Sun, 1 Aug 2010 19:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.04 X-Spam-Level: X-Spam-Status: No, score=-0.04 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKkowgIcDlvQ for ; Sun, 1 Aug 2010 19:47:28 -0700 (PDT) Received: from web37602.mail.mud.yahoo.com (web37602.mail.mud.yahoo.com [209.191.87.85]) by core3.amsl.com (Postfix) with SMTP id 4CA973A6817 for ; Sun, 1 Aug 2010 19:47:28 -0700 (PDT) Received: (qmail 21343 invoked by uid 60001); 2 Aug 2010 02:47:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280717272; bh=nah9GE8m1br27bRjuEO83UBLfpAMsNEFy987/RyQCz4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=b6hYRiUNAugKIuwkvkNufZgy9ZjYIj6CtuOCDHBBTnb5tKai9QCtM46XCpC5e/B6NFKvhbmlfaW6B1ahx0bW69ScfWVUK9ngouN7cCldXjEZA3GN6+WGhWvpI/CePdbp637RETPV+V+BHsBK6VQcBR1FOYrNZhjm9gbNaZh1Lgk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sxYdH0EVYuGmyeC1n6mIrlJCaSJ9J8TjEUA3mvLy3SWkrjopecIt2HgKgfIsiNXDJToyNybnIre81WR0xjGG3uYGg390z/+qmxGEQoqZEUO/3wd8XIKb87SWzIiYgCSbqdKpJ0si3SzNbVnGXlNF29kKi5Q1t+nwEc9hvsQLNzc=; Message-ID: <635529.20547.qm@web37602.mail.mud.yahoo.com> X-YMail-OSG: cedFdRMVM1nn.7rC1VDB5v3Ud3j2RPnMIrkIa6p1x.wlWNP bjeEKPusP_kZjEXGjelKivlR9OtDTjU91hGBiKHKDMNiaIHNTQV2yJZg0aVc v5K6F.Vtm0xfap03E4NoEDsCX6xc4m4T0B3oNo.FW9si.Ph.t51PwC7taxlv KrydEpxEofCE5wQ4wPTByN7dhYMy7STwivjsDtczyx8nVfG5HoqoyvIeL9Tt WPM3X8cPwopwvHSaSsyeg0HW8JtDEB7lB1CcgwddX9jnMBI4q_ktR.ipVUJ_ cKUyw3tNkmGPwa0nt4T5zNZw6vUzbPnqLWzMx0ipXPUtZs8pqIiMmvZyfDoC w9ZfGF5CFe5NQ Received: from [67.119.192.108] by web37602.mail.mud.yahoo.com via HTTP; Sun, 01 Aug 2010 19:47:52 PDT X-Mailer: YahooMailClassic/11.2.4 YahooMailWebService/0.8.105.279950 Date: Sun, 1 Aug 2010 19:47:52 -0700 (PDT) From: Oleg Gryb To: David Recordon In-Reply-To: <583401.18530.qm@web37601.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-8234156-1280717272=:20547" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: oleg@gryb.info List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 02:47:30 -0000 --0-8234156-1280717272=:20547 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I've just verified Ruby and Perl's user agents as well: both worked as expe= cted - no fragments in the web log files. It adds confidence. Thanks to eve= ryone who has answered. The code that I've used is below: ---------------------------------------------------------------------------= ----- use LWP; my $browser =3D LWP::UserAgent->new; if ($browser) { =A0=A0 $browser->agent("User-Agent: Mozilla/4.0"); =A0=A0 my $req =3D HTTP::Request->new(GET =3D> "http://localhost:8080/tmp#a= ccess_token=3D123"); =A0=A0 my $res =3D $browser->request($req); } ---------------------------------------------------------------------------= ---- require "httpclient.rb" client =3D HTTPClient.new client.get('http://localhost:8080/ruby#access_token=3D123') --- On Sun, 8/1/10, Oleg Gryb wrote: From: Oleg Gryb Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? To: oleg@gryb.info, "David Recordon" Cc: oauth@ietf.org Date: Sunday, August 1, 2010, 8:42 PM David, Yes, you're right, I've should have paid attention to the GET line, not to = the URL above. Browser honors fragment sent in Location, but it's not on th= e GET line.=20 I've also enabled Tomcat access log and could not find the fragment there. My apologies.=20 --- On Sun, 8/1/10, David Recordon wrote: From: David Recordon Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? To: oleg@gryb.info Cc: oauth@ietf.org Date: Sunday, August 1, 2010, 8:24 PM Yes, the HTTP request that the browser finally made was: GET / HTTP/1.1=A0 Host:=A0www.google.com The fragment wasn't sent by the browser to the server. --David On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb wrote: Here is an example with Location header. I don't see URI with access token = been truncated. See Location header generated by JSP and actual redirect th= at browser followed below. red.jsp (Running on local Tomcat): <% String url =3D "http://www.google.com#access_token=3D123"; response.send= Redirect(url); %> Live HTTP headers trace for Iceweasel Browser: http://localhost:8080/red.jsp GET /red.jsp HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/20090= 32018 Mozilla/3.0.12 (Debian-3.0.12-1) Accept: text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 Accept-Language: en-us,en;q=3D0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7 Keep-Alive: 300 Connection: keep-alive HTTP/1.x 302 Moved Temporarily Server: Apache-Coyote/1.1 Set-Cookie: JSESSIONID=3D236DAD3EA6288BDC6A780CFFFB9F83E2; Path=3D/ Location: http://www.google.com#access_token=3D123 Content-Type: text/html;charset=3DISO-8859-1 Content-Length: 0 Date: Mon, 02 Aug 2010 00:18:01 GMT ---------------------------------------------------------- http://www.google.com/#access_token=3D123 GET / HTTP/1.1 Host: www.google.com --- On Sun, 8/1/10, Oleg Gryb wrote: > From: Oleg Gryb > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > To: "Marius Scurtescu" , "Bouiaw" > Cc: oauth@ietf.org > Date: Sunday, August 1, 2010, 7:18 PM > I'll need to check if it's true for > dynamic redirects that use Location header, > but right now I can provide an example where JavaScripts > are used for redirects > in which case access token is send in a URL. > > Let us assume that you've implemented an endpoint on your > authz server as a JSP > that populates access token dynamically: > > > 'http://www.google.com#access_token=3D<%=3Dvar_with_token%>'"> > > > > After JSP container expanded the variable, the response > that browser will see > looks as follows: > > > > > > > > To test the page above, I put it to my local Apache web > server and then accessed > it using Iceweasel browser. I've used HTTP Live Headers to > see all redirects. > The trace is below. Please let me know what I'm missing. > The last GET has access > token in it. > > http://localhost/red.html > > GET /red.html HTTP/1.1 > Host: localhost > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:1.9.0.7) Gecko/2009032018 > Mozilla/3.0.12 (Debian-3.0.12-1) > Accept: > text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7 > Keep-Alive: 300 > Connection: keep-alive > If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT > If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip > > HTTP/1.x 200 OK > Date: Sun, 01 Aug 2010 23:16:17 GMT > Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with > Suhosin-Patch > mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 > Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT > Etag: "dfa53-67-48ccb4133b4c0"-gzip > Accept-Ranges: bytes > Vary: Accept-Encoding > Content-Encoding: gzip > Content-Length: 110 > Keep-Alive: timeout=3D15, max=3D100 > Connection: Keep-Alive > Content-Type: text/html > ---------------------------------------------------------- > http://www.google.com/#access_token=3D123 > > GET / HTTP/1.1 > Host: www.google.com > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; > rv:1.9.0.7) Gecko/2009032018 > Mozilla/3.0.12 (Debian-3.0.12-1) > Accept: > text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5 > Accept-Encoding: gzip,deflate > Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7 > Keep-Alive: 300 > Connection: keep-alive > Referer: http://localhost/red.html > Cookie: > PREF=3DID=3D0f1fa5297d3f9d6a:U=3Df5ef3a217b0cd5bf:TM=3D1277864220:LM=3D12= 78796823:GM=3D1:S=3Dj8uhrMH9ofdi5YZo; > NID=3D37=3DJ2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkHOqi= MUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd; > ; > SID=3DDQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG9_Y= xNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6cW1= gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ; > =A0HSID=3DASoUGayYF7At1XErl > > > > > > > > ----- Original Message ---- > From: Marius Scurtescu > To: Bouiaw > Cc: Oleg Gryb ; > oauth@ietf.org > Sent: Sun, August 1, 2010 1:03:36 PM > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in > OAuth 2.0? > > On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw > wrote: > > Does the redirect with fragment in URL without sending > it to the > > server have been tested with all main browsers ? > > AFAIK this is how all major browsers behave. Does anyone > know > otherwise? Browsers that don't respect this? > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > =A0 =A0 =A0 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =20 -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth =0A=0A=0A --0-8234156-1280717272=:20547 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I've just verified Ruby and Perl's user agent= s as well: both worked as expected - no fragments in the web log files. It = adds confidence. Thanks to everyone who has answered. The code that I've us= ed is below:

-------------------------------------------------------= -------------------------
use LWP;

my $browser =3D LWP::UserAgent= ->new;

if ($browser) {
   $browser->agent("User-A= gent: Mozilla/4.0");
   my $req =3D HTTP::Request->new(GET = =3D> "http://localhost:8080/tmp#access_token=3D123");
   my= $res =3D $browser->request($req);
}
-----------------------------= --------------------------------------------------
require "httpclient.r= b"

client =3D HTTPClient.new
client.get('http://localhost:8080/ru= by#access_token=3D123')


--- On Sun, 8/1/10, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
=
From: Oleg Gryb <oleg_gryb@yahoo.com>
Subject: Re: [OAUTH-WG] = Is User Agent Profile Secure in OAuth 2.0?
To: oleg@gryb.info, "David Re= cordon" <recordond@gmail.com>
Cc: oauth@ietf.org
Date: Sunday, = August 1, 2010, 8:42 PM

David,

Yes, yo= u're right, I've should have paid attention to the GET line, not to the URL= above. Browser honors fragment sent in Location, but it's not on the GET l= ine.

I've also enabled Tomcat access log and could not find the fra= gment there.

My apologies.

--- On Sun, 8/1/10, David Recordon = <recordond@gmail.com> wrote:
<= br>From: David Recordon <recordond@gmail.com>
Subject: Re: [OAUTH-= WG] Is User Agent Profile Secure in OAuth 2.0?
To: oleg@gryb.info
Cc:= oauth@ietf.org
Date: Sunday, August 1, 2010, 8:24 PM

Yes, the HTTP request that the browser finally m= ade was:
GET / HTTP/1.1 
Host: www.google.com

The fragment wasn't sent by the browser to the server.<= /div>

--David


On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb= <oleg_gryb@yahoo.com> wrote:
Here is an example with Location header. I don't see URI with acces= s token been truncated. See Location header generated by JSP and actual red= irect that browser followed below.

red.jsp (Running on local Tomcat):

<% String url =3D "http://www.google.com#access_token=3D123= "; response.sendRedirect(url); %>

Live HTTP headers trace for Iceweasel Browser:

http://localhost:8080/red.jsp

GET /red.jsp HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U;= Linux i686; en-US; rv:1.9.0.7) Gecko/2009032018 Mozilla/3.0.12 (Debian-3.0= .12-1)
Accept: text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8=
Accept-Language: en-us,en;q=3D0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 302 Moved Temporarily
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=3D236DAD3EA6288BDC6A780CFFFB9F83E2; Path=3D/
Location: http://www.google.com#access_token=3D123
Content-Type: text/html;charset=3DISO-8859-1
Content-Length: 0
Date: Mon, 02 Aug 2010 00:18:01 GMT
--------------------------------= --------------------------
http://www.google.com/#access_token=3D123

GET / HTTP/1.1
Host: = www.google.com


--- On Sun, 8/1/10, Oleg Gryb <oleg_gryb@yahoo= .com> wrote:

> From: Oleg Gryb <oleg_gryb@yahoo.com>
> Subject: Re: [OAUTH-WG] Is = User Agent Profile Secure in OAuth 2.0?
> To: "Marius Scurtescu" <mscurtescu@google= .com>, "Bouiaw" <bouiaw@gmail.com>
> Cc: oauth@ietf.org
> Date: Sunday, August 1, 2010, 7:18 PM
> I'll need t= o check if it's true for
> dynamic redirects that use Location header,
> but right now I can provide an example where JavaScripts
> are used for redirects
> in which case access token is send in a URL.
>
> Let us assume that you've implemented an endpoint on your
> authz server as a JSP
> that populates access token dynamically:
>
> <html>
> <body onload=3D"window.location.href =3D
> 'http://www.google.com#access_token=3D<%=3Dvar_with_t= oken%>'">
> </body>
> </html>
>
> After JSP container expanded the variable, the response
> that browser will see
> looks as follows:
>
>
> <html>
> <body onload=3D"window.location.href =3D 'http://www.g= oogle.com#access_token=3D123'">
> </body>
> </html>
>
> To test the page above, I put it to my local Apache web
> server and then accessed
> it using Iceweasel browser. I've used HTTP Live Headers to
> see all redirects.
> The trace is below. Please let me know what I'm missing.
> The last GET has access
> token in it.
>
> http://localhost/red.html
>
> GET /red.html HTTP/1.1
> Host: localhost
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7
> Keep-Alive: 300
> Connection: keep-alive
> If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT
> If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip
>
> HTTP/1.x 200 OK
> Date: Sun, 01 Aug 2010 23:16:17 GMT
> Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with
> Suhosin-Patch
> mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0
> Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT
> Etag: "dfa53-67-48ccb4133b4c0"-gzip
> Accept-Ranges: bytes
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 110
> Keep-Alive: timeout=3D15, max=3D100
> Connection: Keep-Alive
> Content-Type: text/html
> ----------------------------------------------------------
> http://www.google.com/#access_token=3D123
>
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=3D0.9,*/*;q=3D0.8 > Accept-Language: en-us,en;q=3D0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=3D0.7,*;q=3D0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://localhost/red.html
> Cookie:
> PREF=3DID=3D0f1fa5297d3f9d6a:U=3Df5ef3a217b0cd5bf:TM=3D1277864220:LM= =3D1278796823:GM=3D1:S=3Dj8uhrMH9ofdi5YZo;
> NID=3D37=3DJ2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkH= OqiMUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd;
> ;
> SID=3DDQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG= 9_YxNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6= cW1gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ;
>  HSID=3DASoUGayYF7At1XErl
>
>
>
>
>
>
>
> ----- Original Message ----
> From: Marius Scurtescu <mscurtescu@google.com>
> To: Bouiaw <bouiaw@gmail.com>
> Cc: Oleg Gryb <oleg@gryb.info>;
> oauth@ietf.org
> Sent: Sun, August 1, 2010 1:03:36 PM
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in
> OAuth 2.0?
>
> On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw <bouiaw= @gmail.com>
> wrote:
> > Does the redirect with fragment in URL without sending
> it to the
> > server have been tested with all main browsers ?
>
> AFAIK this is how all major browsers behave. Does anyone
> know
> otherwise? Browsers that don't respect this?
>
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>      
>



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


-----Inline Attachment Follows-----

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


-----Inline Attachment Follows-----

_______________________________________________
OAuth mailing l= ist
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>

=0A=0A --0-8234156-1280717272=:20547-- From oleg_gryb@yahoo.com Mon Aug 2 09:23:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8166E3A6BE7 for ; Mon, 2 Aug 2010 09:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.527 X-Spam-Level: * X-Spam-Status: No, score=1.527 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iprC86HJfoZf for ; Mon, 2 Aug 2010 09:23:01 -0700 (PDT) Received: from web37605.mail.mud.yahoo.com (web37605.mail.mud.yahoo.com [209.191.87.88]) by core3.amsl.com (Postfix) with SMTP id 6A7AE3A69EF for ; Mon, 2 Aug 2010 09:23:01 -0700 (PDT) Received: (qmail 50779 invoked by uid 60001); 2 Aug 2010 16:23:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280766206; bh=tnfOClezHszlKAbiCRxRE1iIm4QKpdt8cg5DYEAEUuc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fyJnR3MmsLtLYkRYWTc6rFKycmH6Y5duSnlmlWxAqKprjCvGuaT53WgPVFwxP2/HoiVbQZjXc66Fd3fgiVy4uW8ft0cLQEFa1GNVXOPkGCBoSyUG9nRWLv4UJ9ELSIC+5SRwq8tWbe6yy6E+mld/QGg/27EgVHML3A20t8S9p+8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=fZSkc8nQ0CFq5QXxuvFgFnEY3cVTrefAYITSCNvFQLtVJegPgCs784zM6wE3c9FeiTALz0FoyJs4g1+QIz1jG/7WmiFyFF/EK9/B7mzlMuejGt7fGij+g9jdi3se9M7kMu4G/Yo9Imc84JiXvVuG4IS4GtGG+/vGHGEl3AuXdoI=; Message-ID: <304014.50128.qm@web37605.mail.mud.yahoo.com> X-YMail-OSG: EwYRtukVM1l9HWWGW8x.7TOwORUEs.50cbDkRmXQVaIsII7 bVNztJVmBmqTQHoZVB16NAIQ30QTvTw5IXiHDxNuF_py0vSCvs2w9T4Y0Ma. ARvR7exGpuWJmYkwzCQg4jEuosGY7GVHoV2uRq432S6mazJIn4MuDb2Aaits iYM_63Z1JgXzNOSkHPpOKL2FSZyrn1K02ifB_q.lDPgu0TU7EYsKzQ.E3pXR iFe.u1XDJrPm_QnMOskN8JWWWSgvvd.92J.fIRAqxrPMvdjTBkXqqR64rRLF Mh0_d_JmbFZTJcBM8oQhO.1GXGBMgcYghS2R9If6dkaIb Received: from [208.240.243.170] by web37605.mail.mud.yahoo.com via HTTP; Mon, 02 Aug 2010 09:23:26 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <635529.20547.qm@web37602.mail.mud.yahoo.com> Date: Mon, 2 Aug 2010 09:23:26 -0700 (PDT) From: Oleg Gryb To: David Recordon In-Reply-To: <635529.20547.qm@web37602.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1390414669-1280766206=:50128" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 16:23:03 -0000 --0-1390414669-1280766206=:50128 Content-Type: text/plain; charset=us-ascii What about browsing history? I've just run the JSP below in Tomcat and found out that Firefox remembers the redirect in the browsing history. It'll be a problem in a shared desktop or Internet kiosk environment. JSP: <% String url = "http://localhost:8080#access_token=123"; response.sendRedirect(url); %> The URL that I can see in Firefox->History: http://localhost:8080#access_token=123 Why don't you want to send the access token in a response's body along with a JavaScript that will redirect the browser to the URL without token on page load? Oleg. ________________________________ From: Oleg Gryb To: David Recordon Cc: oauth@ietf.org Sent: Sun, August 1, 2010 7:47:52 PM Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? I've just verified Ruby and Perl's user agents as well: both worked as expected - no fragments in the web log files. It adds confidence. Thanks to everyone who has answered. The code that I've used is below: -------------------------------------------------------------------------------- use LWP; my $browser = LWP::UserAgent->new; if ($browser) { $browser->agent("User-Agent: Mozilla/4.0"); my $req = HTTP::Request->new(GET => "http://localhost:8080/tmp#access_token=123"); my $res = $browser->request($req); } ------------------------------------------------------------------------------- require "httpclient.rb" client = HTTPClient.new client.get('http://localhost:8080/ruby#access_token=123') --- On Sun, 8/1/10, Oleg Gryb wrote: >From: Oleg Gryb >Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? >To: oleg@gryb.info, "David Recordon" >Cc: oauth@ietf.org >Date: Sunday, August 1, 2010, 8:42 PM > > >David, > >Yes, you're right, I've should have paid attention to the GET line, not to the >URL above. Browser honors fragment sent in Location, but it's not on the GET >line. > > >I've also enabled Tomcat access log and could not find the fragment there. > >My apologies. > >--- On Sun, 8/1/10, David Recordon wrote: > > >>From: David Recordon >>Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? >>To: oleg@gryb.info >>Cc: oauth@ietf.org >>Date: Sunday, August 1, 2010, 8:24 PM >> >> >>Yes, the HTTP request that the browser finally made was: >>GET / HTTP/1.1 >Host: www.google.com The fragment wasn't sent by the browser to the server. --David On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb wrote: Here is an example with Location header. I don't see URI with access token been truncated. See Location header generated by JSP and actual redirect that browser followed below. > >red.jsp (Running on local Tomcat): > ><% String url = "http://www.google.com#access_token=123"; >response.sendRedirect(url); %> > >Live HTTP headers trace for Iceweasel Browser: > >http://localhost:8080/red.jsp > >GET /red.jsp HTTP/1.1 >Host: localhost:8080 > >User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009032018 >Mozilla/3.0.12 (Debian-3.0.12-1) >Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >Accept-Language: en-us,en;q=0.5 >Accept-Encoding: gzip,deflate >Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 >Keep-Alive: 300 >Connection: keep-alive > >HTTP/1.x 302 Moved Temporarily >Server: Apache-Coyote/1.1 >Set-Cookie: JSESSIONID=236DAD3EA6288BDC6A780CFFFB9F83E2; Path=/ >Location: http://www.google.com#access_token=123 >Content-Type: text/html;charset=ISO-8859-1 >Content-Length: 0 >Date: Mon, 02 Aug 2010 00:18:01 GMT > >---------------------------------------------------------- >http://www.google.com/#access_token=123 > >GET / HTTP/1.1 >Host: www.google.com > > >--- On Sun, 8/1/10, Oleg Gryb wrote: > >> From: Oleg Gryb > >> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? >> To: "Marius Scurtescu" , "Bouiaw" >> Cc: oauth@ietf.org >> Date: Sunday, August 1, 2010, 7:18 PM > >> I'll need to check if it's true for >> dynamic redirects that use Location header, >> but right now I can provide an example where JavaScripts >> are used for redirects >> in which case access token is send in a URL. >> >> Let us assume that you've implemented an endpoint on your >> authz server as a JSP >> that populates access token dynamically: >> >> >> >> >> >> >> After JSP container expanded the variable, the response >> that browser will see >> looks as follows: >> >> >> >> >> >> >> >> To test the page above, I put it to my local Apache web >> server and then accessed >> it using Iceweasel browser. I've used HTTP Live Headers to >> see all redirects. >> The trace is below. Please let me know what I'm missing. >> The last GET has access >> token in it. >> >> http://localhost/red.html >> >> GET /red.html HTTP/1.1 >> Host: localhost >> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; >> rv:1.9.0.7) Gecko/2009032018 >> Mozilla/3.0.12 (Debian-3.0.12-1) >> Accept: >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> Accept-Language: en-us,en;q=0.5 >> Accept-Encoding: gzip,deflate >> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 >> Keep-Alive: 300 >> Connection: keep-alive >> If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT >> If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip >> >> HTTP/1.x 200 OK >> Date: Sun, 01 Aug 2010 23:16:17 GMT >> Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with >> Suhosin-Patch >> mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0 >> Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT >> Etag: "dfa53-67-48ccb4133b4c0"-gzip >> Accept-Ranges: bytes >> Vary: Accept-Encoding >> Content-Encoding: gzip >> Content-Length: 110 >> Keep-Alive: timeout=15, max=100 >> Connection: Keep-Alive >> Content-Type: text/html >> ---------------------------------------------------------- >> http://www.google.com/#access_token=123 >> >> GET / HTTP/1.1 >> Host: www.google.com >> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; >> rv:1.9.0.7) Gecko/2009032018 >> Mozilla/3.0.12 (Debian-3.0.12-1) >> Accept: >> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 >> Accept-Language: en-us,en;q=0.5 >> Accept-Encoding: gzip,deflate >> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 >> Keep-Alive: 300 >> Connection: keep-alive >> Referer: http://localhost/red.html >> Cookie: >>PREF=ID=0f1fa5297d3f9d6a:U=f5ef3a217b0cd5bf:TM=1277864220:LM=1278796823:GM=1:S=j8uhrMH9ofdi5YZo; >>; >>NID=37=J2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkHOqiMUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd; >>; >> ; >>SID=DQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG9_YxNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6cW1gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ; >>; >> HSID=ASoUGayYF7At1XErl >> >> >> >> >> >> >> >> ----- Original Message ---- >> From: Marius Scurtescu >> To: Bouiaw >> Cc: Oleg Gryb ; >> oauth@ietf.org >> Sent: Sun, August 1, 2010 1:03:36 PM >> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in >> OAuth 2.0? >> >> On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw >> wrote: >> > Does the redirect with fragment in URL without sending >> it to the >> > server have been tested with all main browsers ? >> >> AFAIK this is how all major browsers behave. Does anyone >> know >> otherwise? Browsers that don't respect this? >> >> Marius >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> > > > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > >>-----Inline Attachment Follows----- >> >> >>_______________________________________________ >>OAuth mailing list >>OAuth@ietf.org >>https://www.ietf.org/mailman/listinfo/oauth >> > >-----Inline Attachment Follows----- > > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > --0-1390414669-1280766206=:50128 Content-Type: text/html; charset=us-ascii
What about browsing history? I've just run the JSP below in Tomcat and found out that Firefox remembers the redirect in the browsing history. It'll be a problem in a shared desktop or Internet kiosk environment.

JSP:
<% String url = "http://localhost:8080#access_token=123"; response.sendRedirect(url); %>

The URL that I can see in Firefox->History: http://localhost:8080#access_token=123

Why don't you want to send the access token in a response's body along with a JavaScript that will redirect the browser to the URL without token on page load?

Oleg.


From: Oleg Gryb <oleg_gryb@yahoo.com>
To: David Recordon <recordond@gmail.com>
Cc: oauth@ietf.org
Sent: Sun, August 1, 2010 7:47:52 PM
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?

I've just verified Ruby and Perl's user agents as well: both worked as expected - no fragments in the web log files. It adds confidence. Thanks to everyone who has answered. The code that I've used is below:

--------------------------------------------------------------------------------
use LWP;

my $browser = LWP::UserAgent->new;

if ($browser) {
   $browser->agent("User-Agent: Mozilla/4.0");
   my $req = HTTP::Request->new(GET => "http://localhost:8080/tmp#access_token=123");
   my $res = $browser->request($req);
}
-------------------------------------------------------------------------------
require "httpclient.rb"

client = HTTPClient.new
client.get('http://localhost:8080/ruby#access_token=123')


--- On Sun, 8/1/10, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

From: Oleg Gryb <oleg_gryb@yahoo.com>
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?
To: oleg@gryb.info, "David Recordon" <recordond@gmail.com>
Cc: oauth@ietf.org
Date: Sunday, August 1, 2010, 8:42 PM

David,

Yes, you're right, I've should have paid attention to the GET line, not to the URL above. Browser honors fragment sent in Location, but it's not on the GET line.

I've also enabled Tomcat access log and could not find the fragment there.

My apologies.

--- On Sun, 8/1/10, David Recordon <recordond@gmail.com> wrote:

From: David Recordon <recordond@gmail.com>
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?
To: oleg@gryb.info
Cc: oauth@ietf.org
Date: Sunday, August 1, 2010, 8:24 PM

Yes, the HTTP request that the browser finally made was:
GET / HTTP/1.1 
Host: www.google.com

The fragment wasn't sent by the browser to the server.

--David


On Sun, Aug 1, 2010 at 5:12 PM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
Here is an example with Location header. I don't see URI with access token been truncated. See Location header generated by JSP and actual redirect that browser followed below.

red.jsp (Running on local Tomcat):

<% String url = "http://www.google.com#access_token=123"; response.sendRedirect(url); %>

Live HTTP headers trace for Iceweasel Browser:

http://localhost:8080/red.jsp

GET /red.jsp HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009032018 Mozilla/3.0.12 (Debian-3.0.12-1)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.x 302 Moved Temporarily
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=236DAD3EA6288BDC6A780CFFFB9F83E2; Path=/
Location: http://www.google.com#access_token=123
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 0
Date: Mon, 02 Aug 2010 00:18:01 GMT
----------------------------------------------------------
http://www.google.com/#access_token=123

GET / HTTP/1.1
Host: www.google.com


--- On Sun, 8/1/10, Oleg Gryb <oleg_gryb@yahoo.com> wrote:

> From: Oleg Gryb <oleg_gryb@yahoo.com>
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?
> To: "Marius Scurtescu" <mscurtescu@google.com>, "Bouiaw" <bouiaw@gmail.com>
> Cc: oauth@ietf.org
> Date: Sunday, August 1, 2010, 7:18 PM
> I'll need to check if it's true for
> dynamic redirects that use Location header,
> but right now I can provide an example where JavaScripts
> are used for redirects
> in which case access token is send in a URL.
>
> Let us assume that you've implemented an endpoint on your
> authz server as a JSP
> that populates access token dynamically:
>
> <html>
> <body onload="window.location.href =
> 'http://www.google.com#access_token=<%=var_with_token%>'">
> </body>
> </html>
>
> After JSP container expanded the variable, the response
> that browser will see
> looks as follows:
>
>
> <html>
> <body onload="window.location.href = 'http://www.google.com#access_token=123'">
> </body>
> </html>
>
> To test the page above, I put it to my local Apache web
> server and then accessed
> it using Iceweasel browser. I've used HTTP Live Headers to
> see all redirects.
> The trace is below. Please let me know what I'm missing.
> The last GET has access
> token in it.
>
> http://localhost/red.html
>
> GET /red.html HTTP/1.1
> Host: localhost
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> If-Modified-Since: Sun, 01 Aug 2010 23:15:07 GMT
> If-None-Match: "dfa53-67-48ccb4133b4c0"-gzip
>
> HTTP/1.x 200 OK
> Date: Sun, 01 Aug 2010 23:16:17 GMT
> Server: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny2 with
> Suhosin-Patch
> mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4 Perl/v5.10.0
> Last-Modified: Sun, 01 Aug 2010 23:15:07 GMT
> Etag: "dfa53-67-48ccb4133b4c0"-gzip
> Accept-Ranges: bytes
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 110
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Content-Type: text/html
> ----------------------------------------------------------
> http://www.google.com/#access_token=123
>
> GET / HTTP/1.1
> Host: www.google.com
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
> rv:1.9.0.7) Gecko/2009032018
> Mozilla/3.0.12 (Debian-3.0.12-1)
> Accept:
> text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://localhost/red.html
> Cookie:
> PREF=ID=0f1fa5297d3f9d6a:U=f5ef3a217b0cd5bf:TM=1277864220:LM=1278796823:GM=1:S=j8uhrMH9ofdi5YZo;
> NID=37=J2gm7WZsItUM0qhpdyYDiOyE7XuO0tWvSWtOcBpgWZ-Y3Rrb6XJC46TcHkHOqiMUF1ClrcG9JZQ9l0BN8eJUinfWIgsUEw7NuCwphBhwjO1odRifOKngacoHcy83E1wd;
> ;
> SID=DQAAAHcAAADE79x4u_-iBaW7H0MKg1k42z-x8maC4Cm3nUsu68UmsWtkeKZ1cRpG9_YxNhRNeSqGpeRGwyxyMUFtyLBEtfpwt76t_RgE0BTQRig2NqD82bmbcf_CTC0Eu-7HjxNw_n6cW1gkWrUPS46aCzkeIDHAJHDMoVOrrmkVe3lcOGZ1ZQ;
>  HSID=ASoUGayYF7At1XErl
>
>
>
>
>
>
>
> ----- Original Message ----
> From: Marius Scurtescu <mscurtescu@google.com>
> To: Bouiaw <bouiaw@gmail.com>
> Cc: Oleg Gryb <oleg@gryb.info>;
> oauth@ietf.org
> Sent: Sun, August 1, 2010 1:03:36 PM
> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in
> OAuth 2.0?
>
> On Sun, Aug 1, 2010 at 12:22 PM, Bouiaw <bouiaw@gmail.com>
> wrote:
> > Does the redirect with fragment in URL without sending
> it to the
> > server have been tested with all main browsers ?
>
> AFAIK this is how all major browsers behave. Does anyone
> know
> otherwise? Browsers that don't respect this?
>
> Marius
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>      
>



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


-----Inline Attachment Follows-----

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


-----Inline Attachment Follows-----

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


--0-1390414669-1280766206=:50128-- From beaton@google.com Mon Aug 2 12:46:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217A73A6C5A for ; Mon, 2 Aug 2010 12:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.837 X-Spam-Level: X-Spam-Status: No, score=-105.837 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e98g+JVBvCsb for ; Mon, 2 Aug 2010 12:46:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E85843A6C5B for ; Mon, 2 Aug 2010 12:46:44 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id o72JlBAZ020263 for ; Mon, 2 Aug 2010 12:47:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280778432; bh=/Ou9RlHIuyIAL+6t2CI/Y6a+uRA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=eFsBLvEJd4lCSo0ANYcqq/qvwFcUBwh4fDqXD2s+FpGidISLjEFXR2Jx6fdFqKQDg WCc501SSWfES5+HhdWezA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=MdOtp6sItsO+MPL6s2qTBTtpS5w4QgR+2LruNic0Ki8ZsXYp+0GNKX9IfvzRxOVNF 1Cz416wkofgfqCdttgDGQ== Received: from pxi10 (pxi10.prod.google.com [10.243.27.10]) by kpbe15.cbf.corp.google.com with ESMTP id o72Jl33B016036 for ; Mon, 2 Aug 2010 12:47:10 -0700 Received: by pxi10 with SMTP id 10so1612455pxi.16 for ; Mon, 02 Aug 2010 12:47:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.150.29 with SMTP id x29mr5741397wfd.326.1280778430422; Mon, 02 Aug 2010 12:47:10 -0700 (PDT) Received: by 10.142.195.9 with HTTP; Mon, 2 Aug 2010 12:47:10 -0700 (PDT) In-Reply-To: <304014.50128.qm@web37605.mail.mud.yahoo.com> References: <635529.20547.qm@web37602.mail.mud.yahoo.com> <304014.50128.qm@web37605.mail.mud.yahoo.com> Date: Mon, 2 Aug 2010 12:47:10 -0700 Message-ID: From: Brian Eaton To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 19:46:46 -0000 On Mon, Aug 2, 2010 at 9:23 AM, Oleg Gryb wrote: > > What about browsing history? I've just run the JSP below in Tomcat and fo= und out that Firefox remembers the redirect in the browsing history. It'll = be a problem in a shared desktop or Internet kiosk environment. I think the best practice for authentication tokens passed on URLs is to clean the URL as soon as it is received. For the web server flow, that would mean sending a 302 after receiving the authorization code. For the user-agent/javascript flow, that would mean copying the token into a cookie or a javascript variable, and then using window.location.replace() to clean the URL. My javascript ninja sources tell me that location.replace() cleans the browser history, but I haven't actually tested it. =A0The mozilla documentation is very clear on the expected behavior: https://developer.mozilla.org/en/window.location "Replace the current document with the one at the provided URL. The difference from the=A0assign()=A0method is that after using=A0replace()=A0t= he current page will not be saved in session history, meaning the user won't be able to use the Back button to navigate to it." Cheers, Brian From torsten@lodderstedt.net Mon Aug 2 12:53:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47FA63A683E for ; Mon, 2 Aug 2010 12:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.239 X-Spam-Level: X-Spam-Status: No, score=0.239 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkrDw11dU397 for ; Mon, 2 Aug 2010 12:53:46 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id 631163A67A4 for ; Mon, 2 Aug 2010 12:53:46 -0700 (PDT) Received: from tmo-108-251.customers.d1-online.com ([80.187.108.251] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Og15P-0003F5-SQ for oauth@ietf.org; Mon, 02 Aug 2010 21:54:13 +0200 Message-ID: <4C57224C.5000401@lodderstedt.net> Date: Mon, 02 Aug 2010 21:53:48 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 19:53:47 -0000 the existing authorization server endpoints (end-user authorization and tokens endpoint) have a relatively clearly semantics and scope. Adding distinct new functions to an authorization server will (in my opionion) require the definition of new endpoints. For example, I'm working on an I-D for token revocation. Such a function does not fit into the tokens endpoint since it has become a "token issuance endpoint" rather than a general purpose client2server endpoint. I therefore would propose to include the option to define and register new endpoints into the Extensibility section of the spec. This would also facilitate the incorporation of additional endpoints (with well-defined names) into OAuth discovery. Any thoughts? regards, Torsten. From eran@hueniverse.com Mon Aug 2 13:05:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0E193A6C5B for ; Mon, 2 Aug 2010 13:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XWUurkBjLaF for ; Mon, 2 Aug 2010 13:05:11 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EC8833A6C48 for ; Mon, 2 Aug 2010 13:05:10 -0700 (PDT) Received: (qmail 10288 invoked from network); 2 Aug 2010 20:05:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Aug 2010 20:05:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 2 Aug 2010 13:05:28 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , "OAuth WG (oauth@ietf.org)" Date: Mon, 2 Aug 2010 13:05:32 -0700 Thread-Topic: [OAUTH-WG] Extensibility: new endpoints Thread-Index: AcsyfIC0xtmR+Y/fTxKs4D2AVX+HbQAAVejA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C57224C.5000401@lodderstedt.net> In-Reply-To: <4C57224C.5000401@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:05:12 -0000 This doesn't belong in core. A registry is used to avoid name collisions, n= ot to provide an inventory. Maybe in discovery. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Monday, August 02, 2010 12:54 PM > To: OAuth WG (oauth@ietf.org) > Subject: [OAUTH-WG] Extensibility: new endpoints >=20 > the existing authorization server endpoints (end-user authorization and > tokens endpoint) have a relatively clearly semantics and scope. Adding > distinct new functions to an authorization server will (in my opionion) r= equire > the definition of new endpoints. For example, I'm working on an I-D for > token revocation. Such a function does not fit into the tokens endpoint s= ince > it has become a "token issuance endpoint" rather than a general purpose > client2server endpoint. >=20 > I therefore would propose to include the option to define and register ne= w > endpoints into the Extensibility section of the spec. This would also fac= ilitate > the incorporation of additional endpoints (with well-defined names) into > OAuth discovery. >=20 > Any thoughts? >=20 > regards, > Torsten. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Mon Aug 2 13:06:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398E33A6C5D for ; Mon, 2 Aug 2010 13:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.023 X-Spam-Level: X-Spam-Status: No, score=-1.023 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vD6zXdWdtt4 for ; Mon, 2 Aug 2010 13:06:40 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by core3.amsl.com (Postfix) with ESMTP id 455133A6C48 for ; Mon, 2 Aug 2010 13:06:40 -0700 (PDT) Received: from tmo-108-251.customers.d1-online.com ([80.187.108.251] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Og1Ht-00018L-OO; Mon, 02 Aug 2010 22:07:06 +0200 Message-ID: <4C572562.8050003@lodderstedt.net> Date: Mon, 02 Aug 2010 22:06:58 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:06:41 -0000 and discovery does not belong into the core? regards, Torsten. Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: > This doesn't belong in core. A registry is used to avoid name collisions, not to provide an inventory. > > Maybe in discovery. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Monday, August 02, 2010 12:54 PM >> To: OAuth WG (oauth@ietf.org) >> Subject: [OAUTH-WG] Extensibility: new endpoints >> >> the existing authorization server endpoints (end-user authorization and >> tokens endpoint) have a relatively clearly semantics and scope. Adding >> distinct new functions to an authorization server will (in my opionion) require >> the definition of new endpoints. For example, I'm working on an I-D for >> token revocation. Such a function does not fit into the tokens endpoint since >> it has become a "token issuance endpoint" rather than a general purpose >> client2server endpoint. >> >> I therefore would propose to include the option to define and register new >> endpoints into the Extensibility section of the spec. This would also facilitate >> the incorporation of additional endpoints (with well-defined names) into >> OAuth discovery. >> >> Any thoughts? >> >> regards, >> Torsten. >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From eran@hueniverse.com Mon Aug 2 13:18:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B098E3A6BC9 for ; Mon, 2 Aug 2010 13:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXEhJXXXBoCm for ; Mon, 2 Aug 2010 13:18:09 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id B29B03A698C for ; Mon, 2 Aug 2010 13:18:09 -0700 (PDT) Received: (qmail 28108 invoked from network); 2 Aug 2010 20:18:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 2 Aug 2010 20:18:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 2 Aug 2010 13:18:37 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Mon, 2 Aug 2010 13:18:40 -0700 Thread-Topic: [OAUTH-WG] Extensibility: new endpoints Thread-Index: AcsyflEMw1nMToSUT0iBQEzdErEshwAAH7Hg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> In-Reply-To: <4C572562.8050003@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:18:10 -0000 No according to WG consensus. We took it all out because too many people co= nsidered it experimental, so while it may be a WG item, it is not part of t= he core spes. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, August 02, 2010 1:07 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Extensibility: new endpoints >=20 > and discovery does not belong into the core? >=20 > regards, > Torsten. >=20 > Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: > > This doesn't belong in core. A registry is used to avoid name collision= s, not > to provide an inventory. > > > > Maybe in discovery. > > > > EHL > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Monday, August 02, 2010 12:54 PM > >> To: OAuth WG (oauth@ietf.org) > >> Subject: [OAUTH-WG] Extensibility: new endpoints > >> > >> the existing authorization server endpoints (end-user authorization > >> and tokens endpoint) have a relatively clearly semantics and scope. > >> Adding distinct new functions to an authorization server will (in my > >> opionion) require the definition of new endpoints. For example, I'm > >> working on an I-D for token revocation. Such a function does not fit > >> into the tokens endpoint since it has become a "token issuance > >> endpoint" rather than a general purpose client2server endpoint. > >> > >> I therefore would propose to include the option to define and > >> register new endpoints into the Extensibility section of the spec. > >> This would also facilitate the incorporation of additional endpoints > >> (with well-defined names) into OAuth discovery. > >> > >> Any thoughts? > >> > >> regards, > >> Torsten. > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> From torsten@lodderstedt.net Mon Aug 2 13:19:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB6A3A6C63 for ; Mon, 2 Aug 2010 13:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.919, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nMf9xrShg2C for ; Mon, 2 Aug 2010 13:19:52 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id 75DCF3A6BC9 for ; Mon, 2 Aug 2010 13:19:52 -0700 (PDT) Received: from tmo-108-251.customers.d1-online.com ([80.187.108.251] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Og1Ug-0005KW-AS; Mon, 02 Aug 2010 22:20:19 +0200 Message-ID: <4C57287C.1090105@lodderstedt.net> Date: Mon, 02 Aug 2010 22:20:12 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:19:53 -0000 What consensus do you refer to? The WG charter? regards, Torsten. Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: > No according to WG consensus. We took it all out because too many people considered it experimental, so while it may be a WG item, it is not part of the core spes. > > EHL > > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Monday, August 02, 2010 1:07 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >> >> and discovery does not belong into the core? >> >> regards, >> Torsten. >> >> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: >> >>> This doesn't belong in core. A registry is used to avoid name collisions, not >>> >> to provide an inventory. >> >>> Maybe in discovery. >>> >>> EHL >>> >>> >>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Torsten Lodderstedt >>>> Sent: Monday, August 02, 2010 12:54 PM >>>> To: OAuth WG (oauth@ietf.org) >>>> Subject: [OAUTH-WG] Extensibility: new endpoints >>>> >>>> the existing authorization server endpoints (end-user authorization >>>> and tokens endpoint) have a relatively clearly semantics and scope. >>>> Adding distinct new functions to an authorization server will (in my >>>> opionion) require the definition of new endpoints. For example, I'm >>>> working on an I-D for token revocation. Such a function does not fit >>>> into the tokens endpoint since it has become a "token issuance >>>> endpoint" rather than a general purpose client2server endpoint. >>>> >>>> I therefore would propose to include the option to define and >>>> register new endpoints into the Extensibility section of the spec. >>>> This would also facilitate the incorporation of additional endpoints >>>> (with well-defined names) into OAuth discovery. >>>> >>>> Any thoughts? >>>> >>>> regards, >>>> Torsten. >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> > From torsten@lodderstedt.net Mon Aug 2 13:19:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284A23A6C69 for ; Mon, 2 Aug 2010 13:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2xnQirxFy-8 for ; Mon, 2 Aug 2010 13:19:58 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id 410953A6BC9 for ; Mon, 2 Aug 2010 13:19:58 -0700 (PDT) Received: from tmo-108-251.customers.d1-online.com ([80.187.108.251] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1Og1Um-0000VA-Hb for oauth@ietf.org; Mon, 02 Aug 2010 22:20:25 +0200 Message-ID: <4C572883.7020302@lodderstedt.net> Date: Mon, 02 Aug 2010 22:20:19 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "OAuth WG (oauth@ietf.org)" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Subject: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:19:59 -0000 In the WG meeting at Maastricht, I have been asked to write down my requirements regarding Discovery. And here they are: Assumptions: Discovery allows a compliant client to automatically obtain all deployment specific data required to securely access a particular resource servers as well as its respective authorization server for the purpose of obtaining access tokens. Starting point of the discovery process is a resource URL. This URL can be hard-coded into the client, bundled with the applications resources or manually configured by the end-user at runtime. 1) Client -> Resource The client uses the resource URL to obtain resource-specific data, such as a) one URI refering to its authorization server b) a definition of all scopes of the resource c) additional data, e.g. supported signature methods and algorithms I do not make any assumption about how many requests are processed in order to gather this information and whether there will be any levels of indirections (e.g. from resource to resource server). 2) Client -> Authz Server The authz server URI obtained in step 1 is used to gather the following data from the authz server: a) endpoint URLs (end-user authorization, tokens, ...) b) information about the server's capabilities, e.g. the supported response (end-user authorization endpoint) and grant types (tokens endpoint) The client stores the authz server's discovery URL along with the token(s) it obtains for further use. And that's it from my point of view. I would very much appreciate if we could have a discussion towards a consensus about discovery requirements. regards, Torsten. From romeda@gmail.com Mon Aug 2 13:28:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D443A686E for ; Mon, 2 Aug 2010 13:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5TM1t-ATar1 for ; Mon, 2 Aug 2010 13:28:00 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 4518E3A681E for ; Mon, 2 Aug 2010 13:27:59 -0700 (PDT) Received: by qyk8 with SMTP id 8so1982683qyk.10 for ; Mon, 02 Aug 2010 13:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=4yrvIKrnW3gtta5eq/TY+SfqWi1vWEVAgVtoCWFkf1k=; b=Fx+4ddC1pxaL7sPPSCzjGNUt7HUoF+eZAb62zZGSfLKSndAH8sRL/CFRPCQJMETr0r pkxwnjfkKzWqvrHEDsU2Mnd+lQzTk/T9dlqR3J1I3y0ZzIs+Hn7zaBuQyW/x+C3fURfk FFVY0poe3zGvJUUZMUaZ7WjGzeB14VDVqLV9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=DGJa1h1+S0u7Qlyi7Lu8axIaSq9qtdpVCqYPj81pAgKd/nNQ5/I/KNr5mtnNoBypmU NXiM6Dgh5zgUr18Mq9hBu1tsut0HLtvtUDRdGd/VdzwMzW8AN5aMyuv5dJzpSRVcbMN2 mhcoqMXEl/s0GgRx+ZvKuU6iVOHiVcTzU8QBo= Received: by 10.224.34.210 with SMTP id m18mr2038888qad.301.1280780906721; Mon, 02 Aug 2010 13:28:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.216.84 with HTTP; Mon, 2 Aug 2010 13:28:05 -0700 (PDT) From: Blaine Cook Date: Mon, 2 Aug 2010 22:28:05 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/mixed; boundary=00c09fa21bcdfaf6a3048cdd0a05 Subject: [OAUTH-WG] Flow Diagrams X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:28:00 -0000 --00c09fa21bcdfaf6a3048cdd0a05 Content-Type: text/plain; charset=UTF-8 Hi all, as promised, attached are the flow diagrams that Hannes and I used as the basis for our tutorial Friday in Maastricht. I'm trying to get through a boat-load of email at the moment, so it's just the images right now, but I will post the "UML" (as per PlantUML's syntax, which is awesome) for the diagrams on github so anyone can download or fork them for fixes and/or annotations. cheers, b. ps: a note about the device profile, these two flows (device w/input and without) are not in the most recent spec, so are almost certainly subject to change and/or merging (i.e., even more so than the other flows). --00c09fa21bcdfaf6a3048cdd0a05 Content-Type: text/plain; charset=US-ASCII; name="native-up.txt" Content-Disposition: attachment; filename="native-up.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gcdrt1593 QHN0YXJ0dW1sCgphY3RvciBVc2VyCgpwYXJ0aWNpcGFudCAiUmVzb3VyY2UgQ29uc3VtZXIgKE5h dGl2ZSBBcHApIiBhcyBSQwpwYXJ0aWNpcGFudCBFeHRlcm5hbEJyb3dzZXIKcGFydGljaXBhbnQg RW1iZWRkZWRCcm93c2VyCnBhcnRpY2lwYW50ICJBdXRob3JpemF0aW9uIFNlcnZlciIgYXMgQXV0 aFoKcGFydGljaXBhbnQgIlJlc291cmNlIFNlcnZlciIgYXMgUlMKClVzZXIgLT4gUkM6IFRha2Ug YWN0aW9uIHRoYXQgcmVxdWlyZXMgQXV0aG9yaXphdGlvbiB0byBSUwoKVXNlciA8LSBSQzogT2J0 YWluIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBmb3IgQXV0aFoKUkMgLT4gQXV0aFo6IFByZXNlbnQg dXNlcm5hbWUgYW5kIHBhc3N3b3JkClJDIDwtIEF1dGhaOiBSZXR1cm4gQWNjZXNzIFRva2VuClJD IC0+IFJDOiBEaXNjYXJkIFVzZXJuYW1lICYgUGFzc3dvcmQKCmxvb3AKICBSQyAtPiBSUzogRmV0 Y2ggcHJvdGVjdGVkIHJlc291cmNlIHcvQWNjZXNzIFRva2VuLgogIFJDIDwtIFJTOiBSZXR1cm4g cHJvdGVjdGVkIHJlc291cmNlLgplbmQKCkBlbmR1bWwK --00c09fa21bcdfaf6a3048cdd0a05 Content-Type: image/png; name="web-server.png" Content-Disposition: attachment; filename="web-server.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gcdrsk2u0 iVBORw0KGgoAAAANSUhEUgAABN8AAANmCAIAAABFb7rZAAAANXRFWHRjb3B5bGVmdABHZW5lcmF0 ZWQgYnkgaHR0cDovL3BsYW50dW1sLnNvdXJjZWZvcmdlLm5ldDpnVRsAAAJMelRYdHBsYW50dW1s AAB4nH1UTW+bQBC98ytGOeEDNriJrVpVFUJdVVEcW2CnVS7VGsbxqsCi3cWW8+s7y0cLjpMLsMyb 2Tdv3u6t0kzqMkstFmshYaNQWgX94jEvWK7hyvwB/wXp276T4kjLwRUwBRu/DwxRiVLGCIHIVZlR lv0TtxChPLQpYdBP8Uu9F5K/Ms1F3iAroAk8v1O+Awsjq6LnfCU2M5jnGiURCx9MN/zANNYNbXwD CYMZLAvMzxH+/28iGAYtNjLSwNJwgZUUMSp1AWk2DjHhEmMNWjTUE+wi6/2rSE0BZJvRo1LnVs+2 9EqiMtqbn4/PwE2LOxZjU9O09xGoo04LimlvenOWKmB5AqwZAoJNBqDQadAn3CaqcptxrTGBnZAZ JEwz2EmR1Rr/Y91kPaHku1O1gyJn1c09wqiOn2UP+0139SSVj5wm0PdKIBLsjPW7SFNxPMvrDOgb V0XKTmaML9LMsRLmi3M52BkemaO7Mo3WVc+0ucCua4D3Jmy4h6hLmYMfG4PBWvwhe9jH0bIwpVhK 8R1tsq8jgy6dN1a75L3+KhWiaC0ekW6o4z0UUmhSjQYr20N2HHX5DC83Q8ePSpGKplTTxttaww8I RRbmiXVLD3MFWauUjvpm8QB0wJUR8sadTO2IabgvU/Cm4F3PbtzZ2INgHq1h7HruwLpnB2avFwOI 5hCWZOwM6SY4cCnyjEZTxeGH0FEhdIWbXDt3XDf3CDwtLG84Gbq/x66zdcfOePrZ8dzFJ3dyYy1Y DMsIfv0Fmf6zIY8BR2wAAIAASURBVHja7N0JfE3nvv/xTKUlVEIEGUhCmraiaElpKTI1MbQJDTk4 Wkcd2mobx6E4l5ZruLeDCAcnFG06OUWCqKINieGaom5NRQwVEiFNSDSDDP3/juffdffZk52ITD7v 13p5rf1k7bXXXnl+z36+9t4rVr8BAAAAAFDTrCp9z5L8gowte0++/9nRmbHy78Wvv5cWTigAAAAA oJrSadG13KMzl6y17/2VVXfdZa39c0cmLZSfcloBAAAAAPc2nWbtOLTRNUTF0W98BqW+MfnozFlH Jk3/tvPgNXZPS2N8i6CMLXs5swAAAACAe5VOJZqute8lEVSyaM7hDeXlh3WX6ye+2f70UPnpGrse lzft4uQCAAAAAKo+nRZdy01oFSTh8/Db75TdOqQXTbVFfqreQS3MzOb8AgAAAACqOJ3++LfF6l3T koIDpqKpWrY99ZJseWTSQs4vAAAAAKAq02lJfoG6DJLhB3oNl+snvllj12Ot/XO3cvM4xQAAAACA Kkunlzftkmi6pWPYHaPp72+fRsj2F7/+nlMMAAAAAKiydHry/c8kbaa+MdnCdHpk0nTZXu7FKQYA AAAAVFk6PTozVtLm0ZmzLEynsuXt7WM5xQAAAACAKkunFX/v9D947xQAAAAAUMXptOLfO43ke6cA AAAAgCpOp7ev2fucxdfs3cI1ewEAAAAAVZ9Of/vX3ztdpv7eadmtQ+bT6fanR/D3TgEAAAAA9ySd Fl3LTWgVIrHz8NvvmAmoh9+eIdvEtwgqzMzm/AIAAAAAqjidiqwdqerzvd92Hmz4Ed/rJ7aod03X 2PW4vGkXJxcAAAAAcE/SqQqo8S2CJILevkhS+O4h475/bsT/DH1921ORXz/4rHrXlGgKAAAAALi3 6fS32x/x/fFvy9SbqLqLtByZtJAP9AIAAAAAqiOdKiX5BZc37doROEFy6c6gCRe//p4r9AIAAAAA qjudKkdnxko6Pfbuck4lAAAAAIB0CgAAAAAgnZJOAQAAAACkUwAAAAAA6ZR0CgAAAAC4N+k0a0eq JM87Lt8/N07SaVKfcZZsfHVnKmccAAAAAFCBdKreFK3ahbdYAQAAAAAVS6dXd6ZKmLzjktRHvXc6 3pKNee8UAAAAAFCxdGohvncKAAAAACCdAgAAAABIp6RTAAAAAADpFAAAAABAOiWdAgAAAABIpwAA AAAA0inpFAAAAABAOgUAAAAAkE5JpwAAAAAA0ikAAAAAgHRKOgUAAAAAkE4BAAAAAKRT0ikAAAAA gHQKAAAAACCdkk4BAAAAAKRTAAAAAADpVN/B1/5b0umh19/nVAIAAAAAaiadlhYUff1Qb0mn8q+s czYBAAAAANWdTsvLynaHTZZo+pXN0/KvrEsLJxQAAAAAUK3p9IeoBRJK1zv4X968W/6VdWnhhAIA AAAAqi+dnl70T4mj/2zwzNWdqXJT/pV1aZF2zilq3L/e0mepUwu/axY6M3hNYaEAQb1TmJVJp5c3 pqy5/WneC59t0RovxH0jLWtsn5af0rNR4yNLeflhlrqy3GU65QSy1I/ODF5TWChAUO8UZoXTac6h k2sbPycPc3z2x3o/OjZrhbTLT2UbOjcYWVhIpyx0ZvCawkIBgnqnMO9VOr15ITOhVYg8xv5XZhnd YP/Ls+Snss2vP2fSv8HIwkI6ZaEzg9cUFgoQ1DuFWfXp9Nb1/C2PD5MH2BHwRtmtEqPbSPsO/9dl G9lStqeLg5GFhXTKQmcGryksFCCodwqzKtOp5bHz/0Ks/+umQizAyMJCOmWhM4PXFBYKENQ7hVmZ dKo+sruhdaglH9mVbf7/B4BfnkUvByMLC+mUhc4MXlNYKEBQ7xRm1aTTSlzuSLt4ktyXjg5GFhbS KQudGbymsFCAoN4pzLtNp//3p2I27arQrv/1h2dsb//hmbhv6OtgZGEhnbLQmcFrCgsFCOqdwqx8 Os3akfrPBs/ITk8v/roSv+DTi/4p95U9XN2ZSncHIwsL6ZTF8uXWrYOlpYeYHKN+v6bUxX5OAYJ6 Z6mZdHrj5Pn1Dv6yxx+iFlT6dyz3lT3IfmRv9HjU7Mjy5Zfzf/jhK+3mzz9v+eKLeVVehBkZ2//x j79lZm6v5uIvK0tduHCyrMTHfyQH8PHH78qTlcYaH5VWr56Vk5NczelUnQRZtm1bWlS0vw4N4vIr 27hx4bvvjhs//qX5899au/aD3NyUOvqCpPqkdIC0tE2qpbj4gPxSzp1L1OblsbH/If8avXufPk/N nPnnO87sN29e9OabkfPmvZmUFFunOzPq7mz1boZ9S/q5mWXTpoWHDn1xlx27SnZS/fVIAaI6672O zitqvCqrMp0WZuVs8nhRdrc7fEp5WVmlf8dy391hk2U/sjfZJ50eNTiyeHq6zJ07QbuZmBjTtm3r Ki/CadP+ZGVlNWPG2Crf88WLW86f32zqp++888onn8yWle7dO3bq1CEk5BkHh6Zt2jjduLGrZkfG EyfWP/98T1MJ5B6lU3USIiIC3d1b2ds32rVrZZ14Fbl2bYe/f3dXV+epU0cvXvxOVNTwxx/3+v77 f9TRdKr6ZO/eXeXpqJY9e1ZLdcyZ84a6mZKy0tu77d3M2vv37+Xn1/H996P++McBQ4YE1OnOjLqb Tis07OuN5HeZTocNC/7oo0l3+WpSuZ3UeD1SgKjOeq+j84oar8qqTKd7IqbJvrb7vVJaUHSXv2bZ w7bur8jeZJ90etTvdCrT1tatW8iE283Nuco/rDVwYO+JE0cY/dHXX7//7LOdtQF0ypSXZeXSpa0P PthAvaFas8tf/zrK1JHfu3SqToIsXbv6yNyrTryKjB0b7uHhkpX1vd47kHUxmmp9Umbe8utQjfPn v2VjYyMvlurm9Ol/mjBhWKXT6enTG2Rvly9vqx+dGXU0nVZ02Ncbye8ynVb5q0mllxqpRwoQ1ZlO 69y8ojZUZRW/dyphsqre7azavQFVnk53714VGPi0g0NTd/dWV658pxolJISH95NGH5922vtXI0f2 X7Bg0rhxQ6T9+nX9tyXXr/+wZUvH/fvjrKysvvlmsdaembn9hRf6ODo+3KWLz7vvjuvW7XHzDyGR ctas1+RgevZ8Yt++T6XxP//z9caNH5ItZQ60YUO03uNKDFi9epbeAJqTk2xv30htrHfY167tkBZn 5+atWjUfNWrgL7/slG3CwvrGxf2n2slrr0W8+GJftZ6c/LH6/7ZKnyUZH+VIbt7cWyPpVOZhgwY9 Z+ZojT4vo6dIlgEDen366f8/S6tWvSe/VqNPWe4+evQLLi4tmzRpLL90M4+uLfIQ8iryj3/8zdTb qkaPx2hvMfWkzBy87ESyYps2Tk8++eipUwmyWYcO7o895rlp08LKlYPWJ6X/2NraqJ/KAUhfkkJQ kVte4KUMTe1cZu0zZox9++0/yLNu394tPv4jw/d/rK2tV6yYqdd+x0MdMaL/Bx9M1LZ//fWIJUum 1XhnRh1Np6aGfaPlZjiSq3RqWMJmSl63Q8rNmJgpKiTLPnUXFXqltHv16tKiRbOAAD9TrybaTiox 1NRsPVKAqJF0WlfmFbWhKsvv3d87Bep3OpXXWiktmTGfO5eofZ1AXsvHjAmTSvv736f6+rbXZsxO Tg7z5r0pM3jD/yYPDX1WDV6SPwcP9tf93/G+fbvJvFYGKUl9UsDmH6J16xYTJgw7evRrGQUkNEpj Xt7uoKAe48e/JENDYeE+3Qe9cWOXzIq0D5nIADp8eKgMRjIyysy+uPiA4WHLrvz9ux8/vk6Wfv26 hYQ8I9vIkatEKmegefOHJVGooVMeVGYkd3OWZNoke/v2279XczqVcyUjfoMGD6xb96GZozX6vIye Ilk6dmyvTeM++mhS586PGH3K8kBeXq7Sx2SHx46tNfPo2vI///Op/B6PHFlj9BmZOh6jvcXUkzJz 8PJi+d5742XjZ57pLFHwD38IOXlyvbwgaW97VqgcdPukPHqjRg/KJFgORnLpgQOfyY/kWUgtPPRQ QxXzTO3c1dX5ww//8r//+095SZY+WVKiX3FTp46Wl96XXx509WqS1njHQ12xYoaHh4tKyHJHOQz1 Kcea7cyoo+nU1LBvtNwMR3JTJWym5HU7pO5br7JPtSxdOl3GPfUds7VrP/jhh6/kseR1YejQIFPH oO2kokNNzdYjBYhqTqd1a15RG6qSdApUMp327t01OLiH7vdw0tI2yRx6/foPZRA5dOgLmY9mZGxX RTh2bLjR/V+48I1sJhFU1v/xj7898ICd+g8zaZFdbdy4UPvEo0qnZh4iMvJ5tfHy5TPc3JzNfxZL BinZj3ZBDhlAn3jC++mnfWWwWLXqPTW46B722bP/elztDdj4+I/kphz8jh3LmzRpLGl2y5a/y6Ap O5FDlYFGcsuJE+vv8izJyTf1ruA9SqcNGzaQEVkOb+vWJeaP1vB5mTpF5l9FtKesHkjve1ymHl1b pIfIBhcvbjF8OmaOx1RvMXxS5g/+tdcitC+Ldunio15g5JDkNakS5aDXJ9V/lEjIfOwxT7np4tJS DvWTT2ZLu/mdy8Fo/+Us2+zZs9rolSqki8o+VRi25FBldt648UPS4WX9gw8mPv98z9rQmVEX06mp Yd9MuRl+stewhM2XvG6HNPxg8IEDnzVq9ODKle/qHeqSJdNkumn+08WVGGpqvB4pQFRbOq1z84ra UJWkU8DcyOLt3fbdd8fphgGZZap1GUFkomxnZzt58qiCgn/9X/L33/9DirBHj07PPNNZLSkpK81/ R0jamzVrMmHCMFleeWWQ3P2///tt9clGWdc+96+lU0se4tNP/9PV9Q7pVKKj7Cc9/Vu9D5/IqCdp Uz1l3X2qx9WOR+4oN3fuXHHr1sGHH7aXn44f/9LSpdP/+tdRf/7zYDn4xx/3uvuz5O7eyvCzJfc0 nUZFDZdposzG3nhjqO4TNzxaU8/L8BSZfxXRO8Opqf92DUxTj64tP/74T9lAr9H8r8xMbzF8UhYe /LRpf/L3765dyVOl04qWg16fnDt3gq9v+8WL3xk3bojcfOmlQCmQP/wh5P33oyzfecuWjtHRfzX6 6/7ll539+/eSQ5UXVAv39sc/Dhg1aqCs+Pi0W7v2g9rQmVEX06mpYb9C6dSwhC0secObMuzLNHT6 9D9pLQkJC/z8Onbt6iNLu3ZtzB9DJYaaGq9HChDVlk7r3LyiNlRl1aTTr7766siRI9rNixcvfvnl l3RW1IORRfdzFLJ8/PG7Ulq6G8gw4eTksGjRO7J+5sxGKULDz++ZKsKSkkPyav3mm5F///tUtQQH 95CSlh/9+uv/yIig/U/bkiXTVDq15CEsSac3b+61sbFRY5zeVyNkAFXZUnefKjls375M3dyy5e9y U/3f/5AhAZMm/dHNzVkGUNlA0vtbb/1B7/lW4iwVFe2XI/zuu39U//dOd+xYLg+tvjxp6mgNn5eZ UySvIgsWTNIu6mP0VUQ9kPqShraYf3RZCgv3NW/+8KuvhpsKe0aPx/yUUfdJWXjwRtNpRctBr0/u 2/eptbW17Pazz+bITTmGDh3cW7RodvTo1xbu/OrVJNnm66/fN/MWlvrWn4WHKq+yjRs/lJgYI1N5 dQ3eGu/MqHOvKWaGfTPlZkk6tbDk9W5ev75LHnTo0CDtUmqnTiXI/Fi9+qxc+e4d02mlh5qaqkcK ENWZTuvcvKI2VGXVpFNPT8958+ZpNzdv3ty2bVs6K+rByDJnzhv29o0OHPhM/Xm6vn27aX/oIjn5 Y6k9eUX38+uoXeRWJtOyjfpgRn7+HvWnWUwVoYxTMtvW/RNY6iIZ6j+WZCogw01c3H/OmDFWhiHZ 0sKH0J0EREUNl41NfSlx+fIZugOoPJ3jx9c9+qiHuiaq7j5LSw89+eSjw4eHysPl5CRHRAR26/a4 ms1IYn/4Yfunn/ZVYalRowfl5o8//vMuz5IciaPjw6b+Pti9viqSBGx5eVCfPzF6tIbPy8wpGjzY PzLyeTk5q1a9JyfH6KuILPIovr7tDx78XNZ/+ilefVDW6KPrffTO1tbmgw8mqi9Yyr02blyo7m7q eEz1FqO/LEsO3mg6rWg56PVJeTpNmzbWPresvnqqO7s1tfOAAD95vnL3uXMnSHTXO2PSr2SWoL5Z LV1XZuHqD6tacqhyZtq2bd2ypaM2CNR4Z0ade00xP+ybKje9kdxoCVtY8ro3pd4lG/fo0Un7rIS6 NIvUxdmzm2QAHDEiVLvkgaljqMRQU7P1SAGi+tNpHZpX1IaqJJ0C5kaWX3/9HxkOZOrg6ekiJSoT X+2CaR06uMvLtoeHy4ABvWQz7Q+sh4Y+K2nBy8vV2bm50U9VacugQc9NmvRHvcYnnvBWn4uQXY0c 2V9SnxT5ihUz3d1bWfgQupMASYlynHJf7W1Ybdm2bWmXLj7qP7dkALW6rX17t9dei1CfrtQ77FOn EmRYlEFQ4roclfrfO1kuX95mbW2tfTs3JOSZRx5pp92r0mdpzJiw2bNfr6m/KCOH6u3dVsKSDLVG j9bo8zJ1ipKSYl1cWjZs2CAsrO+cOW+YehW5dGmrtMhvQZKMm5uzuvSI0UfXW6R7SAyTTChnXn71 ckjyImTmeEz1FqNPypKDN5VOK1QOen1S/QeN9r6NNDZq9KD0Cm1jUzsfNixYnQeZB2j/5az7XRrZ T5MmjeXJym/888/nVuhQ/+M/XpXerl6qa0NnRp17TTE/7JsqN72R3FQJW1LyujfVZdWkIpo1a6IW dRjy6A8+2KBNG6fY2P+QsUVdGMnMMVR0qKnZeqQAUSPptK7MK2pDVd7zdLpnz57AwEAHBwcZ0rKy slTj1atXw8PDpdHHxycpKUk1jhw5Mjo6ety4cdJ+48YN+jpqw8iiXV7l0KEvDP/6040buwzfy1Jf Ddcu7lIlyx/+EBIc3KPSDyHDk9FLosXETPnww79U6EjkVOTkJFfoLpU4S3v3fjJ8eOg9+gt15n/X phbDozX1vIyeopKSQxaet+xsI3e35Nd98eKW48fXGf6l0wr9yow+KcsP3sJTZ2apaJ/U2/n167uK ivbLSZA+b+qPvkotnDmz0egfc6t05dZUZ0YdfU0xs5gpN1Mj+d2P0kZ3oh4rP3+PLJYcQ+Uet5rr kQJE7an3WjuvqPGqvOfptGfPnpI5y8vLz58/X1xcrBoDAgLGjBkjEXTJkiW+vr6qsU+fPk5OTvPn zz99+nRZWRl9HXViJnHvlvnz35o8edRnn835059ebNz4IcN3gapk+ec//7sW/jHoDRui9f4ETo2n U5ZqW2pnn6ydnRm8prDc5UIBgnqvB4VZsXTau3fv4ODgCxcuaD89e/aslZVVfHz8iRMnUlNTbW1t MzMzVTodO3YsXRyMLGrZsWP5rFmvvfLKoKlTR+tdco2FdMpCZwavKSwUIKh3CtN4OvX29n7vvfe0 m5s2bZK8qtYllwYGBtrZ2U2ePLmwsFBakpKSbl9cuMczv9u1a5dKpzNnzqSLg5GFhXTKQmcGryks FCCodwqzkum0X79+ISEh2s2VK1dK5tTdIDk52cnJafHixbKelpZ2+4/SbtXbCekUjCwspFMWOjN4 TWGhAEG9U5h3lU7nzp1rb29/8OBBWc/MzOzbt+/UqVPVj1JSUkpKSsrLy/38/GJiYlSjv7+/bKM+ 7nvz5s28vDzSKRhZWEinLHRm8JrCQgGCeqcw7zadFhQURERE3P6rG552dnYBAQE5OTnqRx06dHBw cPDw8BgwYIBspholwYaGhtra2np5eTk7OycnJ5NOwcjCQjploTOD1xQWChDUO4V5t+lUyc7OTk1N zcjI0GvPu81w+/z8/CtXrtCnwcjCQjploTOD1xQWChDUO0tVplOAkYWFdMrCwuQYjDMUIKh3lrqU To/OjKUro7aNLCx1a+F3zUJnBq8pLBQgqHcK06pKfot0ZaB6RkxOAuhaAKh6gBKur0+NdAowEoGu RdcCqHoAlDDpFAC1BroWAKoeACVMOgUYiQC6FkDVA6CE60k65apIQPWg1kDXAkDVA6jHJcxflAEA AAAAkE4BAAAAACCdAgAAAABIpwAAAAAAVFE65Yv1QPWg1kDXAkDVA+CqSOZwUXKgelBroGsBoOoB 8BdlGOAARiLQtQBQ9QAoYdIpAGoNdC0AVD0A0ikDHMBIBLoWAKoeACVc29MpX6wHqge1BroWAKoe AFdFAgAAAACAdAoAAAAAIJ0CAAAAAFBP0mlCQkKsjv/93/+t5qf61VdfHTlyRLt58eLFL7/8Uu/Y tm/fXlxcrHvM+/bto5cAAAAAQB1IpxZ+K7d79+4dO3Yc/bstW7aY2Tg9Pf3ChQtV+1Q9PT3nzZun 3dy8eXPbtm21Y+vUqVNERIS7u7u9vf3u3bu19kmTJtFLUEtwEQvQtQBQ9QC4KpI5Fl7RuEJJb+DA gRMnTqzOdDplyhS13rVr12HDhpFOUQvxBwBA1wJA1QPgL8rcq3Q6cuTImJiY2bNnu7u79+zZc//+ /dI4Z86cxo0bOzg4eHt7b9y4UVquXr0aHh4uLT4+PklJSdp9o6Ojx40bJ+03btzYs2dPYGCgrMuu srKyKp1OJRgPGjSIdApGItC1AFD1ACjheptO+/fv/8Vt33zzjWrs06dP69atJ0yYcOzYMcmfYWFh 0pifnx8UFDR+/HgJpUVFRdISEBAwZswYiaBLlizx9fXV7uvk5DR//vzTp0+XlZVJuJWwWl5efv78 ed3vjlqeTuXh4uLiGjRosH79etIpGIlA1wJA1QOghOttOn388cdH3TZt2jQtYUZGRqr1FStWuLm5 qXXdT/aePXvWysoqPj7+xIkTqamptra2mZmZ6r5jx47V9t+7d+/g4GAz31Y1n04bNmxobW0tD7Rt 2zbdYyadgpEIdC0AVD0ASrhupFPLr4pkmPQkYc6cOVOtx8XFubq6GqbTpKQkCY09evR45ne7du3S u6+QXBoYGGhnZzd58uTCwkLDA/D29n7vvfe0m5s2bZK8qh1bVFRUVlaWh4fHG2+8QTpF7cRFLEDX AkDVA+CqSFWg0uk0LS1N0unWrVvN3FeTnJzs5OS0ePFiwwPo169fSEiIdnPlypUSdLVjU9873blz p42NTWJiIukUAAAAAEinv0VFRfXt21fbzN/fX26qT+3evHkzLy/PMJ2mpKSUlJSUl5f7+fnFxMQY HsDcuXPt7e0PHjwo65mZmbLDqVOn6qVT8dZbb0m+VR8eJp0CAAAAQD1Mp1ZWVta/CwwMNJNOjx49 2qFDB3d3d/UtUMmKoaGhtra2Xl5ezs7OycnJhulUtndwcPDw8BgwYEBBQYHhAUhjRESEHIOnp6ed nV1AQEBOTo5hOpXNvL29g4KCJOjqHbP2XisAAAAAoK6m00q4fPlyWVmZdjM/P//KlStmts+7zfw+ s7OzU1NTMzIy+N0DAAAAQL1Kp3yxHqgqRddyqTVUP7oWQNUDoITrSTrlouRAVZFq2vbUqIxv9lJr qOaOx0kAqHoAlDDpFMC/VZMsa2yeXtu0T+pbH+m9lUqtgRc5AFQ9ANIpAxxQfelUW9bY+Om+lUqt gRc5AFQ9ANIpAxxQA+lU761Uag28yAGg6gGQTu88gWZhYamG5eLX3zMio8pxfRSAqgdACdfhdMr/ xgH36H/CdJctHSN3h0/55tGhie3DT8xbbf6KvgAAAADplHQKVGU6XWv/XErI2yn9o9Y1898z5J0r 2/eXl5RycgAAAEA6JZ0C1ZdOebMUAAAApFPSKVDz6ZQ3SwEAAEA6JZ0CNcz8m6VcxAL3CF0LoOoB UMKkUwBVVnoAXQsAVQ9QwqRTxjuAkQh0LQBUPQBKmHQKMBIBdC0AVD1ACZNOGe8ARiLQtQBQ9QAo YdIpcL/gIhagawGg6gFwVSTSKQAAAACAdAoAAAAAIJ2STgEAAAAApFMAAAAAAOmUdArUDlzEAnQt AFQ9AK6KRDoFah7FBboWAKoeAH9RhnQKMBKBrgWAqgdACZNOAVBcoGsBoOoBkE5JpwAjEehaAKh6 AJQw6RTAv1j+Dfjy8vL169dPnTp10qRJX3zxxa1bt6p70PzqqyNHjmg3L168+OWXX6r1hISE2Nu2 b99eXFysbSPt+/bt47dcy7sWAKoeACVMOgVgqZycnICAAG9v71mzZs2bN69Lly5PPfVUenp6dR6D p6enPLR2c/PmzW3btlXr3bt379SpU0REhLu7u729/e7du7V2ydL8+gAAAO5bpFOgvnn99dfbtWt3 /fp1dbOwsFDS6Ysvvlh70umUKVPUeteuXYcNG0Y6BQAAAOkUqG9yc3Pt7OwmTJig2zh//nwrK6uf fvpJ1keOHLlw4cK3337b2dm5ffv2CQkJapurV6+Gh4c7ODj4+PgkJSWpRtk4JiZm9uzZ7u7uPXv2 3L9/v2rfs2dPYGCgbCztWVlZlU6nAwcOHDRoEOkUAAAApFOgvtm3b58E0U2bNuk2/vDDD9K4bt06 We/Tp4+rq+tHH330448/jh49unnz5qWlpdIeEBAwZsyYGzduLFmyxNfXV91RNm7durVk3WPHjkl2 DQsLU+2SVKOjo8vLy8+fP6/73VHL06mE4bi4uAYNGqxfv550CgAAANIpUJdY8g14yaXa26SakpIS a2vrZcuWqcD5zjvvqPbs7GzZeO/evWfPnpWV+Pj4EydOpKam2traZmZmqo0jIyPVxitWrHBzc1Pr vXv3Dg4OvnDhgqnDMJ9OGzZsKMcjj7ht2zZtG9JpLe9aAKh6AJQw6RRABYrr+PHjkvpiY/9tzEpP T9eioATOmTNnaj9q2bLlwoULk5KSZIMePXo887tdu3bpbRwXF+fq6qrWJZcGBgba2dlNnjy5sLDQ 8DC8vb3fe+893cwseVVLoVFRUVlZWR4eHm+88QbptK50LQBUPQBKmHQKoALFdevWrTZt2rz00ku6 jYsXL7a3t8/OztYLnNeuXZNQunbt2rS0NFnZunWr3t5MpVMlOTnZyclJdm54GP369QsJCdFurly5 UhKvlkLV90537txpY2OTmJhIOuVFDgBVD4ASJp0C9XAk+vTTTxs1avTtt9+qm/v27ZMMOXfuXC1w BgQE5ObmlpaWzps3r3nz5nl5edLu7+/ft29f9WHdmzdvqkZT6TQlJaWkpKS8vNzPzy8mJsbwGOTh JA8fPHhQ1jMzM2XPU6dO1Uun4q233pJjU58iJp3yIgeAqgdAOiWdAvVtJJIk6ejo6OHh0b59+6ZN my5cuFCSpJZO+/fv/8gjj0jUlGT43XffqXaJiKGhoba2tl5eXs7OzsnJyWbSaYcOHRwcHGT/AwYM KCgoMDwAaYyIiLCysvL09LSzs5M8nJOTY5hOZTNvb++goCA5PGmX7a1/p73XCl7kAFD1AEinpFOg dqnQN+Al76WlpZ05c6asrEy3XQVO+enly5e1yKrJz8+/cuWKJfvPu838NtnZ2ampqRkZGfzuql/R tdx71LUA3G8vKAAoYdIpgHtC76pIqK9kKN721KiMb/ZyKgAAAOkUQG20cuXKpKQkzsP9kE5lWWPz 9NqmfVLf+qhCb6UCAACQTgEAVZlOtWWNjR9vpQIAANIpAKCG0ylvpQIAANIpgCoOGCws1bBQfUD9 xlWRAEqYdAqAWkPN/NfGlo6Ru8OnfPPo0MT24SfmraZrAQwRnASAEiadAqDWUH3pdK39cykhb6f0 j1rXzH/PkHeubN9fXlJK1wJAmQOUMOkUALWG6us8um+W6n3RlK4FMERwEgBKmHQKgFpDNXUe3TdL 6VoAKHOAEiadAiCdogaYvyovXQu4z3FVJIASJp0CoNZA1wIAACCdAkQIgK4FAABIpwCoNdC1AAAA SKcAEQKgawEAANIpAGoNdC0AtQNXRQIoYdIpAGoNdC0AtX0QAEAJk04BUGugawFgaguAdMq0BiBC gK5F1wIYBABQwqRTANQa6FoAmNoCIJ0yrQGIEKBr0bWA+wVXRQIoYdIpAGoNdC0AAADSKUCEAOha AACAdAqAWgNdCwAAgHQKECEAupa+kpKSsrIyugQAAKRTANQa6nDXkmj3zTffvPnmm/Pnz9+xY8c9 Otry8vL169dPnTp10qRJX3zxxa1bt/Q2yMzMjI2NvXLlSiV23qdPn5kzZ5rfJiEhQfa/fPnydevW nTt3jv6DeoCrIgGUMOkUALWGetW1+vfv7+fn98EHH/zxj38cMmSIakxPT79w4UKFjsfMXXJycgIC Ary9vWfNmjVv3rwuXbo89dRTsr3uNtOmTbOyspoxY0YlHsuSdNq9e/dOnTpFRER4enra2NjEx8fT hVC/BwEAlDDpFAC1hrrUtc6cOSNRLSMjQ6994MCBEydOrNDxmLnL66+/3q5du+vXr6ubhYWFkk5f fPFFbYOSkpLWrVtLfHVzc7PkM7p6j2VhOp0yZYpa79evX3BwMF0ITG0BUMKkU4Chh1pDbela6enp 1tbWH3/8sW7jnDlzGjdu7ODgIHFx48aN0hITE9OrV68WLVoEBATs379fbTZy5Mjo6Ohx48bJljNm zNC7iyY3N9fOzm7ChAm6jfPnz7eysvrpp5/Uzfj4+JYtWx44cEAat2zZom02YMCAuLg4tb569eoX XnjB6OGpdDp79mx3d/eePXtqR2gqnb722muypd5TuHHjRnZ2trQ4Ozu3atVq1KhROTk5antpHz16 tIuLS5MmTbp06aIar169Gh4eLnf08fFJSkpSjXv27AkMDJRG2X9WVpaZRoCpLUAJk06ZMQOkU9C1 /s3UqVMloL788svXrl1TLfn5+UFBQePHj5cAVlRUJC3r1q07cuSIrA8fPnzo0KFqM8mETk5OkjNP nz4t0U7vLpp9+/ZJ5ty0aZNu4w8//CCNslt1MzQ0VEXHbt26DR48WNusY8eOixYtUusLFizo3Lmz 0cOTI2ndurUE4GPHjkliDAsLM5NOz5w507Rp01dffVXvKZSVlclu/f39T9zWr1+/kJAQdV/J5F5e Xps3by4uLj5+/LjWOGbMGHniS5Ys8fX1VY2SjSXulpeXnz9/XjY20wgwtQUoYdIpM2aAdAq6lr6E hIRWrVq5uLjs3r1btZj6mO7SpUs9PDy0dDp27FjtR6buIrlU921SpaSkRCLxsmXLZP3nn3+2tbWV 0CjrsbGxDzzwgPYGo9F0+puxT/ZGRkaq9RUrVri5uRlNp56eno8++qg8rgTgvLw8vadw7tw5OU7t jV85J3JTju3s2bOyIo+uuzfVGB8fLzk2NTVVjj8zM1Pae/fuHRwcrPf9W6ONwN3jqkgAJUw6BUCt oR52rZycnP79+z/00EP5+fmG8W/Dhg1+fn5db2vXrp2WCXW/7WkqnR4/flyCnMRO3cb09HRp3LZt m6zLTpo1azbhtldeeUXa33///YqmU+1I4uLiXF1djabTIUOGpKSk6H7JVveOSUlJ8tDaTy9duiQ3 k5OTVfvhw4d196Yae/To8czvdu3aJe0SQQMDA+3s7CZPnlxYWKg2NtoIAADplBkzQDoFXcu4n3/+ Wfvap278O336tCQrlSRXrVpV0XR669atNm3avPTSS7qNixcvtre3z87OLi0tlTD55ptvLvldcHCw j4+Plk6jo6PV+vTp0+8ynWrfOzV6x5MnT8rT/+6779TNb7/9Vm6eOXMmLS1NVpYuXap7R9W4detW o2dSMq2Tk5M8xzs2AgBAOmXGDJBOQdf6lxMnTuzcuVP99dGVK1dKCj179qysR0VF9e3bV22zZ88e aT937lxmZuaIESMcHByMplPdu+j59NNPGzVqJHlP3dy3b5/ktLlz58p6YmJiixYtdL+Nqa6NpN6K HDx4cGRkZFFR0erVqx9++GEtneo9VpWk07KysieffHL48OF5eXm5ubkRERHdunUrLy+XH8lj+fr6 Hjp0SNZPnTqlrirs7+8v7erzujdv3lQfFU5JSSkpKZF7+fn5xcTEqD0bbQQAgHTKjBkgnYKu9X8S EhIkNzZp0qRDhw6S37744gvVfvToUWlxd3dXb5mGhYU9+OCDbdq0Wb58efPmzdWFkfTSqd5d9Eho dHR09PDwaN++fdOmTRcuXKiC36BBgyZNmqS38RNPPDFq1ChZ2bFjh4uLS8OGDeUAJM1q6VTvsaok nf52+11iSaQSg+3t7Z9++mn1VVhx+fJl2VIyszwFNzc3dSkmyeqhoaG2trZeXl7Ozs7JycnSKEcl 6V2e5oABAwoKCtTdjTYCAEA6ZcYMkE5B1/o3ZWVlaWlphn/yVKUy7a+PZmdnq/Wbt5nam+5d9Egc lQeSyGfJXzTVlJaW5ubmVvSx7oY8U6OP+Msvvxi25+fnX7lyRbcl7za9zYw2AneJqyIBlDDpFAC1 BroWgNo+CACghEmnAKg10LUAMLUFQDplWgMQIUDXomsBDAIAKGHSKQBqDXQtAExtAZBOmdYARAjc v11LbppfOGNAPcNVkQBKmHQKgFpDLU2n5jeuJQu/OAAA6jfSKUA6Bem0DvQ0OjwAAKRTZswA6RSk U9IpAAAgnQJECGoNpFM6PAAApFNmzADpFKRT0ilQz3BVJIASJp0CoNZAOiWdAhQUAEqYdAqQTgHS KQAKCqCESacAqDWQTnklBigoAJQw6RQgnQJVn06LruXySgwwtQVACZNOAdIpUDPptCS/4MdpS+Kd gqutH9LhgSrEVZEASph0CoBaQ51Pp1k7Dn3fa+wa2x7SrhbSKQAAIJ0CpFOgmtKp7pulegvpFAAA kE4B0ilQHelU781S0ikAACCdAqRTag3Vmk4ztuw1FUqrf+EXBwAA6ZQZM0A6xX2aTtVPTy34crP3 S/Etgze4DiQ0AvUAV0UCKGHSKQBqDXUynaqVrB2p+1+e9XWjXontw79+qBfpFKivry8AKGHSKQBq DbU6nSpF13L13krlfAJMbQFQwqRTgHQKVHc61ai3UumHAFNbAJQw6RQgnVJrqMl0qhRdy+V8Akxt AVDCpFOAdArUcDoFUBdxVSSAEiadAqDWQDoFAAAgnQKkU4B0CgAASKcAqDWQTgEAAEinAOkUIJ0C AADSKQBqDaRTALUDV0UCKGHSKQBqDaRTALX99QUAJUw6BUCtgXQKgKktANIpM2aAdArSKT0N4PUF ACVMOgVArYF0CoCpLQDSKTNmgHQK0ik9DbhfcFUkgBImnQKg1kA6BQAAIJ0CpFOzysvLb926VY/P Z0lJSVlZGf2KdAoAAEinAKqj1hISEmJv2759e3FxseUPt3btWgcHB7WemJiYmppaC89JZmamPLUr V65U4r59+vSZOXOmXmNhYWGsgYyMDNIpozoAACCdArirWuvevXunTp0iIiLc3d3t7e13795diXQ6 bNiwBQsW3OXxp6enX7hwoaI/Mm/atGlWVlYzZsyoxAEYTad5eXmjdXTt2lX2XzuTOekUAACQTkmn QB1Lp1OmTFHrkrUkZ1YinVaJgQMHTpw4saI/MqOkpKR169be3t5ubm6WfEZX71GMplNdOTk5Li4u I0aMuN+6FqM6cL/hqkgAJUw6BVDd6VTi2aBBg9T61atXw8PDJX/6+PgkJSWpxmvXrr3wwguOjo5d unSZNGmSlk5Hjhy5aNEibT06OnrcuHHy0xs3bhjdT3Z29ujRoyXaNWnSRHYlLXPmzGncuLFsJmFy 48aNukdo+CO5uzyKs7Nzq1atRo0aJSnR6FOLj49v2bLlgQMHrKystmzZorUPGDAgLi5Ora9evVqe kdFHUel09uzZ7u7uPXv23L9/v97+IyMjJffm5uaSThnVgfv59QUAJUw6BVCV6VQypAS2Bg0arF+/ XrUHBASMGTNG4uWSJUt8fX1V4/PPPx8cHHzhwoVLly5JxtPSqe7bjLLu5OQ0f/7806dPl5WVGd2P NHp5eW3evLm4uPj48ePSkp+fHxQUNH78eDmSoqIi3SM0/JHc9Pf3P3Fbv379QkJCjD610NBQFby7 des2ePBgrb1jx45all6wYEHnzp2NPoo8kdatW0+YMOHYsWMSsMPCwnR3vmbNGmtr6+3bt9+HXYtR HeD1BQAlTDoFcE/SacOGDSVoWVlZbdu2TTWePXtWbsbHx0v8S01NtbW1zczMvHjxojRKpFTb6H6y Vy+djh071sx+VKPh91Qt/GTvuXPn5O7a+6sJCQly8+eff9a7i7TIw505c0bWY2NjH3jggaysLDPp 9Ddjn+yNjIxU6ytWrHBzc9N+lJGR4ejoKMH1/uxajOoAry8AKGHSKYB7kk6joqIkuXl4eLzxxhuq MSkpSSJfjx49nvndrl27du7cKY3a9WnNpFNt3eh+VOPhw4crl07V3bXDuHTpktxMTk7Wu4scQ7Nm zSbc9sorr8g277//fkXTqfZE4uLiXF1dtR+FhIQ88sgjBQUFpFNGdYDXFwCUMOkUQJWlU/XxVwmf NjY2iYmJsp6WliZxbuvWrbpbZmZmWltb79271/J0anQ/qnHp0qWVS6cnT56Uu3/33Xfq5rfffis3 1XukmtLSUgmTb7755pLfBQcH+/j4aOk0OjparU+fPr2i6XTZsmV2dnYHDhy4b7sWozpwv+GqSAAl TDoFUK3pVLz11ltOTk6SQmXd39+/b9++6i+s3Lx5My8vT1aefPLJkSNH5uTkHDx48IknnrhjOjW1 H2nx9fU9dOiQrJ86dUpdUDcqKkrajR6k7o9kYzmM4cOHy65yc3MjIiK6detWXl6uu71k7BYtWuj+ +VZ1baRdu3bJ+uDBgyMjI4uKilavXv3www9r6VTvAIymU4nWjRs3li2v65AwTDplVAcAAKRTAFWW TgsKCry9vYOCgiTsSUYNDQ21tbX18vJydnZWH53dvHlz06ZNpVGy5aJFiyxJp0b3c/nyZdlM4qKj o6Obm5u6CtHRo0c7dOjg7u6uff1Vo/ej06dPSyKVYGlvb//000/rvXEqBg0aNGnSJL1GidOjRo2S lR07dri4uDRs2DAsLGzu3LlaOtV7FKPpNDY21srAzp07SaeM6gAAgHQK4B7WWn5+/pUrV3RbSkpK 9Foqtx/xyy+/GP45Fgmupv42qd6PsrOzK/3XXEpLS03d18wB0LUY1QEAAOkUwL2ttaJruZxAkE4B AADpFEDNpNOS/IIfpy2JdwqmEkE6BWAKV0UCKGHSKYB7WGtZOw5932vsGtse0q4WTiBIpwCoa4AS Jp0CqKZ0qvtmqd7CCQTpFAB1DVDCpFMA1ZFO9d4sJZ2CdAqAdApQwqRTxjugWoeejC17TYVSFhZL Fr2eZvnGAJjaAqCESacAQ4/+T08t+HKz90vxLYM3uA4kUYBhHICFuCoSQAmTTgHck1rL2pG6/+VZ Xzfqldg+/OuHepFOwTAOAABIp0xrgBqLEEXXcvXeSuUEgmEcAACQTgHUWIRQb6VSiWAYBwAApFOm NUDNR4iia7mcQDCMAwAA0ikAIgToWgBqKa6KBFDCpFMA1BroWgBq+yAAgBImnQKg1kDXAsDUFgDp lGkNQIQAXYuuBTAIAKCESacAqDXQtQAwtQVAOmVaAxAhQNeiawH3C66KBFDCpFMA1BroWgAAAKRT gAgB0LUAAADpFAC1BroWAAAA6RQgQgB0LQAAQDoFQK2BrgWgduCqSAAlTDoFQK2BrgWgtg8CAChh 0ikAag10LQBMbQGQTpnWAESIalFeXn7r1i1+uXQtAExtAVDCpFOg/kcISYDr16+fOnXqpEmTvvji i1qVBteuXevg4KDWExMTU1NT7+EJ/OqrI0eOaDcvXrz45ZdfqvWEhITY27Zv315cXKxtI+379u2j a1F9AFNbAJQw6RTA3dZaTk5OQECAt7f3rFmz5s2b16VLl6eeeio9Pb0WptNhw4YtWLDgLncoT+3C hQtGf+Tp6SlnQLu5efPmtm3bqvXu3bt36tQpIiLC3d3d3t5+9+7dWrtEeroW1QfUb1wVCaCESacA qqPWXn/99Xbt2l2/fl3dLCwslHT64osv1sJ0WiUGDhw4ceLESqTTKVOmqPWuXbtKTiadMowDAADS KYAqq7Xc3Fw7O7sJEyboNs6fP9/Kyuqnn36S9ZEjRy5cuPDtt992dnZu3759QkKC2ubq1avh4eGS G318fJKSklSjbBwTEzN79mx3d/eePXvu37/f8BFlm+jo6HHjxsl9b9y4YXQ/165de+GFFxwdHbt0 6SLZT0unct9FixZZvp/s7OzRo0e7uLg0adJEdiUtc+bMady4sWzm7e29cePGyqVTybeDBg0inTKM AwAA0imAKqu1ffv2SRDdtGmTbuMPP/wgjevWrZP1Pn36uLq6fvTRRz/++KMkvebNm5eWlkp7QEDA mDFjJBYuWbLE19dX3VE2bt26tWTdY8eOSVYMCwszfETZxsnJSQLw6dOny8rKjO7n+eefDw4OvnDh wqVLlwYMGKClU7nvzJkzLd+PNHp5eUnILC4uPn78uLTk5+cHBQWNHz9e0mxRUVFF06ncKy4urkGD BuvXryedMowDAADSKYAqqzXJpdrbpJqSkhJra+tly5apEPjOO++o9uzsbNl47969Z8+elZX4+PgT J06kpqba2tpmZmaqjSMjI9XGK1ascHNzM5pOx44dq9aN7ufixYvSKMlQbaP7yV69dGp+P6rR8Huq lf5kb8OGDeW0yD63bdumbUM6ZRgHAACkUwBVUGvHjx+XuBUb+2/flU9PT9cymG4gFC1btly4cGFS UpJs0KNHj2d+t2vXLr2N4+LiXF1djaZTbRuj+9m5c6c0ZmRk3DGdmt+Pajx8+LDl6dTb2/u9997T je6SV7UUGhUVlZWV5eHh8cYbb5BOGcaB+wpXRQIoYdIpgHtea7du3WrTps1LL72k27h48WJ7e/vs 7Gy9EHjt2jXJexIX09LSZGXr1q1mkqcl6dTofjIzM62trffu3Wt5OjW6H9W4dOlSy9Npv379QkJC tJsrV66UoKulUPW9UwnPNjY2iYmJpFOGcYDXFwCUMOkUQFXW2qefftqoUaNvv/1W3dy3b5+Tk9Pc uXO1EBgQEJCbm1taWjpv3rzmzZvn5eVJu7+/f9++fdWfZrl586ZqrGg6NbWfJ598cuTIkTk5OQcP HnziiSfumE5N7UdafH19Dx06JOunTp0qKyuTlaioKGk3eirkWUsslwdVIVk2mzp1ql46FW+99Zac IvVhZtIpwzjA6wsASph0CqDKak2SpKOjo4eHR/v27Zs2bbpw4cLy8nItBPbv3/+RRx6RqCmR7Lvv vlPtks1CQ0NtbW29vLycnZ2Tk5Mrl06N7mfz5s1yGNIo2XLRokWWpFOj+7l8+bJsZmVlJc/Ozc1N XQbp6NGjHTp0cHd31/36qFJQUBARESHbe3p62tnZSSyXhGyYTmUzb2/voKAgOUvSLttb/057r5Wu BYCpLQBKmHQKMPRU5qcStNLS0s6cOaPeYNQLk/JTSXpaZNXk5+dfuXLl7o/ccD8lJSWV2LPR4/nl l19yc3P1GuXp6D1TTXZ2dmpqqvbFVzCMA/VS0bVcprYAr+OkU8Y7oC5FCL23KEHXYhgH6k1db3tq VMY3ey3ZmKsiAXUaV0ViWgPUkwixcuXKpKQkzi1di2EcqH91Lcsam6fXNu2T+tZHFXorFQBIpwCo NdC1AFRlOtWWNTZ+lr+VCgCkUwDUGuhaAO5JOuWtVACkU6Y1QLVGCBYWFhYWlipZeM0FQDoFQK2B rgWgaupad9nSMXJ3+JRvHh2a2D78xLzVVD1Qn3BVJKY1ABECdC0AtT2drrV/LiXk7ZT+Ueua+e8Z 8s6V7fvLS0qpeuC+eh0nnTLAAUQI0LUA1HBd675ZqvdFU6oeIJ2STgEQIUDXAlBNda37ZilVD5BO SacMcAARAnQtADXA/FV5qXqAdEo6BUCEAF0LAFUPoCpxVSQGOIDJBOhaAKh6ACCdAkwmqDXQtQBQ 9QBIpwxwAJMJ0LUAUPUAQDoFmExQa6BrAaDqAZBOGeAAJhOgawGg6gHUDlwViQEOYDIBuhYAqh5A ba9o0ikDHMBkAnQtAFQ9ANIp6RRgMgHQtQBQ9QAVTTplgAOYTICuBYCqB0A6JZ0CTCYAuhYAqh64 X3BVJAY4gMkE6FoAqHoAIJ0CTCaoNdC1AFD1AEinDHAAk4kaV1JSUlZWVucOOysrKycnh64FgKoH ANIpcN9NJhISEmJjY5cvX75u3bpz587VqmeUmZkpx3blypVK3LdPnz4zZ840+nyTkpJ0WxITE3/6 6SdZKSwsjDWQkZGhtwfZPjU1tcqfbHFxcVBQkJeXl6ur68mTJ5mnAqDqAYB0Ctxfk4nu3bt36tQp IiLC09PTxsYmPj6+2g44PT39woULZjaYNm2alZXVjBkzKrE3U+lUnu9DDz2UlpamtTz33HMSzmUl Ly9vtI6uXbvKoxsG0WHDhi1YsOAun5qhbdu2tW3blnkqAKoeQNXiqkgMcEBdSqdTpkxR6/369QsO Dq62Ax44cODEiRNN/bSkpKR169be3t5ubm6WfEZXb29m0qmtra38tLy8XC+d6srJyXFxcRkxYsS9 eGpGydH27duXeSoAqh5AdVY06ZQBDqil6fS1115zd3eXlZEjR0ZHR48bN87BweHGjRtXr14NDw+X dR8fH+1jsXv27AkMDJRGuUtWVpZqNLql7C0mJmb27NmyZc+ePffv3y+Nc+bMady4sWwp+XPjxo2G BxYfH9+yZcsDBw5YWVlt2bJFax8wYEBcXJxaX7169QsvvGB0byqd6j2oer5/+ctf7Ozsli1bZiad RkZGSirOzc01PDB5OosWLarQUzN1WrST/OGHHzo6OjZq1Ejuog5GdturV68WLVoEBARoB5+dnT16 9GiJzU2aNOnSpYuZc848FQBVD4B0ygAH1NV0eubMmaZNm7766qsq2jk5Oc2fP//06dNlZWUSkMaM GSMxdcmSJb6+vuqOEsYkXJWXl58/f764uFg1Gt1S9ta6desJEyYcO3ZMclRYWJg05ufnBwUFjR8/ XsJVUVGR4YGFhoaqA+vWrdvgwYO19o4dO2rhcMGCBZ07dza6N6MPqp7v559/Pm3aNHmy6enpRtPp mjVrrK2tt2/fbvSM6b4ra+FTM3VatJMsd4mKinr22WflLgUFBfLTdevWHTlyRO4+fPjwoUOHaqfX y8tr8+bNcsKPHz9u5pwzTwVA1QMgnTLAAXUvnXp6ej766KOSxyQE5uXlqeA0duxYtcHZs2etrKzi 4+NPnDiRmppqa2ubmZkp7b179w4ODtb9dqWpLWVvkZGRapsVK1a4ubmpdTMff/3555/l7hKYZT02 NvaBBx7Q3p41mk5/M/bJXqMPqtKppL7HHnusf//+huk0IyPD0dFRAqepM6mXTu/41MycFu0ki7/9 7W/9+vUzfLilS5d6eHho+9H7yqupnTNPBUDVAyCdMsABdS+dDhkyJCUlRffitLoBLCkpSfJPjx49 nvndrl27pF1yaWBgoJ2d3eTJkwsLC81sqbu3uLg4V1fXO6ZT2b5Zs2YTbnvllVdkt++//35F06nR B1XpVFb27dtnY2Pz2Wef6aXTkJCQRx55RL2BaUk6veNTs+S0GKbTDRs2+Pn5db2tXbt22n4OHz6s ezCmds48FQBVD0DhqkgMcEBdSqfa906NBrC0tDTJP1u3bjV69+TkZCcnp8WLF5vZsqLptLS0VLZ5 8803l/wuODjYx8dHS6fR0dFqffr06ZVOp0K2b9GixeOPP66l02XLlknePnDggJkzWdF0aslp0Uun p0+flsPYtm2brK9atUqlU7WfpUuX6u7E/G+HeSoAqh5APUY6Be67dCr8/f379u2rPsR78+ZN9enf lJSUkpKS8vJyPz+/mJgYM1uainBRUVFGr1KbmJgooVH7LqtQ10ZS7woOHjw4MjKyqKho9erVDz/8 sJZO9fZmSTotKCho37697FmlU0l6jRs3lv1c1yFRuRLpVO9g7nha9NLpnj17JJ2eO3cuMzNzxIgR Dg4Oql124uvre+jQIVk/deqUupSx0Z0zTwVA1QMgnTLAAfUwnUpGCg0NtbW19fLycnZ2Tk5OlsYO HTpIavLw8BgwYID2OVijW5qKcEePHpWduLu7qzcJNYMGDZo0aZLeIT3xxBOjRo2SlR07dri4uDRs 2DAsLGzu3LlaOtXbmyXp9Lfb7/1aW1urdBobG2tlYOfOnZVIp3oHc8fT8pvBJ3vl2T344INt2rSR Y2vevLm6MNLly5flXnJUjo6Obm5u6pJLRnfOPBUAVQ+AdMoAB9TJyUTRtdw77j8/P//KlSu6LXm3 WbKlGZK4LPlzprpKS0uN/q2Xyu3t3tE7mAqdlt9u//0Ydfebt2ntv/zyi+HTr+jOGcYBUPUASKcM cEAtmkyU5Bf8OG1JvFMwlQiGcQBUPVAvcVUkBjigtk8msnYc+r7X2DW2PaRdLZxAMIwDoOqB+62i SacMcECNTSZ03yzVWziBYBgHQNUDpFPSKYDqmEzovVlKOgXDOACqHiCdkk4Z4IBqHXoytuw1FUpZ WFhYWFgq9F+WTN4A0inpFMDd1tqpBV9u9n4pvmXwBteBvHcKhnEAVD1wP+CqSAxwQO2dTGTtSN3/ 8qyvG/VKbB/+9UO9SKdgGAdA1QMgnTLAATU2mSi6lqv3VionEAzjAKh6AKRTADU2mVBvpVKJYBgH QNUDIJ0ywAE1P5koupbLCQTDOACqHgDpFACTCdC1AFD1AKoeV0VigAOYTICuBYCqB1DbK5p0ygAH MJkAXQsAVQ+AdEo6BZhMAHQtAFQ9QEWTThngACYToGsBoOoBkE5JpwCTCYCuBYCqB+4XXBWJAQ5g MgG6FgCqHgBIpwCTCWoNdC0AVD0A0ikDHMBkAnQtAFQ9AJBOASYT1BroWgCoegCkUwY4gMkE6FoA qHoAtQNXRWKAA5hMgK4FgKoHUNsrmnTKAAcwmQBdCwBVD4B0SjqtUSUlJWVlZXXusLOysnJycqht JhOga9G1AKqeqgdIp/ddOk1ISIiNjV2+fPm6devOnTtXq85CZmamHNuVK1cqcd8+ffrMnDnT6PNN SkrSbUlMTPzpp59kpbCwMNZARkaG3h5k+9TU1Cp/ssXFxUFBQV5eXq6uridPnqS8mUyArkXXAqh6 ThFAOr2/0mn37t07deoUERHh6elpY2MTHx9fbU8yPT39woULZjaYNm2alZXVjBkzKrE3U+lUnu9D Dz2UlpamtTz33HMSzmUlLy9vtI6uXbvKoxsG0WHDhi1YsOAun5qhbdu2tW3blqpmMgG6Fl0LoOqp eqAu4qpIVZNOp0yZotb79esXHBxcbU9y4MCBEydONPXTkpKS1q1be3t7u7m5WfIZXb29mUmntra2 8tPy8nK9dKorJyfHxcVlxIgR9+KpGSVH27dvX6qayQToWnQtgKqn6gGQTn977bXX3N3dZWXkyJHR 0dHjxo1zcHC4cePG1atXw8PDZd3Hx0f7WOyePXsCAwOlUe6SlZWlGo1uKXuLiYmZPXu2bNmzZ8/9 +/dL45w5cxo3bixbSv7cuHGj4YHFx8e3bNnywIEDVlZWW7Zs0doHDBgQFxen1levXv3CCy8Y3ZtK p3oPqp7vX/7yFzs7u2XLlplJp5GRkZKKc3NzDQ9Mns6iRYsq9NRMnRbtJH/44YeOjo6NGjWSu6iD kd326tWrRYsWAQEB2sFnZ2ePHj1aYnOTJk26dOli5pyDyQToWgCoegCoq+n0zJkzTZs2ffXVV1W0 c3Jymj9//unTp8vKyiQgjRkzRmLqkiVLfH191R0ljEm4Ki8vP3/+fHFxsWo0uqXsrXXr1hMmTDh2 7JjkqLCwMGnMz88PCgoaP368hKuioiLDAwsNDVUH1q1bt8GDB2vtHTt21MLhggULOnfubHRvRh9U Pd/PP/982rRp8mTT09ONptM1a9ZYW1tv377d6BnTfVfWwqdm6rRoJ1nuEhUV9eyzz8pdCgoK5Kfr 1q07cuSI3H348OFDhw7VTq+Xl9fmzZvlhB8/ftzMOQeTCdC1AFD1AFD30qmnp+ejjz4qeUxCYF5e ngpOY8eOVRucPXvWysoqPj7+xIkTqamptra2mZmZ0t67d+/g4GDdb1ea2lL2FhkZqbZZsWKFm5ub Wjfz8deff/5Z7i6BWdZjY2MfeOAB7e1Zo+n0N2Of7DX6oCqdSup77LHH+vfvb5hOMzIyHB0dJXCa OpN66fSOT83MadFOsvjb3/7Wr18/w4dbunSph4eHth+9r7ya2jmYTICuBYCqB4C6l06HDBmSkpKi e3Fa3QCWlJQk+adHjx7P/G7Xrl3SLrk0MDDQzs5u8uTJhYWFZrbU3VtcXJyrq+sd06ls36xZswm3 vfLKK7Lb999/v6Lp1OiDqnQqK/v27bOxsfnss8/00mlISMgjjzyi3sC0JJ3e8alZcloM0+mGDRv8 /Py63tauXTttP4cPH9Y9GFM7B5MJ0LUAUPUAqhNXRaqadKp979RoAEtLS5P8s3XrVqN3T05OdnJy Wrx4sZktK5pOS0tLZZs333xzye+Cg4N9fHy0dBodHa3Wp0+fXul0KmT7Fi1aPP7441o6XbZsmeTt AwcOmDmTFU2nlpwWvXR6+vRpOYxt27bJ+qpVq1Q6VftZunSp7k7M/3bAZAJ0LQBUPYDaUNGk06pJ p8Lf379v377qQ7w3b95Un/5NSUkpKSkpLy/38/OLiYkxs6WpCBcVFWX0KrWJiYkSGrXvsgp1bST1 ruDgwYMjIyOLiopWr1798MMPa+lUb2+WpNOCgoL27dvLnlU6laTXuHFj2c91HRKVK5FO9Q7mjqdF L53u2bNH0um5c+cyMzNHjBjh4OCg2mUnvr6+hw4dkvVTp06pSxkb3TmYTICuBYCqB0A6rYfpVDJS aGiora2tl5eXs7NzcnKyNHbo0EFSk4eHx4ABA7TPwRrd0lSEO3r0qOzE3d1dvUmoGTRo0KRJk/QO 6Yknnhg1apSs7Nixw8XFpWHDhmFhYXPnztXSqd7eLEmnv91+79fa2lql09jYWCsDO3furEQ61TuY O56W3ww+2SvP7sEHH2zTpo0cW/PmzdWFkS5fviz3kqNydHR0c3NTl1wyunMwmQBdCwBVD4B0WsfS qeXy8/OvXLmi25J3myVbmiGJy5I/Z6qrtLTU6N96qdze7h29g6nQafnt9t+PUXe/eZvW/ssvvxg+ /YruHEwmQNcCQNUDIJ3WxnRadC2X/gQwmQBdCwBVD6ByuCrS3Q5wJfkFP05bEu8UzPAHMJkAXQsA VQ8ANZBOs3Yc+r7X2DW2PaRdLZx0gMkE6FoAqHoAqKZ0qvtmqd7CSQeYTICuBYCqB4DqSKd6b5aS TgEmE6BrAaDqAaBa02nGlr2mQikLC0slFiYTYJ4KgKoHoIurIlVsgDu14MvN3i/Ftwze4DqQ904B JhOgawGg6gFUT0WTTo3/NGtH6v6XZ33dqFdi+/CvH+pFOgWYTICuBYCqB0A6rYF0qhRdy9V7K5X+ BDCZAF0LAFUPgHRa3elUo95KZfgDmEyArgWAqgdAOq3JdKoUXculPwFMJkDXAkDVA6gcrorEAAcw mQBdCwBVDwCkU4DJBLUGuhYAqh4A6ZQBDmAyAboWAKoeAEinAJMJag10LQBUPQDSKQMcwGQCdC0A VD2A2oGrIjHAAUwmQNcCQNUDqO0VTTplgAOYTICuBYCqB0A6JZ0CTCYAuhYAqh6gokmnDHAAkwnQ tQBQ9QBIp6RTgMkEQNcCQNUD9wuuisQABzCZAF0LAFUPAKRTgMkEtQa6FgCqHgDplAHOvPLy8lu3 blXDA5WUlJSVldXFp1M9R17Pft3UGuhaAKh6AKTTezLAJSQkxMbGLl++fN26defOnatPJ3Ht2rUO Dg53v5/ExMTU1FQzG/Tp02fmzJl15elU4ZHf8cxYmCpjYmJq1fn55JNPcnNzmUyAeSoAqh4AqjWd du/evVOnThEREZ6enjY2NvHx8dX2JNPT0y9cuFAL45zegQ0bNmzBggX1I53qPbW7PPI7nhlLvPPO O59++mmtSqcnT558/vnnS0pKmEyAeSoAqh6AhbgqUtWk0ylTpqj1fv36BQcHV9uTHDhw4MSJE2th nKvogdWhdKr31KrnyM0/qWeffbb2nB/NX//6VzN9gMkEmKcCoOoB3D81WzPp9LXXXnN3d5eVkSNH RkdHjxs3Tqb7N27cuHr1anh4uKz7+PgkJSWpjffs2RMYGCiNcpesrCzVaHRL2VtMTMzs2bNly549 e+7fv18a58yZ07hxY9nS29t748aNekeVnZ09evRoFxeXJk2adOnSRdvPHY/q2rVrL7zwgqOjo9xr 0qRJWly5mwOTzRYtWqTuItv36tWrRYsWAQEBanu9jGf0tOgyugejR2Lm6dxxhwMGDIiLi1Prq1ev lp0YfWrqyA0fV86/HJKzs3OrVq1GjRqVk5Nj9FegnZmSkhLvf/fuu++aOu26JJp+8sknFXpQ3bvf /a/75ZdfnjZtmm4o/a//+i9ZOXPmjL29/a+//spkAsxTAVD1AEin1Z1OZTretGnTV199VYUWJyen +fPnnz59uqysTGLPmDFjJBgsWbLE19dX3VHm95IZysvLz58/X1xcrBqNbil7a9269YQJE44dOyaZ ISwsTBrz8/ODgoLGjx8vQaKoqEjvqGQ/Xl5emzdvlj0fP35c288dj+r5558PDg6+cOHCpUuXJKFp ceVuDkw3fK5bt+7IkSPSPnz48KFDhxqmU6OnRZepPRgeiZmnc8cdduzYUUvUCxYs6Ny5s6mnZvRx ZTN/f/8Tt/Xr1y8kJMTor0D3iV/93bJlyxo0aLBjxw5Tp12Tl5dnZWW1e/fuCj2o7h7u/tct0b1Z s2aFhYWyfv36dUnvR48eVXnb1tZ269atTCbAPBUAVQ+AdFp96dTT0/PRRx+1trYePHiwBAY1jx87 dqza4OzZsxIh4uPjJTOkpqbKlD0zM1Pae/furYKBtitTW8reIiMj1TYrVqxwc3NT66Y+QKv2Y/iF xjse1cWLF6VRMq3aRvuo510emNGPvy5dutTDw8NwA8PTYoreHgyPxNTTsWSHRtOp0adm+Ljnzp2T x9Xe0E5ISJCbP//8s96vwOiZOXjwYKNGjVatWmXmtGuOHz8uG1y5cqVCD6qpkl/3r7/+2rRp088/ /1zW5Yz17NlT27/URWxsLJMJME8FQNUDIJ1WXzodMmRISkpKRkaG0dSRlJQkc/0ePXo887tdu3ZJ uwSwwMBAOzu7yZMnq7eeTG2pu7e4uDhXV1fz6VTt5/Dhw4bp1PxR7dy5Uxq1J6LFlbs8MN3NNmzY 4Ofn1/W2du3aGW5geFr03HEP2pGYejqW7NDydGr4uOp0aY976dIluZmcnGwYR/VuSphs1arV9OnT zfcczcmTJ2UD2X+FHlRTVb/uP//5z/7+/rLy2GOPaR8zFu7u7h9//DGTCTBPBUDVA7AEV0WqmnSq fe/UaOpIS0uTub6pjzhKfnByclq8eLGZLSuaTtV+li5dWtGjyszMtLa23rt3r15cucsD0zY7ffq0 xM5t27bJ+qpVq4xmS8PTosuSPWhHYurpWLJDSafR0dFqXeJihdKpCo3fffedav/222/l5pkzZ8yn 0xs3bsiDDh06tLy83JKe89vt9y1tbGxUBLX8Qav8133w4EHZj+RSubv2HwrFxcVybN9//z2TCTBP BUDVA7jP1aJ0Kvz9/fv27as+rXrz5k316d+UlJSSkhKJIn5+ftrfqzS6palUEBUVJRsbPSpp9/X1 PXTokKyfOnVKfdvQkqN68sknR44c+f/Yu/u4qOr8//9cWF6RV4h4ASTgZSpoLqK1lMqVF6h5EWrI jXTV1K0MP6Spu7rmlrp+VlRKWym1tG27JYGC62WoGK5m9HG11QIlFQUVAhVTcAB/ry/n1/nMZ+bM MCAMII/7bf6YOZw5533OvF9v3k/PcMzPz5fI4e3trca5h2mYulpqaqpEwczMTMlFU6ZMUTeuvx3N 06KyZAv6LTF1OBVucPz48ZMnTy4qKtq6dWvLli3VdGrq0PT3K2db9hsWFiZnqaCgIDQ01MfHR8mc ptKpHHJwcPCgQYMMLhdrnnZ9QUFBH374YaV2qq9aPm7h5eXVtGnTuXPnqkvOnj3bpk0bzb8cZjIB 5qkAqHoApNNaS6eSfEaMGGFvb+/p6ens7Kxc7OratauEAXd395CQkLt375pZ01QqOHPmjGzEzc1N ufSn7+rVq/IuGxsbSQiurq7Gdycyta/du3e3aNFCFkq4jYmJUePKwzRMf7WxY8c2adKkY8eOsbGx jo6Oyl2I9FfQPC36KtyCfktMHU6FGzx06FCnTp0aN24sP3333XfVdGrm0PT3m56eLuFQYq2Dg8PA gQOVa5hm0unx48flw2rWrFmrX0VERJg67foOHDjQr18/5X8WtXCn+qrl435Qft9jab8kUnXJ9OnT //znPzOZAPNUAFQ9AFgvnVqusLBQuYGN6nY5S9Y0Q4KowY1YVT///HNBQUFlWyVRx9Teq6VheXl5 yvI75YxXMHVaLN+ChYdjfoMlJSWmzp6Zc26w2QrPf9V6jj5JlWvWrKnyTqvl4169erWfn5/68l// +ldYWBiTCTBPBUDVA0AdTadADfniiy9qce+Sb11dXbdv364u2bVr162r16g1ME8FQNUDsBx3RWKA Ax7WpUuXlixZYvCf7kq97P9NRPY/j1FrYJ4KgKoH8PAVTTplgAOqPrjI43O7gTtaDE6bu6Yot4Ba A/NUAFQ9ANIpAxxQO+lUfXxu56t/KZVaA/NUAFQ9ANIpAxxQC+nU4FIqtQbmqQCoegCk04ca4Hjw 4FFdj8tffMVkAsxTAVD1AFTcFYkBDqip6YL+Y0/vyV+PW/DPnhOTuow7u2IrtQbmqQCoegANB+kU qP10usPh+ZThb6SMjIxr5Z864a1rB06U6UqoNTBPBUDVAyCdMsAB1psu6F8s5Z69YJ4KgKoHQDpl gANqZ7qgf7GUWgPzVABUPQDSKQMcUAsMLpZSa2CeCoCqB2Aed0VigAOYTICuBYCqB1DXK5p0ygAH MJkAXQsAVQ+AdEo6BZhMAHQtAFQ9QEWTThngACYToGsBoOoBkE5JpwCTCYCuBYCqBxoK7orEAAcw mQBdCwBVDwCkU4DJBLUGuhYAqh4A6ZQBDmAyAboWAKoeAEinAJMJag10LQBUPQDSKQMcwGQCdC0A VD2AuoG7IjHAAUwmQNcCQNUDqOsVTTplgAOYTICuBYCqB0A6JZ0CTCYAuhYAqh6gokmnDHAAk4nq pdPpSktLa70ZZWVl9+/fN/XT69ev5+fn14WWVLlrmToEhnGAXygASKekUwDVUGsJCQmbNm2KjY2N i4vLzMysjwc+ePDgpUuXVu29SUlJaWlp1dKMHTt2tG7d2nh5cXFxUFCQp6eni4vLuXPnrHBCTLWk yrbb+Jg5hOoaxv/xj3+cOnVKfXn58uXPPvuMugZIpwAeEndFYoAD6s1kYsCAAV5eXqGhoR4eHnZ2 dvHx8VZrcFZW1sWLF2s3nU6aNCk6OlqzPZVtnqlMuH///ieffNKaPaHCdFrZQ1ts093MIVTXMC49 cMWKFerL3bt3W/m8AWDyBoB0ygAH1HI6XbBggfJ86NChwcHBVmvwqFGj5s2bV7vp1Ex7Kts8U5lQ 2jZkyJA6lU4re2gTbDqZOQTSKcAvFAAgnQKo5nQ6Z84cNzc3eRIeHr527dpZs2ZJyLl169aNGzfG jRsnz3v06JGcnKysnJqaGhgYKAvlLdevX1cWaq4pW1u/fv3y5ctlzWeeeebEiROy8J133mnevLms 2a1bt127dhm0SnPjISEh27ZtU55v3bp1zJgxajpdsmTJG2+84ezs3KVLl4SEBP39Ll68uGPHjv37 909PT5e3d+3a9amnnkpKSlLXiYmJMW6PcfM0Dy03N1ea0aZNm379+kVFRRlnwvfff19+2qxZM9lO bGysLMnLy5OdSlPbt28fERGh/iWnwTm3pPH6TLVENuLn59e2bduAgABTZ954HYNDcLBppH8IBk2N tXna1BFV6hDMpNNKdTb9tjEsAKRTAKRTBjig/qXTjIyMFi1azJgxQ8l7Tk5OK1eulERRWloqoWX6 9Oky19+wYUOfPn2UN0rOlBhQVlb2008/FRcXKws115StdejQ4bXXXvv+++8lTowdO1YWFhYWBgUF zZ49WzJGUVGRQas0N967d28lSYro6Oi+ffuq23dxcVmzZs3p06enTZvm6OhYUlKiLJe89Pbbb8tG nn32WQmuL7300g8//PD73/9ejlp9r3Ld1aA9xs3TPLRhw4YFBwdfvHjxypUrEp6N0+kvv/wSGRn5 29/+VrZz9+5dWSKb9ff3P1tu6NChw4cPV1uif84tabw+Uy2Ji4s7deqUHEJYWNjEiRM1z7zxOgaH MMKmvf4hGDTVy6alqSOq1CGYSaeV6mz6bWNYAEinAEinDHBAfUqnkgp69uxpa2s7fvz427dvK1P8 mTNnKitcuHDBxsYmPj5eskdaWpq9vX1OTo4sf+6555Q4pG7K1JqytcmTJyvrfPjhh66urspzM98v Nd64+XT61ltvKc/z8vKkDceOHVOWz5kzR1kuK/Tr10+JK4mJiU2bNjVIpw/MfrNX89AuX74sCyVE KeuY+j7tH/7wB8lsyvPMzEx5i3qtOCEhQV5eunTJ4Jxb2HiVJS3ZuHGju7u7+TOvv46+cTYd1UMw aKr5I7L8EMyn00p1Nv3TCIB0CoC7IjHAAfUpnU6YMCElJSU7O1s/fqiZLTk5WWLAoEGDnv3V0aNH ZblEhcDAwEaNGs2fP//evXtm1tTf2rZt21xcXCpMp8YbN59O9f/utF27duvWrTNYvmjRIn9/f+V5 UlJSZdOp5qEdPnxYFqrnzZJ0qmxHfcuVK1fk5ZEjR4yPwpLGq8y0ZOfOnb6+vk+X69y5s+aRaq5j Pp0adI8Kj6jCQxDdunVbtmyZ+lJCrORVU/3Bks4GgHQK4AH/owwDHFC/0qn6d6ea8eP8+fMSA/bt 26f5dskhTk5O7733npk1q5BOjTeupNO1a9cqzxcvXqyZTnNzc6UNEs+qN51qHlpOTo6tra1yndbC dHru3DnZzsGDB5WXe/fulZcZGRkPmU5NtSQ9PV0S3f79++X5li1bNNOpqXUsTKcWHpEl6VT/W8Fi 8+bNkjkfprMBIJ0CIJ0ywAGPVDoVkiuGDBmifK/yzp07yrd/U1JSdDpdWVmZr6/v+vXrzaxpKp1G RkaauhOs5sbHjx8/efLkoqKirVu3tmzZUj+dBgQEFBQUlJSUrFixwtHR0Xi/lqRTg/YYvNQ8tP79 +4eHh+fn5588edLb27vCdFpaWipvCQsLk7dLg0NDQ318fOQwHzKdmmpJamqqJM/MzEyJr1OmTFGb p39optaxMJ3KEXnYNK/wiCw5hHfffdfBwUHar+RtaeHChQvN9IcKOxsA0ikA0ikDHPCopVOJCiNG jLC3t/f09HR2dla+t9m1a1dJMu7u7iEhIcrNckytaSqdnjlzRjbi5uamXLjTp7nxQ4cOderUqXHj xmPHjpUko59OJ02a1L17d9myk5OTeh2vsunUoD0GLzUPbffu3S1atJCFffr0iYmJqTCdPii/Vin5 TdK1JLGBAwcqlxkfPp2aaomcqyZNmnTs2DE2NlZyu3LTI4ND01zHwnQq1tp4VXhElhyCfNASbm1s bDw8PCQwBwQEqLf/rVpnA0A6BUA6ZYADHs3JRGFh4bVr1/SX3C5nyZpmXL16VfPeqpobLykpKSgo MFh469at4uLisrIy2ZRy1e5hGLTH4KXxoel0OssPVpWXl2d8IA/JVEtkX8oh3CmneWim1rG8a1XX Ecl20tLS9P8Kuho7GwBVUW4BkzeggeCuSAxwwCOYTkHXomsBj1Jd7/9NRPY/j1H1AEinDHAAEQJ0 LQC1Wdfy+Nxu4I4Wg9PmrjG4lErVAyCdAiBCgK4FwHrpVH18buerfymVqgdAOgVAhABdC0AtpFOD S6lUPQDSKYCajRA8ePDgwYOHhY/LX3zF5A14NHBXJNIpUBfTKacIdC0Amv9kuaf35K/HLfhnz4lJ XcadXbGVqgcazu9x0ikDHECEAF0LQO2n0x0Oz6cMfyNlZGRcK//UCW9dO3CiTFdC1QOkU9IpACIE 6FoArFfX+hdLuWcvQDolnTLAAUQI0LUA1E5d618speoB0inplAEOIEKArgWgFhhcLKXqgUcYd0Vi gAOIEKBrAaDqAYB0CjCZoNZA1wJA1QMgnTLAAUwmQNcCQNUDAOkUYDJBrYGuBYCqB0A6ZYADmEyA rgWAqgdQN3BXJAY4gMkE6FoAqHoAdb2iSacMcACTCdC1AFD1AEinpFOAyQRA1wJA1QNUNOmUAQ5g MgG6FgCqHgDplHQKMJkA6FoAqHqgoeCuSAxwAJMJ0LUAUPUAQDoFmExQa6BrAaDqAZBOGeAAJhOg awGg6gGAdAowmaDWQNcCUO+r/vr16/n5+TW6i7Kysvv379f3z0un05WWljaQRtbQR2aFzgbSKcBk gloDXQuAlap+3759hw4dMlgYHx+fnp5uyU6TkpLS0tKU58XFxUFBQZ6eni4uLufOnau5I92xY0fr 1q3rwjnPycnZtGnTtWvXqvDewYMHL1261Hh5QkJCcnKywUn+4YcfzGzq9OnT33zzjdUaee/evU1G srOzrfmRWaez/eMf/zh16pT68vLly5999pnVehd3RWJaAxAhQNcC0LCqfu3atTK/178+lpeX17hx 44sXL1qy00mTJkVHRyvP9+/f/+STT1rhSCsVdbKysiw8lipYtGiRjY3NkiVLqtASU+l0wIABTZs2 PX/+vLrk+eefj42NNbPl0NDQuLg4qzXy9u3b0/Q8/fTTsn31Hymq9pFV9mOyTmfz8PBYsWKF+nL3 7t3W6eGP/G9q0ilAhABdi64FUPUacnNzH3vssX379qlL3n///eeee64KDZAYM2TIkLqWTkeNGjVv 3ryaaIZOp+vQoUO3bt1cXV0t+fqrQUvMpFN7e3v5aVlZmSXp9P79++3atSssLLRmI1X5+fmdOnWa MmXKQ35klf2YrNPZSKekU4DJBLUGuhYAq1b9uHHjJk2apL4cOHCgkoVu3LghP5JQ0aNHD/W7puHh 4WvXrp01a5Ysv3XrlryMiYlRMm2bNm2aNWsmQUje/vLLLy9atEjd5ptvvrlq1SqD/a5fv97Pz69t 27YBAQEnTpxQty/Lly9f7ubm9swzz6jLJUWPGTNGdtGvX7+oqCjNqJOamhoYGCg/kvdev35dlrzz zjvNmzeXJdKqXbt2PSi/Miy7cHZ2bt++fUREhPpXiwbHpXnsBuLj4yUWfvPNNzY2Nnv27FGXh4SE bNu2TXm+detWabZmS5TgZ3ykkk7/67/+q1GjRh988IEl6fSrr74KCgoy9dMaaqRq8uTJknsLCgo0 /+FD8yMz/tyN96vZN/T/AUW/sxl/fGY+Zdny4sWLO3bs2L9///T0dDkJXbt2feqpp5KSkiqVTo07 m4UlQzolnQJECNC16FoAVW/yp4mJiU2aNFEChszX5fnNmzfluQSD6dOny3x6w4YNffr0UVaWuOLk 5LRy5UpZs7S0VL229ssvv0RGRv72t7+VCfrdu3cl8LRq1erevXvyI9maZI8zZ84Y7DcuLu7UqVNF RUVhYWETJ05Ut9+hQ4fXXnvt+++/l4n+2LFjleXDhg0LDg6+ePHilStXJFlpplOJTxIDysrKfvrp p+LiYllSWFgoyW327NnSKtmRLJGX/v7+Z8sNHTp0+PDhmseleewGRowYsWDBAnni4+Mzfvx4dXnv 3r2VxC6io6P79u2r2RJTRyrp9NNPP5Vs36JFi6ysrArT6RtvvKHuzmqNVHz++ee2trYHDhzQ3LWp j8z4czfer2bfUBl0NuOPz8ynLHn17bfflh7y7LPPdunS5aWXXvrhhx9+//vfy2mvVDo17mwWlgzp lHQKECFA16JrAVS9yZ/qdDpnZ+eNGzfK8z/+8Y8vvviiPLlw4YKNjU18fLzM79PS0uzt7XNycpSp 9syZM9X36n/z8w9/+IMkATU/SLiSlCXPJQXJVN5M22TX7u7u6gYnT56sPP/www9dXV0flN+NRhoj 2UBZbupros8995wSh/QX6n9lNDMzU7ajXJ17UH7/IXl56dIlg+Mydez65F2yPCMjQ55v2rTpscce Uy+gaQa/B1pfmjU+UjWdSjB76qmnRo4cWWE6lYhl6i82a66RIjs7u02bNhJcNXdtyUem/7mb+mav /jr69Dubwcdn/lOeM2eOsvytt97q16+fEhcTExObNm1aqXRq3NksLBnLcVckpjUAEQJ0LQANseqj oqIkFJWVlUkSUKb1ycnJMtUeNGjQs786evToA6M/RDSVTsUrr7zi7+8vTyRlffzxx8Y73blzp6+v 79PlOnfubLzBbdu2ubi4yJPDhw9LY9S7wppKpxIVAgMDGzVqNH/+fOWyrUHsUQ5K3c6VK1fk5ZEj Rwz2a+rY9cnKrVq1eq3c1KlTZf3Vq1dXNvgZH6maTuXJ8ePH7ezstm/fbiadShAydWm3Rhsphg8f 3r17d+XSpTEzH5nm526wX811zKdTg4+vwk950aJFSv98UH5XZM102q1bt2XLlqkvJcRKXjXV2Sws GZBOASIE6Fp0LYCqN/fT77//XibWf/vb39q2bav8v5Tnz5+XJfp3SzKOAebT6cmTJ21tbSWXSixR s6IqPT1dZvb79++X51u2bDGfTnNycmRTx44dM59OFZJDnJyc3nvvPePYc+7cOTmogwcPKi/37t0r L5VLi/r7NXXsqpKSEmnY66+/vuFXwcHBPXr0UIPf2rVrleeLFy+ucjoVsr58Ir169TKVTv/yl7/o /32v1Rr5wQcfyMdn/r+x0fzITH3u+vs1tY6F6dTCT9mSdKr/rWCxefNmyZymOpuFJQPSKUCEAF2L rgVQ9RVUvY+Pj0zQX331VXWJzN2HDBmifHfxzp07t2/frlQ6FV5eXrLNuXPnGu8uNTVVEkhmZqbE mClTpqhp01Qc6t+/f3h4eH5+voReb29vzXSakpKi0+nKysp8fX3Xr1+vLIyMjFRv7lpaWirbCQsL k2MpKCgIDQ2Vo1ZujWtwXJrHrpIwI6FR/WtDodx2SLlWNn78+MmTJxcVFW3durVly5Zq8NNviYXp 9O7du126dJEtm0qnfn5+agI0UHONlBjWvHlzWfOmHgnDBg3Q/MhMfe76+zW1joXp1MJP2ZJ0+u67 7zo4OEj7lbwtLVy4cKGZzmZJyWzcuFH/28KkU6Y1ABECdC26FkDVG9qwYYNEl+PHj6tLZDo+YsQI e3t7T09PZ2dn4+9GVphOZdYu2zx79qzmHseOHdukSZOOHTtK9HJ0dFRufmMqs+3evbtFixbSmD59 +sTExGgmlq5du8pyd3f3kJAQ9RunZ86ckeVubm7Ktbj09HTJKpLHJHUMHDhQuaRmfFyax64aPXp0 VFSUwd4lgEVERMiTQ4cOderUqXHjxnKAEm/U4GfQEkvS6YPyq3O2traa6TQvL69Dhw6mbrRTc43c tGmTjZHDhw8b7MvUR6b5uRvsV3MdC9OphZ+yJelUepGEWzk6Dw8PCcwBAQHq7X81O5slJRMYGNiz Z0/SKdMagAgBuhZdC6DqK62wsPDatWtVe+/q1av9/PzMrCD5SglXd8qZ35pOp6uwJbfLGS+/evWq foqT/Wr+JyjVdewlJSWmtm/QkochcfHll1+u8tut0EhTH5mpz11/v5XqG6Z6lyWfsiXbSUtLU/+Q tcLO9jAlo4+7IjGtAYgQoGsBoOqrhyQTV1fX7du389HUkLlz5yYmJnIeGmZFk06Z1gBECNC1AFD1 lrp06dKSJUuU/74SAOmUdAowmQBdi64FUPVUPUA6JZ0CoNZA1wJA1QMgnZJOASYToGvRtQCqnqoH 6iPuisQABzCZAF0LwCNb9XXkwScFNHCkU4AIAboWXQug6ut6IwGQTpnWAEwmQNcCQNWTTgGQTgEm E9Qa6FoASKcASKdMawAmE6BrAaDqSadAncJdkZjWAEwmQNcCQNWTTgGKhXQKMPRQa6BrASCdAiCd Mq0BmEyArgWAqmfCDVAspFOAoYdaA10LQO1UfVFuARNugHRKOgUYeqg10LUA1E7V6wrvnl60Id4p 2GpjAoMPYCHuisS0BiBCgK4FoEFU/fVD337lN/Nz+0GyXHmQTgGQTgEmE9Qa6FoArFT1+hdLDR6k UwCkU4DJBLUGuhYAa1S9wcVS0ikA0ikAag10LQBWrfrsPcdMhVLrP/ikANIp0xqACAG6Fl0LaNBV /2P0Z7u7vRjfLninyyhCI1DHcVckpjUAEQJ0LQCPeNVfP5R24uW3v2jml9Rl3BdN/UinQH2saNIp 0xqACAG6FoBHpOqLcgsMLqVyAgHSKekUYOih1kDXAlBrVa9cSmVMAEinpFMA1BroWgBqv+qLcgs4 gQDplHQKMPRQa6BrAaDqAfwf3BWJAQ5gMgG6FgCqHgBIpwCTCWoNdC0AVD0A0ikDHMBkAnQtAFQ9 AJBOASYT1BroWgCoegCkUwY4gMkE6FoAqHoAdQN3RWKAA5hMgK4FgKoHUNcrmnTKAAcwmQBdCwBV D4B0SjoFmEwAdC0AVD1ARZNOGeAAJhOgawGg6gGQTkmnAJMJgK4FgKoHGgruisQABzCZAF0LAFUP AKRTgMlEzddaWVnZ/fv3Oe0GdDpdaWnpo7GXejGM0w8B0ikA0ikDHPCITCYSEhI2lTtw4EBxcbHl u9uxY0fr1q2V50lJSWlpaXXqbJg5LskziYmJy5Ytmz179qpVq+Li4m7evFmpjZs53sGDBy9dutSS jeTk5Ejzrl27VoWjs3wvlW2/5Z1H3cjDD+MP84no90MApFMApFMGOKAeTyYGDBjg5eUVGhrq5ubm 4ODw9ddfVyEVTJo0KTo6+iHbn5WVdfHixcr+yBRTx5WXl+fv7+/i4rJw4cL3338/MjKyV69eycnJ ldq4/vEatM3y3Lho0SIbG5slS5ZU4eQ8ZDqt7OeldB6DNqgbechh/CE/EdIpQDoFQDplgAMenXS6 YMEC5fnTTz8tkaO2UsGoUaPmzZtX2R+ZSaeaxzVz5kx3d/cbN27or1xWVlZdzbYwN+p0ug4dOnTr 1s3V1dWS7+hWbS/V27VMfQoPOYw/5CdCOgVIpwDM465IDHBAvUynEj9Gjx6tPJe0MG7cOJn39+jR Q72QlZubO2bMmDZt2vTr1y8qKkpNBeHh4TExMerztWvXzpo1S35669Ytze3k5eVNmzatU6dOTzzx hGxKlrzzzjvNmzeX1SSw7dq1S7+Fxj+St8tenJ2d27dvHxERkZ+fb+FxyZp2dnabNlUwRo8dO3b7 9u3K8zlz5rzwwgvK85SUlAkTJugfr3HblNy4fPlyNze3Z5555sSJE5q7iI+Pb9eu3TfffGNjY7Nn zx51eUhIyLZt25TnW7dulbNdqb2YOjMGH4rafgnJ3f6vP/3pT7J8/fr1fn5+bdu2DQgIkI1L5zFu g7oR+amZ/cqmzJwN85+Iqc2a6oeanQ0AkzeAiiadMsAB9SmdyrReQtHjjz/+5ZdfKssllkyfPl2S zIYNG/r06aMsHDZsWHBw8MWLF69cuSI5Sk0F+pfy5LmTk9PKlSvT09NLS0s1tyMLPT09d+/eXVxc /J///EeWFBYWBgUFzZ49W1pSVFSk30LjH8lLf3//s+WGDh06fPhwC4/r+PHjkgb//e9/mz+T8kYl kUrzHB0d7e3tlVwkbZCgpX+8xm2TH3Xo0OG11177/vvvJSlJ0NXcxYgRI5Tw7OPjM378eHV57969 1ZwfHR3dt2/fSu3F1Jkx+FD0P68bv/rggw/kRB06dEgWxsXFnTp1SvYVFhY2ceJE6TyabVA2Ij81 s1/zZ8P8J2Jqs6b6oWZnA8DkDaCiSacMcEC9SaeNGze2tbWVkLB//35l4YULF+RlfHy8pIK0tDSJ Zzk5OZcvX5aFEimVdfS/UWmQTmfOnGlmO8pC4797tPCbvZmZmfJ29fpqQkKCvLx06ZIlx5WYmCgv s7KyzJ/Jw4cPP/HEE/fv39+7d68kIm9vbzlYCXXt27c/d+6cwfEaf+d28uTJyvMPP/zQ1dXVePvS WjkVGRkZ8nzTpk2PPfbY9evXzaRTC/di5szofygPtL4YfPLkyWbNmm3ZssWgqRs3bnR3d9f8Zq+6 kfU23mb2a/5smPlETB2OqX6o2dkYFgDSKQDSKQMcUJ/SaWRkpKQjCSGvvvqqsjA5OVkm+oMGDXr2 V0ePHpXMJguzs7MrTKfqc83tKAu/++67qqVT5e1qM65cuSIvjxw5YslxnTlzRlaWNpg/kzqdrmXL lrKj2bNnf/DBB2+++eYrr7ySkpLSq1cv42M08xeh27Ztc3FxMd6+rNCqVavXyk2dOlWatHr16sqm U+O9mDkzBnHU4KVEPgneixcvVpfs3LnT19f36XKdO3c2n07/aNPDkv1qng0zn4ipwzHVDzU7G8MC QDoFQDplgAPqUzpVvmIqk347O7ukpCR5fv78eZno79u3T3/NnJwcW1vbY8eOWZ5ONbejLNy4cWPV 0um5c+fk7QcPHlRe7t27V14q1yErPK6ioiJHR8cZM2ZUeDInTJgQFRXl6uoqKUj25eHhMXfuXM1j rGw6LSkpkYWvv/76hl8FBwf36NFDTadr165VnktcrFQ6NXNmzKTTW7duyU4nTpyo3ogoPT29UaNG ygXnLVu2VJhO19h4WbJfzbNh5hMxdTim+qFmZwNAOgXAXZEY4ID6l06FBDAnJyfl+5D+/v5DhgxR /geRO3fu3L59W570798/PDw8Pz//5MmT3t7eFaZTU9uRJX369Pn222/l+Y8//qjctDYyMlKWazZS /0eysjQjLCxMNlVQUBAaGurj42N8i1dTxyWp2N7e/q9//aukRGVriYmJ0gaDt2/evLlly5YDBw5U ElSzZs3k5ZkzZ4yP0aDZFeYxyclt27bV/y9YlXsjKRf6xo8fP3nyZNnj1q1bZY9qOrVkL2bOjKl0 qtPpJBsPGjTo3r176k9TU1MlnWZmZsoZmzJlinzKSucx1YbPbAZYsl9TV5JNfSJmDsdUP9TsbACY vAEgnTLAAfUvnd69e7dbt25BQUGSASSZjBgxQmKDp6ens7Oz8kXN3bt3t2jRQhZKtoyJibEknWpu 5+rVq7KaRLI2bdq4uroqd9mR7Ne1a1c3Nzf1z0RVBj9KT0+XoCLhzcHBQQKk8YVTM8clLz/66CNH R8emTZt2795d8lJISIhxOs3Ozra1tV2xYoXycvjw4bKyZjg0aFuFeWz06NFRUVEGCyViRUREyJND hw516tSpcePGY8eOfffdd9V0auFeTJ0ZU+lUuSmRZO9Wv1KaIXtv0qRJx44dY2Nj5VwNsmljpg3S tSzZr6l0auYTMbVZU/1Qs7MBYPIGgHTKAAc8CpOJwsLCa9eu6S/R6XQGS6q2HfHzzz8XFBQYLJTg aur//zT4UV5envHbLZeVlXX27NmH+Z9OLWx2ZZWUlJg6Lgv38pBnRt2Isq87d+58bPMbM21Qu1YN fSKamzXTDzU7GwAmbwBIpwxwQP2YTBTlFnACwTAOgKoHQDoFUDuTCV3h3dOLNsQ7BVOJYBgHQNUD jyTuisQAB9T1ycT1Q99+5Tfzc/tBslx5cALBMA6AqgcaWkWTThnggFqbTOhfLDV4cALBMA6AqgdI p6RTANaYTBhcLCWdgmEcAFUPkE5JpwxwgFWHnuw9x0yFUh48ePDgwaNS/2TJ5A0gnZJOATxsrf0Y /dnubi/Gtwve6TKKa6dgGAdA1QMNAXdFYoAD6u5k4vqhtBMvv/1FM7+kLuO+aOpHOgXDOACqHgDp lAEOqLXJRFFugcGlVE4gGMYBUPUASKcAam0yoVxKpRLBMA6AqgdAOmWAA2p/MlGUW8AJBMM4AKoe AOkUAJMJ0LUAUPUAqh93RWKAA5hMgK4FgKoHUNcrmnTKAAcwmQBdCwBVD4B0SjoFmEwAdC0AVD1A RZNOGeAAJhOgawGg6gGQTkmnAJMJgK4FgKoHGgruisQABzCZAF0LAFUPAKRTgMkEtQa6FgCqHgDp lAEOYDIBuhYAqh4ASKcAkwlqDXQtAFQ9ANIpAxzAZAJ0LQBUPYC6gbsiMcABTCZA1wJA1QOo6xVN OmWAA5hMgK4FgKoHQDolnQJMJqpKp9OVlpYaP69FZWVl9+/f59NnngqAqgdAOmWAA+r3ZCIhIWGT nn//+99mNjJ48OClS5caP394ajMOHDhQXFxs+Rt37NjRunVr5XlSUlJaWlqd+lDMHJfk6sTExGXL ls2ePXvVqlVxcXE3b95kngqAqgdAOiWdAg10MjFgwIDevXtP+9WePXtqJZ1KM7y8vEJDQ93c3Bwc HL7++usqpNNJkyZFR0c/ZEuysrIuXrxY2R9V9rjy8vL8/f1dXFwWLlz4/vvvR0ZG9urVKzk5mXkq AKoeQPXirkgMcEB9SqdRUVEW7qJG0+mCBQuU508//bTkzCqk02oxatSoefPmVfZHlT2umTNnuru7 37hxQ3/lsrIy5qkAqHoAIJ0CpNP/lZeXFx4e7uzs3L59+4iIiPz8fPPpVHP9sWPHbt++XVlhzpw5 L7zwgvI8JSVlwoQJZlKchMDRo0crzyW/jRs3TvJnjx491EuLubm5Y8aMadOmTb9+/aTxajqVNsTE xKjP165dO2vWLPnprVu3NLcjzZ42bVqnTp2eeOIJ2ZQseeedd5o3by6rdevWbdeuXfotNP6RqbNU 4XHJmnZ2dps2bXq0uxYA0ikAkE4BJhOVS6dhYWHHy6l/dBoUFOTv73+23NChQ4cPH24+nWquL6lM SaTFxcWOjo729vZKfps9e/by5cs1U5xkyG3btj3++ONffvmlsjwgIGD69OkSLzds2NCnTx9l4bBh w4KDgy9evHjlypWQkBA1nRo0z8nJaeXKlenp6aWlpZrbkYWenp67d++WFv7nP/+RJYWFhXIs0kJp SVFRkX4LjX9k6ixVeFxyqm1sbMz/iS/zVABUPQCQToEGl047derkVy48PFyWZGZmSnZSrxwmJCTI y0uXLplKp6bWP3z48BNPPHH//v29e/dKcvP29t6xY4cExfbt2587d864GY0bN7a1tZX37t+/X1l4 4cIFeRkfHy/xLy0tTfJtTk7O5cuXZaFESmUd/W/2GjRv5syZZrajLDT+O1ULv9lr5ixVeFyJiYny Misri3kqAKoeAEinAJOJ/41PBt/sTU5OluyUnZ2tvLxy5Yq8PHLkiKl0amp9nU7XsmVL+ens2bM/ +OCDN99885VXXklJSenVq5dmMyIjI69fv+7u7v7qq6/qt2TQoEHP/uro0aMSevV3Zyadqs81t6Ms /O6776qWTs2cpQqP68yZM7KytIF5KgCqHkBN465IDHBAPU6n586dk+x08OBB5eXevXvlZUZGhqn4 Z2b9CRMmyMZdXV0lxckKHh4ec+fO1byXkvr3mRI+7ezskpKS5Pn58+dlU/v27dNfMycnx9bW9tix Y5anU83tKAs3btxYtXRq5qgrPK6ioiJHR8cZM2YwTwVA1QOo3YomnTLAAXU6nZaWlvbv3z8sLOz2 7dsFBQWhoaE+Pj7K7WQ145+Z9Tdv3tyyZcuBAwcqkaxZs2by8syZM2bSqZAE6+TkJClUnvv7+w8Z MkT5f1zu3Lkju5Ansrvw8PD8/PyTJ096e3tXmE5NbUeW9OnT59tvv5XnP/74oxyIPImMjJTlmudK /0dmjtqS45JUbG9v/9e//rWkpETZWmJiorSBeSoAqh4A6ZR0CpBO/1d6erpkLUmSDg4Oki3VS4Km 4p+p9bOzs21tbVesWKG8HD58ePfu3U01Q01xd+/e7datW1BQkIQ9yXIjRoyQIOfp6ens7Kx8dXb3 7t0tWrSQhZItY2JiLEmnmtu5evWqrGZjY9OmTRtXV1flXkcSnrt27erm5qb+majK4EemjtqS45KX H330kaOjY9OmTeWcuLi4hISEkE4BUPUASKekU4DJhIa8vLyCgoKaW99yhYWF165d01+i0+kMllRt O+Lnn382brYEV+VSqjGDHz3kUWdlZZ09e7bW/6fTotwChnEAVD1AOiWdMsABTCZQ+51n/28isv95 jK4FgKoHHjHcFYkBDmAygXrWeeTxud3AHS0Gp81dY3Apla4F8AuFqgdAOgVArcF66VR9fG7nq38p la4F8AuFqgdAOgVAraEW0qnBpVS6FsAvFKoeAOkUQHXWGg8eVX5c/uIrhnGAXyhUPQDSKQBqDTXe efQfe3pP/nrcgn/2nJjUZdzZFVvpWgC/UKh6oP7irkgMcACTCdS/dLrD4fmU4W+kjIyMa+WfOuGt awdOlOlK6FoAv1CoeuARrmjSKQMcwGQCda7z6F8s5Z69AGMCVQ+QTkmnAJhMoHY6j/7FUroWwJhA 1QOkU9IpACYTqAUGF0vpWgC/UKh6gHRKOgXAZAJ0LQBUPYBqw12RGOAAJhOgawGg6gGAdAowmaDW QNcCQNUDIJ0ywAFMJkDXAkDVAwDpFGAyQa2BrgWAqgdAOmWAA5hMgK4FgKoHUDdwVyQGOIDJBOha AKh6AHW9okmnDHAAkwnQtQBQ9QBIp6RTgMkEQNcCQNUDVDTplAEOYDIBuhYAqh4A6ZR0CjCZAOha AKh6oKHgrkgMcACTCdC1AFD1AEA6BZhMUGugawGg6gGQThngACYTOp2utLSUD4WuBYCqBwDSKcBk wqKfJiQkbCr3ySeffP3117m5ufo/TUpKSktLq0JjBg8evHTp0oc5HKVhsbGxcXFxmZmZfL7MUwFQ 9QBAOgUe5cnEgAEDevfuPXXq1JEjR/bs2bNx48br169Xfzpp0qTo6OhaSafSMC8vr9DQUA8PDzs7 u/j4eD5i5qkAqHoAlcVdkRjggPqUTqOiotSXGzdutLGx+fTTTx+yMdWSThcsWKA8Hzp0aHBwMB8x 81QAVD2A6q1o0ikDHFB306kYPXq0l5eX8jw8PDwmJkZ5npqaGhgY2Lp1azc3t+vXr6srrFu37o03 3nB2du7SpUtCQoJxOl2/fr2fn1/btm0DAgJOnDghS15++eVFixape3zzzTdXrVplJp3OmTNHdqrs bu3atbNmzZJm3Lp1Ky8vT5bIrtu3bx8REZGfn6+sf+3atTFjxrRp06Zfv37Lli3z8fFRW6v/9hs3 bowbN06e9+jRIzk52cxhai6kazGMA1Q9ANIp6RRADabT6Ojoxx9/vKSkxCBkPvPMMxLtysrKfvrp p+LiYjWFuri4rFmz5vTp09OmTXN0dDR+Y1xc3KlTp4qKisLCwiZOnChLtm7d2qpVq3v37snzmzdv Nm/e/MyZM6bSaUZGRosWLWbMmKFs1snJaeXKlenp6aWlpUFBQf7+/mfLDR06dPjw4WqrhgwZIm+U JPnCCy9IqlSX679d0vL06dMlpm7YsKFPnz5mDlNzIV2LYRyg6gGQTkmnAGownW7evNnOzk7CpEHI fO6554KDgy9evKi/sqzw1ltvKc/z8vJsbGyOHTv2wMQ3ezdu3Oju7i5PfvnlFwmcyveHY2JiJPtp NszDw6Nnz562trbjx4+/ffu2stmZM2cqK2RmZsrudu3apbxMSEiQl5cuXZJQKk8SExOV5Tt27NBP p+rbL1y4IKvFx8dLsk1L95ltKwAATi5JREFUS7O3t8/JyTF1mJoL6VoM4wBVD4B0SjoFUIPp9I9/ /KOSIQ1CpmSzwMDARo0azZ8/X7nsaZxC27Vrt27dOoPlO3fu9PX1fbpc586dlYWvvPKKv7+/PHnq qac+/vhjzYZNmDAhJSUlOztbPwyrm01OTpZ4qf70ypUr8vLIkSPyFv3lBunU4O2DBg169ldHjx41 dZiaC+laDOMAVQ+g7uOuSAxwQH1Np/fv35doOnfuXM3wKST+OTk5vffee8Yr5ObmSt6TNKi/PD09 XULd/v375fmWLVvUdHry5ElbW1vJpRIdNfOe/t+daqbTc+fOye4OHjyovNy7d6+8zMjIuHv3btOm TZU9Pii/YKuZTs+fPy/r79u3T/O0GBymmYV0LYZxgKoHANIpgOpMpxLq0tLSgoODJZ3evHnTOM6l pKTodLqysjJfX1/1f52RFQICAgoKCkpKSlasWOHo6Kh+BVd5Y2pqqqTTzMzMnJycKVOmqEFReHl5 SYxUk3Bl02lpaWn//v3DwsJkj9KA0NBQHx8faZ78aNSoUX379t2+ffuSJUt69+7dtm1bzbDt7+8/ ZMgQ5fu6d+7cUVqueZiaC+laDOMAVQ8ApFMA1ZlObWxsbG1tJSh6e3vPmzdPCWnGca5r166SLSW7 hoSESJRVVxg5cmT37t1dXFycnJzUK5n6bxw7dmyTJk06duwYGxsr8VW5MdKD8nv5yq7Pnj1btXT6 oPzCrCTSli1bOjg4DBw4MCMjQ1kuSTg8PFyWLFy48KOPPlLu92v8dlltxIgR9vb2np6ezs7OR44c MXWYmgvpWgzjAFUPAKRTALVTa7fLGcfFsrKyq1evKtctNeXl5ZWWlj4ov0QplIWrV6/28/N7+FbJ xgsKCkz99KWXXjL/f6UWFhZeu3bN/GGaWkjXYhgHqHoAIJ0CqM5aK8otqNpONe/NawmdTufq6rp9 +/aaOBWrVq2aP3/+p59++rvf/a558+bqFV0wTwVA1QMNDXdFYoAD6sdkQld49/SiDfFOwVWuxM2b NycnJ1fhjZcuXVqyZIny/9ZUu8OHDy9fvnzq1KkLFy787rvv6BvMUwFQ9QAVTTplgAPq6GTi+qFv v/Kb+bn9IFmuPDiBYBgHQNUDpFPSKQArTSb0L5YaPDiBYBgHQNUDpFPSKQBrTCYMLpaSTsEwDoCq B0inpFMGOMCqQ0/2nmOmQikPHpY8GMYBfqFQ9UA9xV2RGOCAujiZ+DH6s93dXoxvF7zTZRTXTsEw DoCqB0A6ZYADanMycf1Q2omX3/6imV9Sl3FfNPUjnYJhHABVD4B0ygAH1Npkoii3wOBSKicQDOMA qHoApFMAtTaZUC6lUolgGAdA1QMgnTLAAbU/mSjKLeAEgmEcAFUPPHq4KxIDHMBkAnQtAFQ9gLpe 0aRTBjiAyQToWgCoegCkU9IpwGQCoGsBoOoBKpp0ygAHMJkAXQsAVQ+AdEo6BZhMAHQtAFQ90FBw VyQGOIDJBOhaAKh6ACCdAkwmqDXQtQBQ9QBIpwxwAJMJ0LUAUPUAQDoFmExQa6BrAaDqAZBOGeAA JhOgawGg6gHUDdwViQEOYDIBuhYAqh5AXa9o0ikDHMBkAnQtAFQ9ANJpA0unOp2utLSUTgmGHiYT oGsBoOoBKpp0atEAl5CQsKncJ5988vXXX+fm5uqvlpSUlJaWVoW9Dx48eOnSpQ9zzErDYmNj4+Li MjMz6d9gMgG6Fl0LoOoBkE4f5XQ6YMCA3r17T506deTIkT179mzcuPH69evV1SZNmhQdHV0r6VQa 5uXlFRoa6uHhYWdnFx8fTxcHkwnQtehaAFUPoF7grkhVTKdRUVHq8o0bN9rY2Hz66acP2eJqSacL FixQng8dOjQ4OJguDiYToGvRtQCqHgAaSjoVo0eP9vLyUp6Hh4fHxMQoz1NTUwMDA1u3bu3m5nb9 +nV1hXXr1r3xxhvOzs5dunRJSEgwTqfr16/38/Nr27ZtQEDAiRMnZMnLL7+8aNEidY9vvvnmqlWr zKTTOXPmyE6V3a1du3bWrFnSjFu3buXl5ckS2XX79u0jIiLy8/OV9a9duzZmzJg2bdr069dv2bJl Pj4+amv1337jxo1x48bJ8x49eiQnJ5s5TM2FAJMJ0LUAUPUASKc1mE6jo6Mff/zxkpISg5D5zDPP SLQrKyv76aefiouL1RTq4uKyZs2a06dPT5s2zdHR0fiNcXFxp06dKioqCgsLmzhxoizZunVrq1at 7t27J89v3rzZvHnzM2fOmEqnGRkZLVq0mDFjhrJZJyenlStXpqenl5aWBgUF+fv7ny03dOjQ4cOH q60aMmSIvFGS5AsvvCCpUl2u/3ZJy9OnT5eYumHDhj59+pg5TM2FAJMJ0LUAUPUASKc1mE43b95s Z2cnYdIgZD733HPBwcEXL17UX1lWeOutt5TneXl5NjY2x44de2Dim70bN250d3eXJ7/88osETuX7 wzExMZL9jFsoDfPw8OjZs6etre348eNv376tbHbmzJnKCpmZmbK7Xbt2KS8TEhLk5aVLlySUypPE xERl+Y4dO/TTqfr2CxcuyGrx8fGSbNPS0uzt7XNyckwdpuZCgMkE6FoAqHoApNMaTKd//OMflQxp EDIlmwUGBjZq1Gj+/PnKZU/jFNquXbt169YZLN+5c6evr+/T5Tp37qwsfOWVV/z9/eXJU0899fHH H2um0wkTJqSkpGRnZ+uHYXWzycnJEi/Vn165ckVeHjlyRN6iv9wgnRq8fdCgQc/+6ujRo6YOU3Mh wGQCdC0AVD0ATdwVqRrS6f379yWazp07VzN8Col/Tk5O7733nvEKubm5kvckDeovT09Pl1C3f/9+ eb5lyxY1nZ48edLW1lZyqURHzbyn/3enmun03LlzsruDBw8qL/fu3SsvMzIy7t6927RpU2WPD8ov 2Gqm0/Pnz8v6+/bt0zw/BodpZiHAZAJ0LQBUPYCGU7PWSKcS6tLS0oKDgyWd3rx50zjOpaSk6HS6 srIyX19f9X+dkRUCAgIKCgpKSkpWrFjh6OiofgVXeWNqaqqk08zMzJycnClTpqhBUXh5eUmMVJNw ZdNpaWlp//79w8LCZI/SgNDQUB8fH2me/GjUqFF9+/bdvn37kiVLevfu3bZtW82w7e/vP2TIEOX7 unfu3FFarnmYmgsBJhOgawGg6gGQTqszndrY2Nja2kpQ9Pb2njdvnhLSjONc165dJVtKdg0JCZEo q64wcuTI7t27u7i4ODk5qVcy9d84duzYJk2adOzYMTY2VuKrcmOkB+X38pVdnz17tmrp9EH5hVlJ pC1btnRwcBg4cGBGRoayXJJweHi4LFm4cOFHH32k3O/X+O2y2ogRI+zt7T09PZ2dnY8cOWLqMDUX AkwmQNcCQNUDIJ3WzgB3u5xxXCwrK7t69apy3VJTXl5eaWnpg/JLlEJZuHr1aj8/v4c/O7LxgoIC Uz996aWXzP9fqYWFhdeuXTN/mKYWAkwmQNcCQNUDIJ1W5wBXlFtQtZZp3pvXEjqdztXVdfv27TVx vlatWjV//vxPP/30d7/7XfPmzdUrugCTCdC1AFD1AKyAuyJVeoDTFd49vWhDvFNwlce7zZs3Jycn V+GNly5dWrJkifL/1lS7w4cPL1++fOrUqQsXLvzuu++oDTCZAF0LAFUPAHU3nX7lN/Nz+0HyRHlw lgEmE6BrAaDqAcBK6VT/YqnBg7MMMJkAXQsAVQ8ANZ5Orx/61uBiKekUYDIBuhYAqh4ArJFOefDg URceDGFgngqAqgcaGu6KVMF492P0Z7u7vRjfLninyygm0ECtzC0A5qkAqHqAiiad/v9n5/qhtBMv v/1FM7+kLuO+aOpHOgUYicA8FQBVD4A5YS2kU0VRboHBpVQ6EMBIBOapAKh6AMwJrZ1OVcqlVMY7 gJEIzFMBUPUAmBNaI52a/6vcotwCOhBQLR7hv4AH81QAVD0A5oQ2fLoAwDyVeSpA1QMA6RQAwDwV AFUPAKRTAGCeyjwVoOoBgHQKAGCeCoCqB4AHVrgrEoDqQq2BeSoAqh4Ad0Wq+ngHwDpzC4B5KgCq HqCiSaeMaAAjEZinAqDqATAnJJ0CjEQA81QAVD1ARZNOGdEARiIwTwVA1QNgTlj76ZQ7tQDWQa2B eSoAqh4Ad0UCADBPBUDVAwDpFADAPBUAVQ+AdAoAYJ4KgKoHANIpAIB5qvXodLrS0lL6iSgrK7t/ /z7ngaoHgHqTTrlTC2Ad1Brq2jw1ISFh06ZNsbGxcXFxmZmZdeoYc3JypG3Xrl2rwnsHDx68dOnS Ku86KSkpLS3tIdtfLRtRE2ZiYuKyZctmz569atUq+bBu3rxp4Xt37NjRunVrSoaqB8CcsN6kU0Y0 oC7MLQDrz1MHDBjg5eUVGhrq4eFhZ2cXHx9vtUPIysq6ePGimRUWLVpkY2OzZMmSKmztIdPppEmT oqOjH/KIqrYRY3l5ef7+/i4uLgsXLnz//fcjIyN79eqVnJxMOqXq+f0CMCcknQKg1vBIpdMFCxYo z4cOHRocHGy1Qxg1atS8efNM/VSn03Xo0KFbt26urq6WfEfXYGsPmU5r4oiqbObMme7u7jdu3NBf WFZWRjql6vn9AjAnJJ0CoNbwaKbTOXPmuLm5yZPw8PC1a9fOmjVLUs2tW7ckF40bN06e9+jRQ71k l5qaGhgYKAvlLdevX1cWaq4pW1u/fv3y5ctlzWeeeebEiROy8J133mnevLmsKflz165dxg2Lj49v 167dN998Y2Njs2fPHnV5SEjItm3blOdbt24dM2aM5taUdGqw0wfl1yGlPc7Ozu3bt4+IiMjPz1cb qX/I8jImJkYJyd3+rz/96U+yXI7Iz8+vbdu2AQEBpo5I3Yj5/RqfHH2ypp2d3aZN2l8AM7XZ3Nxc OTNt2rTp169fVFSUmk41PyCQTgEwJySdAoxEQB1KpxkZGS1atJgxY4YS7ZycnFauXJmenl5aWioB bPr06ZLZNmzY0KdPH+WNEqUkzpWVlf3000/FxcXKQs01ZWsdOnR47bXXvv/+e4lGY8eOlYWFhYVB QUGzZ8+WvFRUVGTcsBEjRigN8/HxGT9+vLq8d+/eauSLjo7u27ev5tY0dypkNX9//7Plhg4dOnz4 cLWR+oesf+n1xq8++OCDxx9//NChQ7IwLi7u1KlTsq+wsLCJEyeaaoO6ETP71Wyn6vjx45LP//3v f2t+fKY2O2zYsODg4IsXL165ckXyvJpONT8gkE4BMCesW+mUO7UA1kGtoQ6mUw8Pj549e9ra2koI vH37thKZZs6cqaxw4cIFSUfx8fGSf9LS0uzt7XNycmT5c889p+QfdVOm1pStTZ48WVnnww8/dHV1 VZ6b+R7spUuX5O0SmOX5pk2bHnvsMfXyrGY6faD1zV7jnWZmZkoL1Uu1CQkJ8lL2ZXDID7S+GHzy 5MlmzZpt2bLFoKkbN250d3c31QZlI+b3q3lyVImJibJyVlaW8VkytdnLly/Lk927dyvL1W/2mvqA QDoFwJywbqVTAECDTacTJkxISUnJzs7WzGbJyckSaQYNGvTsr44ePSrLJZcGBgY2atRo/vz59+7d M7Om/ta2bdvm4uJSYTqV9Vu1avVaualTp8pmV69eXdl0arxTpYXqkV65ckVeHjlyxDiOGryUyNe+ ffvFixerS3bu3Onr6/t0uc6dO5tvg4X71T85/zt9OXNGVlbOpAFTmz18+LD+cjWdmvqAQDoFANIp AKBOpFP17041s9n58+cl0uzbt0/z7ZKFnJyc3nvvPTNrVjadlpSUyDqvv/76hl8FBwf36NFDTadr 165VnktcrFQ6PXfunLTw4MGDyvK9e/fKS+UKrZl0euvWLdnpxIkT1RsRpaenSyzfv3+/PN+yZUuF 6dTC/Wqm06KiIkdHR+Ub1wZMbTYnJ8fW1vbYsWMG6dT8RwnSKQCQTgEAdTqdCn9//yFDhihf4r1z 547y7d+UlBSdTieBzdfXd/369WbWNBXAIiMjZWXjJiUlJbVt21b9W1ah3BtJudA3fvz4yZMnS2bb unVry5Yt1XRqsDXNnZaWlvbv3z8sLEwaVlBQEBoa6uPjo2ROU+lUjlGy8aBBg5Trw4rU1FRJp5mZ mZIDp0yZov5Vp6k2WLhfzXT6oPzLw/b29n/9618ltytbS0xM/PHHH81sVpaHh4fn5+efPHnS29tb baHmBwTSKQCQTgEA9SOdSgYbMWKEBCRPT09nZ2flK6ldu3aVzOPu7h4SEnL37l0za5oKYGfOnJGN uLm5KRchVaNHj46KijJokkSsiIgIeXLo0KFOnTo1btx47Nix7777rppODbZmaqfp6ekS4STWOjg4 DBw4ULmAaSadKjclatasWatfKc2QvTdp0qRjx46xsbGOjo7KjZHMtMGS/ZpKp+Kjjz6SvTRt2rR7 9+6yjpxzSadmNrt79+4WLVrIB9GnT5+YmBg1nWp+QCCdAkDdSqfcqQWwDmoN9XeeWlhYeO3aNf0l t8tZsqYZV69eteS/M9VXUlJSUFDwMFvLy8sztQXLyUaUfd0pZ0kbHnK/WVlZZ8+eNf6fTjU3q9Pp TH0KlfqAYE1FuQWkU4A5IemUEQ2oE4kCqMvpFIAV6nr/byKy/3mMqgeYE5JOATASgXQKoDbrWh6f 2w3c0WJw2tw1BpdSqXqAOSHpFAAjEUinAKyXTtXH53a++pdSqXqAOSHpFAAjEUinAGohnRpcSqXq AeaEDSWdcqcWwDqoNdTQbzXNSS0PHjwescflL76yvOoZJwHmhPU1nQIA6ns6tXxlAHW2rvUfe3pP /nrcgn/2nJjUZdzZFVupegCkUwAA6RSA9dLpDofnU4a/kTIyMq6Vf+qEt64dOFGmK6HqAZBOAQCk UwDWq2v9i6Xm79lL1QMgnQIASKcAaqqu9S+WUvUAGmg65U4tgHVQayCdAjDF4GIpVQ8wJ2yg6ZQh DKiVRAGQTgFQ9QAVTTplCAMYicA8FQBVD4A5IekUYCQCmKcCoOoBKpp0yhAGMBKBeSoAqh4Ac8I6 l065UwtgHdQamKcCoOoBcFckAADzVABUPQCQTgEAzFMBUPUASKcAAOapAKh6ACCdAgCYpwKg6gGQ TivCnVoA66DWwDwVAFUPgLsiVWK8A2CduQXAPBUAVQ9Q0aRThjCAkQjMUwFQ9QCYE5JOAUYigHkq AKoeoKJJpwxhACMRmKfCcjqdrrS0lPNgtbN0/fr1/Pz8uvaR1W43oOoB5oQNJZ1ypxbAOqg1WH+e mpCQMMPGfdOmTQcOHCguLq7dZufk5EhLrl27VrvN+Pvf/75Jy507d0y9ZfDgwUuXLq3eZpSVla1f v97y9U+fPv3NN9/ov/3LL79cuHBhVFSUHNH9+/cr24CkpKS0tLRqPCJTZ0k6oXKGLemEskJQUJCn p6eLi8u5c+eqvTG12w0+/vjjgoIC0ikA7ooEAGiI6XTAgAFuNs1CQ0Pd3NwcHBy+/vprM5vNysq6 ePFizTV70aJFNjY2S5Ysqd2zJ3FuWrnevXs7OTlN+5WZi3U1kU7feuutTz75xPL15UOMi4tTnktT AwICunXr9vbbb69YsaJfv36/+c1v5OMzvwWDz3fSpEnR0dFWSKfSCb28vCzshPv373/yySdrrjG1 2w0kbw8bNkyn05FOAZBOAQANMZ2OtumgPH/66aclkJjZ7KhRo+bNm1dDbZYZeYcOHSRQubq61pFv ycrBDhw4sFqiTmXt2LHjt7/9reXr379/v127doWFhcrL3//+9507d75586by8t69e5JOX3jhBfMb qdHP13w6XbBggYWdULYwZMgQK6TT2uoGb775ZtU+BdIpANIpAODRSacSTkaPHq08v3Hjxrhx41q3 bt2jR4/k5GRZ8s477zRv3lyWSIDctWuXLAkJCdm2bZuy/tatW8eMGaM8Dw8PX7t27axZs2TlW7du ycv169cvX77czc3tmWeeOXHihGZL4uPjJV998803NjY2e/bsUZfn5eVNmzatU6dOTzzxRL9+/cws NG6zSE1NDQwMlIWy9+vXr5tZaEkskf3K4Tg7O7dv3z4iIkK9jKbGEgmE8vzzzz830yRLTohE048/ /liejB07dvv27crCOXPmqAkzJSVlwoQJ6vpfffVVUFCQ8rygoKBRo0avvfaa/gZXrlwpJ/aHH35Q GrBu3bo33nhDDqRLly4JCQman6+sFhMTY/7ATR2LLPTz82vbtm1AQIC60JJ0ar4Tvv/++23atGnW rJk0MjY21rizWd4HlMZU2C2t3w0yMjIcHBx++eUX0ikA0ikAoCGmU5k9S858/PHHv/zyS2W5hIrp 06fLdH/Dhg19+vSRJYWFhZJ/Zs+eLSsXFRXJkt69e6vpJTo6um/fvuoc3cnJSeJQenp6aWmpvOzQ oYOEpe+//17m6BK3NFsyYsQIJaL4+PiMHz9eXS4t8fT03L17d3Fx8X/+8x/zCw3aLGTeL+mlrKzs p59+Uv+mUXOhJbFEzoC/v//ZckOHDh0+fLh+LJFNyUI5RfqNN25ShSfk9u3bkiSVL7jKOVESqWzc 0dHR3t5eyUKyFwk26lskaqqfxfHjx+XtiYmJ+tv8n//5H1mofPVXGuDi4rJmzZrTp09LyJfNlpSU GH+++mHSzIFrHovs6NSpU7KdsLCwiRMnWpJOLemEktkiIyMlusvKd+/eNe5slvcBC7ul9buBTqeT T3nfvn2kUwCkU23cqQWwDmoNtZJOH7OxFRJd9u/fryy8cOGCvIyPj5fJd1pamsyVc3JyHhh989NM Op05c6a6mrycPHmy8vzDDz90dXU1bsalS5dkLxkZGfJ806ZNjz32mHKNS2mJwV8/mllo3Obnnnsu ODjY4M9lNRdWGEsyMzNlF8p1xQfl9/KRl9Jy5RiXLFkyZcqUkSNHStIz36QKT4jkbXmjcneow4cP P/HEE/fv39+7d6+kIG9v7x07dkgMa9++vf49gbp06aIejuRS9TKpSjKPfMoffPCB0oC33npLWZ6X lycrHzt2zPjzVcOk+QM3fywbN250d3evMJ02btzYwk74hz/8QbKffiPVzlapPmBJt6ytbuDh4SFV QDoFmBOSThnCgDqUKADrpNMRNu0lCkqEePXVV5WFycnJMp8eNGjQs786evRopdKpfgjRf7lt2zYX FxfjZsgKrVq1eq3c1KlTZe+rV69WW/Ldd9/pr2xmoXGbJZMEBgY2atRo/vz59+7dU1bWXFhhLFF2 kZ2drby8cuWKvDxy5IhyjLKmvExNTa2wSRWeEImd8kbZvpIqW7ZsKZuaPXu2ZMs333zzlVdeSUlJ 6dWrl7q+xB71ipwabg3iTVZWlpr9DD6gdu3arVu3zkw6NX/gmseyc+dOX1/fp8t17ty5wnQaGRlp YSc0TqfqNivVByzplrXVDdzc3D766CPSKcDvcdIpQxjASIQGl06Vvzs9fPiwnZ1dUlKSPD9//rzM p42/W2icTteuXas8X7x4cZXTaUlJiSx8/fXXN/wqODi4R48eaks2btyov76Zhaa+DynhwcnJ6b33 3qtwoZlYooTGgwcPKi/37t0rL5Xrvcoxzp07t3379tIS802q8IT88ssv8lkogUdMmDAhKirK1dVV EpHs3cPDQ3akf4b/8pe/LFq0SH15//79jh07vvjii/rblMN0cHDIy8szaEBubq40cseOHWbSaYUH bnAs6enpEgWVJLxlyxZL0qnypW5LOqGZdFqpPlDldFrT3aC4uFhOwldffUU6Bfg9TjplCAMYidBA 06mQWbVM35WvHfr7+w8ZMkT5MuSdO3du374tTyIjI/Vvlzp+/PjJkycXFRVt3bq1ZcuWVU6nkkba tm2r//efyr2RlEtMssc+ffp8++238vzHH39UbueruVCzzSkpKTqdrqyszNfXV/3vQzUXVhhLZC/9 +/cPCwuTLRcUFISGhvr4+MhG1GOU5+Hh4ZIelXNoqkmW5KKgoKAPP/xQeb5582Y5vUpL5Gw3a9ZM Xp45c0Zd2c/PT/lqruqTTz6R1SQ4KS+PHz8un+y7776rfiIBAQFyCCUlJStWrHB0dNT8fNV2Vnjg BseSmpoq6TQzM1POw5QpU1q3bm1hOrWkE5pJp5XqA1VOpzXdDc6ePdumTZsq/OfDpFOAOSHpFAAj ER6ddHr37t1u3bpJLpLptUysR4wYYW9v7+np6ezsrFzHk0TUtWtXNzc35bLYoUOHOnXq1Lhx47Fj x0ryqXI6HT16dFRUlMFCb2/viIgIeXL16lXZgoRVmbK7uroqN+zRXKjZZmmwpCN3d/eQkBDlPjqm FlYYSx6UXxWUKCLh0MHBQX6kXDHTP0ZJQbJNLy8vyS2mmmRJLjpw4EC/fv2U//cyOzvb1tZWYqTy o+HDh3fv3l1dMy8vr0OHDsb/B49sWU6OHGOXLl1atGixbt06JUEpDRg5cqRsRHYtUVC9DGjw+eq3 s8IDNzgW6RJNmjTp2LFjbGyspF/lxkiWpNMKO6H5dGp5H6hyOq3pbjB9+vQ///nPNVr1/LoBmBPW 73TKnVoA66DWYP10av6nhYWFyr159EkyVLNQSUmJMv+uaT///LPxjjQXGrf5djmD1TQXWkgCYaWO WvM0VigmJmbNmjUVribB5uWXX9b8kQS88+fPS3YyyK7qJT75KNXIqvn5PsyBy8rKdu6Uq/JHX4Wz Z2EfeEg10Q3+9a9/hYWF1W7VA2BOWNfTKQDg0UunusK7pxdtiHcKZp5aZ33xxRcVrjN37lyD/zym QqauYaLW7dq1S/kiAOkUAOkUANAg0un1Q99+5Tfzc/tBslx5cMYalM2bNycnJ3MeGlTVk04BkE4B AHVonqp/sdTgwRkDSKcAQDoFAFhjnmpwsZR0CpBOAaBeplPu1AJYB7WGapyn8uDBg4eZB+MkwJyw vqZThjDAaomCk4Aa6lo/Rn+2u9uL8e2Cd7qMYp4K8AsFACVMOgVAraE2u9b1Q2knXn77i2Z+SV3G fdHUj3QK8AsFACVMOgVAraHWulZRboHBpVROEcAvFACUMOkUALWGWutayqVUOh7ALxQAlHC9Safc qQWwDmoNtdK1inILOEUAv1AAUML1I50CAAAAAEA6BQAAAACQTgEAAAAAIJ0CAAAAAEin/w9/WA9Y B7UGuhYAqh4Ad0Uyh5uSA9ZBrYGuBYCqB8D/KMMABzASga4FgKoHQAmTTgFQa6BrAaDqAZBOGeAA RiLQtQBQ9QAo4bqeTvnDesA6qDXQtQBQ9QC4KxIA1ILo6OjnH3URERFLAQAAGhiZAslEaN26daRT APWDt7e3DQAAAB5Rffv2JZ0CqB9kwFJGrt8+ipRDGzx48J8AAAAamM6dO5NOAdQnzz//vBJN8x9F CxYskKNbunQpHzQAAGiY07zBgwdXczrlD+sB62iAtUY6pWsBoOoBPJIlXFPplJuSA9bRAGutCul0 zpw5o0ePzs7OJp3StQBQ9QAlTDoFwEhUa+m0Z8+e8pbLly+TTulaAKh6gBImnQJgJCKdVmz27Nmk UwBUPQDSKekUYCR69NPpDz/8MHHixPbt27do0eLZZ5/dt2+fso6p5cOGDevSpcvevXt9fHzkR6NG jcrMzKyhaHrq1Cnlnr2kUwBUPQDSabWlU/6wHrAO7opUqXR648aN3r1729nZzZ8//29/+5uzs3Pj xo1PnDhharn63l69er366qseHh7yfPHixTURTb///vsnn3xStu/i4vLTTz/RtQBQ9QAaWgnXVDoF gDqYTuPi4uSJt7e3slyyqLycMWOGqeXqe1NTU+X5oUOH5PmAAQNqLpp27ty5LkRTAAAA0ikA1GA6 /e///m95Eh4erizfvn27vAwMDDS13OBbwTk5OfL8scce+/nnn6v3C71qNM3IyOAjBgAApFPSKYBH PJ3+/e9/lye+vr7K8mXLlsnLiIgIU8sN0qly7dTFxaV6o6mnpyfRFAAAgHQKoAGl0ytXrri6uj7+ +OMbN25MTk5+6qmnbG1t9+7da2q5+t7p06cfOXJk2LBh8nzu3LnVHk3ryN+aAgAAPILplD+sB6yD uyJV9p69qamp/fr1U26N265du9jYWGUdU8uV97744ou25UaOHJmVlfVI3gaJrgXwC4WTAFDCj2Y6 5abkgHXwP8pUzcWLF3/88UdLlqvJVkiGbDi3QWIYB/iFAoASJp0CoNZqPJ1W7bprg7oNEsM4wC8U AJQw6RQAtWaOt7e38v3bBVYRGBj47LPPRkVFVdcGZ8+erbS/jt8GiWEc4BcKAEqYdAqAWjNHuepY 39X92yAxjAP8QgFACT8i6ZQ/rAesowHWmnLttHPnzkvrs7p/h16GcYBfKAAo4UcknQKANYctAAAA kE4BgHQKAAAA0ikAhi0AAACQTgGAdAoAAIC6m075w3rAOhpgrZFO6VoAqHoAj2QJ8z/KAPVbA6w1 0ildCwBVD+CRLGHSKcBIRDoFXQsAVQ9QwqRTANQa6ZSuBYCqB0AJk04BRiLSKehaAKh6gBJ+lNMp f1gPWAd3RQJdCwBVD4C7IgEA6RQAAPx/7d0JfEz33sdxEaUlqCUSzdJrS+NWivbaL0ISEUIbNKWa BnUVpZZHrfeiXMurWiSUVlXdctsqFbXUVgkJbi3RXoqHUqqISBpLXEKWPr/6Pz3PPDNnTibbTCY+ 79f/5TVzcuac/znzX87XbADpFMADacCAATJsyb+cCgAAgDJ/mUc6BVB6TZs2TYat6dOncyoAAADK /GUe6RQA6RSOkZ2dnZubWzaOJS8v7969ezynNEIAgIPTKR+sB+zjAexrpNPS1rQ2bNiwzMS///3v ouw3MDBQnuKycQ7XrVtXo0aNB6TBHD169ODBg6ZLUlJSpD1cuXLFsRX75JNPlum5devWg9AImVAA ujDp9Dd8KTlgHw9gXyOdlram1bJlyyZNmgz63datW62t+fPPP58/f97h6dSWahTLAx+odBoZGfnF F1+YLpk8ebJ01alTpzq2YuPGjVMtU1qpu7u71lAzMjJIp0woAF2YdAqAkYh0WtbSqQQAW9bs0aPH 2LFjHZ5ObalGsTzwwUmn9+7dq1OnTmZmprYkOzu7bt26fn5+Pj4+peRdsvLctW7d2pY1SacA6MKk UwD0NdJp2UmnV69e7dWrl2Qzf3//+Ph4WTJr1qwqVarIEkksGzdulCXp6emDBg3y8vKqWrVq8+bN TYPBzJkzfX1927Zte+DAAcs9RkVFxcTEjB492sPDo2HDhhs2bNCWL1y4cOjQobKXGzduyPZliazj 6ekZHR2tXiuzrIZlVXXrZuMD09LSnn322Zo1a8qj5LToplOzeupuZ9++fSEhIbJQzkNqaqpWK8sj EuHh4atWrVK3V65cKRWwdkIsT7ju3jURERGrV69Wt4cPH/7cc8+p24mJiX369NFW27VrV5cuXUwf GBcXJ3n14MGD0ltNX07XrYPtFdM9LboLbUmn1s6nlk6vX78ut9esWWNQJdlCbGyscYtlQgFAFyad AoxEpFPYKZ3279//m/u0D50GBwcPHjxYEtGSJUsCAgJkSWZmpgSYYcOGySV+VlaWWqdBgwZbtmy5 e/fu8ePHtWBQt27dkSNHfv/995IEJB1Z7lHW8fb2nj9//tGjRyXV1KpVKycnRy13d3efO3fu6dOn c3NzZXdBQUEn7uvcuXNYWJi1aphVVbduNj6wa9euoaGh58+fv3jxooRG3XRqVk/d7UjOkWCZl5d3 7tw5qYNaqHtEokmTJosWLVK3FyxY0KxZM2s7sjzhunvXTJgwQSVSeYicZ1dXVxXh5DxIHtNWGz16 tFYBpVu3bvJYudGiRYvevXtry63VwcaK6Z4W3YW2pFNr51OlU9mULJQjNa28ZZVsabFMKADowg5O p3ywHrAPvhUJDm9akk69vLza3xcVFSVLzp49K89RXFycXPQnJydLpElJSfn1/78zVq0jUcoyufXr 10/dXr58uY+Pj266mzhxorqdnp4u29m/f79aPmTIELX8xx9/lOXqRc5f7391k9z96aefdKthVlVr dcv3gRcuXJCFkrLUOtbe2WtaT2vnqkOHDirlao8yOCKDdGq2I7ODsrZ3ze7du6tWrXrv3r1t27ZJ eGvatKkclARdT0/PkydPaqs1bNjQtKpSK9nUDz/8ILeXLVv20EMPqZc0DepgY8UsT4u1hfmmU4Pz Kedt6tSpL730Uvfu3dV/fBhUyZYWy4QCgC7s4HQKAKTTB4TlO3vj4+PlOWrTpk273yUlJZmlO7XO kSNHLJOb9pG/VatWeXt766Y7048F1qlTJyYmxmy52v7ly5fV3YsXL8rdPXv26FbDrKrW6pbvAyXL me7UIJ2a1dPyXEnWCgkJqVChwvjx4+/cuWN8RAbp1GxHZgdlbe+a7Ozs6tWry2rDhg1777333njj jVdffTUxMfHJJ5/U1pG0Zvaiq+z00UcfHXnfwIEDZRfz5s0zroONFbM8LdYW5ptODc6nnDdZU+7u 27cv3yrZ0mIBAKRTAKRTOCadnjlzRp6j7du3G6Q7tc7SpUuLmE7T0tJkO5IDzZafPHlSln/99dfq 7rZt2+SuejXPshpmVbVWt3wfmJKS4uLiol7ItTGdWjtXioQld3f3xYsXGx+RpNOFCxeq5VOmTNFN p7oHZbx3pU+fPvL8+vj4SJCTvdevX3/UqFGm/zvw1ltvTZ48Wbubk5Mjz9rrr7++5HehoaH+/v7G dShQxUxPi/FCg3RqcD7VeZPD9PT0lJoYV4l0CgCkUwAMW6TT0ptORVBQUKdOndSbLW/dunXz5k25 MWbMGFmorSO3AwICDh8+LLdPnTqlvtnVxnQaHBx87do1CUJz5sypVauW2r7pY2VrzzzzTP/+/eVP smZkZGSLFi3y8vIsq6FbVd262fJA2WlUVFRGRsahQ4eaNm2abzq1tp3ExMTs7GypcKtWrWJjY42P qHfv3v369cvKylq5cmX16tV106m1g9Ldu6kVK1bINlWuk11UrlxZ7h47dkxboX379logF5s3b65d u7bp5z/VdyOpVxp162B7xSxPi7WF+aZTg/OpzpvclqdS0rj2bmfdKllrsZK3pXEyPgAA6RQA6RQO TqdyQd+tWzdXV9cGDRp4eHioN0xKpGnUqJGvr++OHTvk7qVLl+TKXp7NmjVr+vj4qK8asjGddu/e /YknnpC/uru7ay9/mYWx06dPS96QKOXm5iaxRL0sZlkN3arq1s2WB27ZsqVatWqyUOLWokWLbEmn utuRHclj69WrFx4efvv2beMjSkhI8PLyqlSpUkRExOzZs62lU92D0t27qcuXL7u4uGhBKywsTM68 9tf09PS6deua/mZMz549LduDBPXo6GhrdbC9YrqnRXdhvunU4Hxq501Cr2zzqaeekvhqrUrWWmxI SEjjxo0ZHwCgVKRTPlgP2AffioTS3LQyMzOvXLlitlCiiGmY+eWXX9Slv+20l7ZkU+rFLgMSn3S3 b1YN3arq1i3fB0qksdxUIc7VzftsPKKcnBwbT6PuQekevi0kjw0YMKCgj9Ktg40V0z0t1s6VLay1 kAK1ano9gJKQlXbtQevC/KIM4Nz4RRk8gE3L7CVBONCoUaM2bdrEeaDXAyihXrnjT9GXv9r/4HRh 0inAxQTpFE7WtFasWBEfH89zBDChAGW+V0pZU771umqByaPmG7+USjplgAO4mCCd0rQA0OsBlGA6 1cqa8q0MXkolnTLAAVxMkE5pWgDo9QDskU6NX0olnRrhg/WAffCtSCjRKZBCoVAoFIqTFtIpAJBO nTidFvqvAACgpP/jeGuTfnt7Tfiq8QubG/Y6MWdlmZy4SacASKcgnQIAUErT6Tq3jolhoxO7j/ni 0aB9fSZe2XkgLzunrE7cpFMApFOQTgEAKI1Ts+mLpQX6oCnpFABIp6RTAABQbFOz6YulD8LEzbci Ac6Nb0UC6RQAEwpQJhXlB05Jp1zHAKUuUZBOQToFwIQCMHGTThngAC4mSKdMcgCYUAAwcZNOAQYm 0ilIpwCYUAAmbtIpAxzAxQTplEkOABMKACZux6dTPlgP2AffigQmOQBMKAATN+kUAEinTHIAAICJ m3QKgHQKJjkAAJi4SacAQDplkgMAAEzcpFMApFMwyQEAwMRNOs0PH6wH7INvRQKTHAAmFICJm3T6 a9k7HUAZG5hIpyCdAmBCAZi4SacMcAAXE6RTJjkATCgAmLhJpwADE+kUpFMATCgAEzfplAEO4GKC dMokB5GXl3fv3j3OA5hQADBxOyyd8sF6wD74ViTYf5LbsGHDsvt27tx59+5dTp2xdevW1ahRg/MA JhQApFOHpVMAIJ2W1UmuZcuWTz31VGRkpK+vr5ub2969ew0e+PPPP58/f74UHm+hK1bQB5JOAQCk U9IpANIpSiqdTpgwQd1++umn+/bta/DAHj16jB07thQeb6ErVtAHkk4BAKRT0ikA0ilKPJ1KVOvZ s6e6ffXq1V69ekkS8/f3j4+PlyWzZs2qUqWKLPHz89u4caMsCQ8PX7VqlVp/5cqVzz77rLodFRW1 cOHCoUOHyso3btyQu7GxsTNnzvT19W3btu2BAwcsqyTrxMTEjB492sPDo2HDhhs2bNDdVHp6uiyR dTw9PaOjozMyMnQrZll5IY8dNGiQl5dX1apVmzdvbvsD09LS5NBq1qwpjxo3bpxuOjWrp+529u3b FxISIgvlPKSmpmq1sjwi28+t5UFZOwoAAOmUdAoApFMnSKeSZyQLVaxYcf369Wp5cHDw4MGDJf8s WbIkICBAlmRmZnbp0mXYsGGyclZWlixp0qTJokWL1PoLFixo1qyZuh0YGOju7j537tzTp0/n5ubK 3bp1644cOfL777+X1BQREWFZJVnH29t7/vz5R48elbhVq1atnJwcy01JBYKCgk7c17lz57CwMN2K WVZeLWzQoMGWLVvu3r17/Phx2x/YtWvX0NDQ8+fPX7x4UUKjbjo1q6fudiSZS7DMy8s7d+6c9hFf 3SOy/dxaHpS1owAAkE7LSDrlg/WAffCtSHBIOq1UqZKLi4s8ETt27FALz549K3fj4uIkMiUnJ7u6 uqakpPxq8T5YgwQ1ZMgQ0+TWr18/dXv58uU+Pj666W7ixInqdnp6uux9//79Zpv68ccfZbl6kfPX +9/nJHd/+ukns4rpVl4tlEqa7TffB164cEEWSvxT61h7Z69pPa2dvQ4dOqiUqz3K4IhsObe6B2Vt 72BCAUA6LSPplC8lB0rDwEQ6RQml0zFjxqSmptarV2/EiBFqYXx8vDwvbdq0afe7pKSkAqVTeWZN k5t2d9WqVd7e3rrpzvQhderUiYmJMVuuanX58mV19+LFi3J3z549ZhXTrbxaeOTIEYN0qvvA3bt3 m+7UIJ2a1dPy7EkuDQkJqVChwvjx4+/cuWN8RLacW92DsrZ3MAgAIJ2STgHQ10inpT2dqs+dSgwr X7785s2b5faZM2fkedm+fbtBllMJauHCher2lClTiiudpqWlyd4lB5otP3nypCz/+uuv1d1t27bJ 3R9++MGsYrqVVwuXLl1qcES6D0xJSXFxcVEv5NqYTq2dPUXCp7u7++LFi42PyJZzq3tQxnsHgwAA 0inpFAB9jXRa2tOpGDVqlAQn9UbQoKCgTp06qbeh3rp16+bNm3JjzJgxslB7bO/evfv165eVlbVy 5crq1asXMZ0GBwdfu3YtJydnzpw5tWrVUns0fWxubu4zzzzTv39/+ZOsGRkZ2aJFi7y8PMuK6VZe lgQEBBw+fFhunzp1SrZm4wNlp1FRURkZGYcOHWratGm+6dTadhITE7Ozs6XCrVq1io2NNT4iG8+t 7kHp7l1CrJxYugaDAADSKekUAH2NdOoE6fT27dt+fn5dunSRgCQZtVu3bq6urg0aNPDw8FBvNz12 7FijRo18fX3VJ1QTEhK8vLwqVaoUERExe/bsIqbT7t27P/HEE/JXScjay4lmmzp9+rTkN0lrbm5u rVu3Vi8zWlZMt/KXLl2SrUl7q1mzpo+Pj/oaJFseuGXLlmrVqslCyYGLFi2yJZ3qbkd2JI+tV69e eHi4nGrjI7Lx3OoelO7eQ0JCGjduTNdgEABAOnX6dMoH6wH74FuR4JBJLivtmrU1MzMzr1y5YrZQ EpF6jU7k5ORcu3at6BVWoUtSsWxcvXhoID09XXenphWzVvlffvnF8rH5PjA7O9tyU/my3M7N+2w8 ItvPre5B6R4+mFAAkE6dPp0CAOm07E1y2Zm3j05eEuceWhrmPLOXBAEAYOImnQIA6fSBmOR2tR+y xrWN3FDF4RVesWJFfHw8TxwAgImbdAoApNOyP8mZvlhqVjhjAACQTkmnAEinpNMSn+RSEw6bvVhK OgUAgHTqlOmUD9YD9sG3IqEYJzkKhUKhUChlppBOnT6sA2Xsv81IpyhK0zq14NMtfs/H1Qn90rsH r50CTCgA6MKkUwD0NdKpI5tWakLygQEz1lZuv7lhr7WPtCedAkwoAOjCpFMA9DXSqcOaVlbaNbOX UjlFABMKALow6RQA6ZR06rCmpV5KZZAHmFAA0IWdJp3yrUiAffCtSHBI08pKu8YpAphQANCFnSOd AgDpFAAAAKRTAKRTAAAAkE4BgHQKAAAA0ikA0ikAAABIp7/hg/WAfTyAfS06OlqGrcDAwGkoScM6 9uAkAPR6AHRhe+rYsaNc5g0YMKCY0ylfSg7YxwPY19SwBQAAgDIpMDCQdAqQTp1DTEyMjFkDBgyY jpLUp5wXJwGg1wOgC9uTXODJZZ5c7JFOAdIpQNMC6PUA6MKlC+kUYCQCTYumBdDrAdCFy0Q65VuR APugr4GmBYBeD6AMd2F+UQYAAAAAQDoFAAAAAIB0CgAAAAAgnQIAAAAAUEzplA/WA/ZBXwNNCwC9 HgDfimSELyUH7IO+BpoWAHo9AH5RhgEOYCQCTQsAvR4AXZh0CoC+BpoWAHo9ANIpAxycrsdSnKvw XFNozGBOodABQX+nY/KtSCibI0te3hGKs5QiplNOIKVsNGYwp1DogKC/0zH5RRkwslBIpxQKF8dg nKEDAvR30inAyMKwRTql0JjBnEKhA4L+TsfUTaefffbZd999p929cOHCp59+SmMFIwuFdEqhcHHM nEKhA4L+TrFrOq1fv/6cOXO0u1u2bHn88cdprGBkoZBOKRQujplTKHRA0N8ppFOAkYVhi+eawsUx mFModEDQ30mnv6fTffv2hYSE1KhRw9fXNzU1VS28evVqr169ZKG/v398fLxaGBUVtXDhwqFDh8ry Gzdu0NbByEIhnVJozGBOodABQX+nYxZbOm3btq1kzry8vHPnzt29e1ctDA4OHjx4sETQJUuWBAQE qIWBgYHu7u5z5849ffp0bm4ubR2MLBTSKYXGDOYUCh0Q9Hc6ZrGl0w4dOoSGhp4/f17769mzZ8uV KxcXF3fixInk5GRXV9eUlBSVTocMGUITByMLhXRKoTGDOYVCBwT9nY5ZyHTq5+f35ptvanc3bdok eVXdllwaEhJSoUKF8ePH37lzR5bEx8dLOm3Tpk273yUlJal0Om3aNJo4GFkopFNK4cq9e4dycg5z cYyyPac4YzunA4L+TrFrOu3cuXNYWJh2d8WKFZI5TVfYs2ePu7v74sWL5faZM2cknW7fvt1sI6RT lMKR5dNP53777Wfa3Z9+2vrJJ3OKvRNevrzz/ff/mpKy086dPzc3OSZmvNyIi5svFfjww+lysLLQ 4aPSypUzMjL22DmdqpMgZceOpVlZB5xoEJenbOPGmOnThw4b9vzcuaPWrXv72rVEJ52QVJuUBnDm zCa15O7dg/Kk/PjjZu26fNmyv8m/ug8PDPzTtGmv5ntlv2XLotdf7zdnzuvx8cucujHDea9WizLs 29LODcqmTTGHD39SxIZdLBuxf3+kA8Ke/d1Jrysc3iuLJ53Onj3bzc3t0KFDcjslJaVTp06TJk1S f0pMTMzOzs7Ly2vVqlVsbKxaGBQUJOuot/veunXr5s2bpFOUzpGlfn2v2bNHanc3b459/PG6xd4J J09+pVy5clOnDin2LV+4sPXcuS3W/jpx4sB//GOm3GjZsslTTzUKC2tXo0a1xx5zv3EjybEj44kT 67t2bWstgZRQOlUnITIyxNfX082tclLSCqeYRdLSEoKCWnp7e0yaNGjx4oljxvR/8skGu3a976Tp VLXJDh2elsNRS/btWym9Y9asEepuYuIKP7/Hi3LV3r17+1atmsybN+bll8P79Al26sYM502nBRr2 zUbyIqbTvn1D588fV8TZpHAbcXh/pAPCnv3dSa8rHN4riyed3r59OzIyUsbZ+vXrV6hQITg4OCMj Q/2pUaNGNWrUqFevXnh4uKymFkqC7datm6ura4MGDTw8PPbs2UM6xQObTuWytW7d2nLB7ePjUexv 1urRo8PYsS/p/mnt2nl//nMzbQCdMGGA3Lh4cfvDD1dUL6g6trzxRrS1mpdcOlUnQcrTT/vLtZdT zCJDhvSqV88rNXWX2SuQzhhNtTYpV97ydKiFc+eOKl++vEyW6u6UKa+MHNm30On09OkvZWuXLu0o G40ZTppOCzrsm43kRUynxT6bFLo4pD/SAWHPdOp01xWloVcWTzpV0tPTk5OTL1++bLb85n2W62dm Zl65coU2DSdNp3v3fhQS0rpGjWq+vp5XrnytFkpI6NWrsyz09/+D9vpVVFT3BQvGDR3aR5Zfv27+ suT69e/UqVPzwIFV5cqV++qrxdrylJSdzz4bWLNm9ebN/adPH9qixZPGu5BIOWPGcKlM27ZNv/nm Y1n497+/VqXKI7KmXAN9+eVCs/1KDFi5cobZAJqRscfNrbJa2azaaWkJssTDo5anZ63o6B6//LJb 1omI6LRq1d/VRoYPj3zuuU7q9p49H6r/byv0WZLxUWpy69Z+h6RTuQ7r2bOjQW11j0v3FEkJD2// 8cf/e5Y++uhNeVp1D1kePmjQs15edapWrSJPusHetSK7kFnk/ff/au1lVd366LYWawdlUHnZiGTF xx5zf+aZxqdObZDVGjXy/eMf62/aFFO47qC1SWk/rq7l1V+lAtKWpCOoyC0TvHRDaxuXq/apU4eM Hv2iHHXDhj5xcfMtX/9xcXFZvnya2fJ8q/rSS93ffnustv5rr0UuWTLZ4Y0ZTppOrQ37ut3NciRX 6dSyCxt0edMGKXdjYyeokCzbNC0q9ErXbt++ee3ajwYHt7I2m2gbKcRQ49j+SAeEQ9Kps1xXlIZe WZzpFHig0qnMtdK15Ir5xx83ax8nkLl88OAI6WnvvjspIKChdsXs7l5jzpzX5Qre8r/Ju3X7sxq8 JH/27h1k+r/jnTq1kOtaGaQk9UkHNt5F3bq1R47se+zYWhkFJDTKwps393bp0mbYsOdlaLhz5xvT nd64kSRXRdqbTGQA7d+/mwxGMjLKlf3duwctqy2bCgpqefz4F1I6d24RFtZO1pGaq0QqZ6BWreqS KNTQKTuVK5KinCW5bJKtbdv2rp3TqZwrGfErVnzoiy/eMait7nHpniIpTZo01C7j5s8f16zZE7qH LDtq0MBb2phs8Pvv1xnsXSv/+tfH8jx+990a3SOyVh/d1mLtoAwqL5Plm28Ok5XbtWsmUfDFF8NO nlwvE5L2smeBuoNpm5S9V678sFwES2Uklx48uFr+JEchfeGRRyqpmGdt497eHu+881///vfnMiVL m8zONu9xkyYNkql3wICeV6/Gawvzrery5VPr1fNSCVkeKNVQ73J0bGOGk6ZTa8O+bnezHMmtdWGD Lm/aIE1fepVtqrJ06RQZ99RnzNate/vbbz+Tfcm88MILXazVQdtIQYcax/ZHOiDsnE6d67qiNPRK 0ilQyHTaocPToaFtTD+Hc+bMJrmGXr/+HRlEDh/+RK5HL1/eqTrhkCG9dLd//vxXsppEULn9/vt/ feihCuo/zGSJbGrjxhjtHY8qnRrsol+/rmrlDz6Y6uPjYfxeLBmkZDvaF3LIANq0qV/r1gEyWHz0 0ZtqcDGt9tmzv+1XewE2Lm6+3JXKJyR8ULVqFUmzW7e+K4OmbESqKgON5JYTJ9YX8SzJybf2qmAJ pdNKlSrKiHz/a9uWGNfW8risnSLjWUQ7ZLUjs89xWdu7VqSFyAoXLmy1PByD+lhrLZYHZVz54cMj tQ+LNm/uryYYqZLMSYXoDmZtUv1HiYTMP/6xvtz18qojVf3HP2bKcuONS2W0/3KWdfbtW6n7TRXS RGWbKgzbUlW5Oq9S5RFp8HL77bfHdu3atjQ0ZjhjOrU27Bt0N8t39lp2YeMub9ogLd8YfPDg6sqV H16xYrpZVZcsmSyXm8bvLi7EUOPw/kgHhN3SqdNdV5SGXmnXdJqdefvy1v0n560+Nm2Z/Hth7S5Z QptGaR5Z/Pwenz59qGkYkKtMdVtGELlQrlDBdfz46Nu3f/u/5F273r//a0lPtWvXTJXExBXGnxGS 5Y8+WnXkyL5SBg7sKQ9/663R6p2Nclt737+WTm3Zxccf/93bO590KtFRtvPzz9vM3nwio56kTXXI pttU+9XqIw+Uu7t3L79371D16m7y12HDnl+6dMobb0S/+mpvqfyTTzYo+lny9fW0fG9JiabTMWP6 y2WiXI2NGPGC6YFb1tbacVmeIuNZxOwMJyf/v+/AtLZ3rRw9+rmsYLbQ+CkzaC2WB2Vj5SdPfiUo qKX2TZ4qnRa0O5i1ydmzRwYENFy8eOLQoX3k7vPPh0gHefHFsHnzxti+8Tp1ai5c+Ibu0/3LL7u7 d28vVZUJ1catvfxyeHR0D7nh7/+HdeveLg2NGc6YTq0N+wVKp5Zd2MYub3lXhn25DJ0y5RVtyYYN C1q1avL00/5S/vCHx4zrUIihxuH9kQ4Iu6VTp7uuKA290k7pNCvt2rFpS9a5dZCdmZZ1bh2/Gxcj f6Vlo3SOLKbvo5Dy4YfTpWuZriDDhLt7jUWLJsrtH37YKJ3Q8v171jphdvZhma1ff73fu+9OUiU0 tI10afnTf/7zLxkRtP9pW7JkskqntuzClnR669b+8uXLqzHO7KMRMoCqbGm6TZUcdu58T93duvVd uav+779Pn+Bx41728fGQAVRWkPQ+atSLZsdbiLOUlXVAavj11+/b/3OnCQkfyK7Vhyet1dbyuAxO kcwiCxaM077UR3cWUTtSH9LQivHepdy5802tWtX/8pde1sKebn2MLxlND8rGyuum04J2B7M2+c03 H7u4uMhmV6+eJXelDo0a+dau/eixY2tt3PjVq7/9tvbatfMMXsJSn/qzsaoyy1ap8sjmzbFyKa++ g9fhjRlON6cYDPsG3c2WdGpjlze7e/16kuz0hRe6aF+ldurUBrk+VrPPihXT802nhR5qHNUf6YCw Zzp1uuuK0tAr7ZFOUxMOb/QOU3H0K/+eySPGH5s247txU7Y1672mQmtZGFe7y+Wt+2ncKIUjy6xZ I9zcKh88uFr9PF2nTi20H7rYs+dD6Xsyo7dq1UT7klu5mJZ11BszMjP3qZ9msdYJZZySq23Tn8BS X5Kh/mNJLgVkuFm16u9Tpw6RYUjWtHEXphcBY8b0l5WtfSjxgw+mmg6gcjjHj3/RuHE99Z2optvM yTn8zDON+/fvJrvLyNgTGRnSosWT6mpGEnv16m6tWweosFS58sNy9+jRz4t4lqQmNWtWt/b7YCX9 rUgSsGV6UO8/0a2t5XEZnKLevYP69esqJ+ejj96Uk6M7i0iRvQQENDx06J9y+7//O069UVZ372Zv vXN1Lf/222PVByzlURs3xqiHW6uPtdai+2TZUnnddFrQ7mDWJuVwqlWror1vWX301PTq1trGg4Nb yfHKw2fPHinR3eyMSbuSqwT1yWppunIVrn5Y1Zaqypl5/PG6derU1AYBhzdmON2cYjzsW+tuZiO5 bhe2scub3pX+Ltm4TZuntPdKqK9mkX5x9uwmGQBfeqmb9pUH1upQiKHGsf2RDgj7p1Mnuq4oDb2y xNOpRNN1bu1lH5JFM458abbv6ye+2tn6BfnrmgptLm1Kon2jtI0s//nPv2Q4uP9rSV7SReXCV/vC tEaNfGXarlfPKzy8vaym/cB6t25/lrTQoIG3h0ct3XdVaaVnz47jxr1strBpUz/1vgjZVFRUd0l9 0smXL5/m6+tp4y5MLwIkJUo95bHay7Ba2bFjafPm/uo/t2QALXdfw4Y+w4dHqndXmlX71KkNMizK IChxXWql/vdOyqVLO1xcXLRP54aFtXviiT9ojyr0WRo8OGLmzNcc9YsyUlU/v8clLMlQq1tb3eOy dori45d5edWpVKliRESnWbNGWJtFLl7cLkvkWZAk4+Pjob56RHfvZkWah8QwyYRy5uWplyrJJGRQ H2utRfegbKm8tXRaoO5g1ibVf9Bor9vIwsqVH5ZWoa1sbeN9+4aq8yDXAdp/OZt+lka2U7VqFTlY ecb/+c/ZBarq3/72F2ntaqouDY0ZTjenGA/71rqb2UhurQvb0uVN76qvVZMe8eijVVVR1ZC9P/xw xccec1+27G8ytqgvRjKoQ0GHGsf2RzogHJJOneW6ojT0ypJNp1lp1zZ4dpEdHBk9Mfee1V/0kr+q V1DvpKTTxFGqRhbt61UOH/7E8tefbtxIsnwtS300XPtyl2IpL74YFhraptC7kOFJ9yvRYmMnvPPO fxWoJnIqMjL2FOghhThL+/f/o3//biX0C3XGz7W1Yllba8ele4qysw/beN7S03UebsvTfeHC1uPH v7D8pdMCPWW6B2V75W08dQaloG3SbOPXrydlZR2QkyBt3tqPvkpf+OGHjbo/5lbonuuoxgwnnVMM ikF3szaSF32U1t2I2ldm5j4pttShcPu1c3+kA6L09PdSe13h8F5Zsun06F8Xq1dNs28fNK7Ejj89 L2t+Ny6GJg7nupIouTJ37qjx46NXr571yivPVanyiOWrQMVSPv/8rVL4Y9BffrnQ7CdwHJ5OKXYr pbNNls7GDOYUShELHRD09zLQMW1Np9mZt9XXIFm+odeyXD/x1ZoKbda5dbx37SatHIws6jP0M2YM Hziw56RJg8y+co1COqXQmMGcQqEDgv5OxyxAOr20KUk2vbVJhI312PGnSFn/wtpdtHIwslBIpxQa M5hTKHRA0N/pmMWWTk/OWy2bTh4x3sZ6fDduiqwvj6KVg5GFQjql0JjBnEKhA4L+TscstnR6bNoy 2fSxaTNsrIeseX/9ZbRyMLJQSKcUGjOYUyh0QNDf6ZgOfO30b7x2CkYWCumUQmMGcwqFDgj6Ox2z mNNpwT932o/PnYKRhUI6pdCYwZxCoQOC/k7HLOZ0ev87ezva/J29W/nOXjCyUEinFBozmFModEDQ 3+mYxZ9Of/3t907fU793mnsvn9+P3tn6JX7vFI4dWSjOVXiuKTRmMKdQ6ICgv9MxC5BOs9KubfAM kx0cGT3RIKAeGT1V1omr3eVOSjpNHAAAAABQzOlUpCYkq/f3bmvW2/ItvtdPbFWvmq6p0ObSpiRO LgAAAACgRNKpCqhxtbuoV2m3Num1t8/QXR1f+tcLr+34U7+1D/9ZvWpKNAUAAAAAlGw6/fX+W3yP /vU99SKqaZEl342L4Q29AAAAAAB7pFMlO/P2pU1JCSEjJZfu7jLywtpdfEMvAAAAAMDe6VQ5Nm2Z pNPvp3/AqQQAAAAAkE4BAAAAAKRT0ikAAAAAgHQKAAAAACCdkk4BAAAAACWTTlMTkiV55lt2dRwq 6TQ+cKgtK1/dncwZBwAAAAAUIJ2qF0WLt/ASKwAAAACgYOn06u5kCZP5lvhA9drpMFtW5rVTAAAA AEDB0qmN+NwpAAAAAIB0CgAAAAAgnZJOAQAAAACkUwAAAAAA6ZR0CgAAAAAgnQIAAAAASKekUwAA AAAA6RQAAAAAQDolnQIAAAAASKcAAAAAANIp6RQAAAAAQDoFAAAAAJBOSacAAAAAANIpAAAAAIB0 SjoFAAAAAJBOAQAAAACkU3OHhr8l6fTwa/M4lQAAAAAAx6TTnNtZax/pIOlU/pXbnE0AAAAAgL3T aV5u7t6I8RJNPyvfWv6V27KEEwoAAAAAsGs6/XbMAgml62sEXdqyV/6V27KEEwoAAAAAsF86Pb3o c4mjn1dsd3V3styVf+W2LJHlnFMAAAAAgD3S6aWNiWvuv5v3/Oqt2sLzq76SJWtcW8tfOa0AAAAA gJJNpxmHT66r0lGC6PGZH5r96fsZy2W5/FXW4cwCAAAAAEoqnd46n7LBM0wi6IGBM3RXODBghvxV 1vnPTymcXAAAAABA8afTe9cztz7ZV8JnQvCI3HvZuuvI8oSg12QdWVPW5/wCAAAAAIozndoeO/8v xAa9Zi3EAgAAAABQmHSq3rL7Zd1utrxlV9b53zcAD5jBKQYAAAAAFE86LcTXHWlfniSP5SwDAAAA AIqaTv/vp2I2JRVo07/98Izr/R+eWfUVJxoAAAAAUPh0mpqQ/HnFdpIwTy9eW4itn170uTxWtnB1 dzLnGgAAAABQmHR64+S59TWCJF5+O2ZBoXcgj5UtyHZka5xuAAAAAEDB0umd1IxN9Z6TYLm314S8 3NxC70AeuzdivGxHtibb5IwDAAAAAAqQTvdFTpZIubPVwJzbWUXch2xhR8uBsjXZJmccAAAAAFCA dHonNUPCZHG92lm8WwMAAAAAPCjpFAAAAAAAu/kfHow+qqG4nCkAAAAASUVORK5CYII= --00c09fa21bcdfaf6a3048cdd0a05 Content-Type: image/png; name="javascript.png" Content-Disposition: attachment; filename="javascript.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gcdrsufk1 iVBORw0KGgoAAAANSUhEUgAABO8AAAOPCAIAAAAc13KrAAAANXRFWHRjb3B5bGVmdABHZW5lcmF0 ZWQgYnkgaHR0cDovL3BsYW50dW1sLnNvdXJjZWZvcmdlLm5ldDpnVRsAAAJMelRYdHBsYW50dW1s AAB4nH1TXW/aQBB8969Y5QkeoIYmoKK2KkFEURQSZEOookrRcV7gVNtn3a2h9Nd374xbEzV5su92 5nZmP75ZEobKLA2EJG1gadEEBV8pqQqRE1y4Gxhvkf9b10Yf+Ni+AGFhOT4HRmh1aSTCROe2zJjV uhN7YaVRBVWUaHJOWeEaYjR7ND68is/D45J22qjfgpTOm0AXeH4jewMWxYFX3/nKYkcwzQkN647u nVm1F4SV3+XYQVbxCB4LzF8jxi7+uePjc7FFOCjagbMWe2vOVfWCT/ILZcm0aNINokl9G2GiDEoC 0pX4H7lBW3Ch8IWOBX4h/RPz0zMeUGkBUxOdpkrHKTznB1xT3PHhGZQztxESK8uMc3nfB53E1SDJ yfirRGpB5AmIU/kRWjwZHDq2zxXWRFuuM0WECWy0ySARJGBjdFZV14MbrCc0anP0GSyPHFbi4EMV f8Xunptu1nEVV50YS4nWwsJVkB3CjRHbjGU12nqj01Qf/hWztTlhINfEHJmWCavnkSm4LLeLxbz9 ZtNt3fTuu12PJu6WDM/RuUJv7a/GVOuiZjihSHIHhdHEMlmRqafapxfVO35WfB4W6FgRUmny/9C6 AeZJkGBzmJsn155gnvICLWf3wGtj3aJdhYNhKxYEd2UKvSH0LkdX4ajfg8k0XkA/7IXtwFWitZi1 IZ5CVPLQZMj7tVdG596Xi8OtprjQ5HGDy861otN2wtMs6HUH3fClH3bWYb/TH37q9MLZx3BwFcyE hMcYvv8BfVOBEJ0+21UAAIAASURBVHja7N0JXFVl/sdxttEU1EARF8AARRrF0nJtNBWEELXEIinN cszR0hT/5taMpo5LU+6mDZk5YZm5QIqaSyhu40aZC+WaSYIIgYKDIEv/3/hMZ+7czQuyXPDzfp2X r3PPPffcc5/7e55zvt57Dza/AgAAAABQ1diU+pEFObkp2w5+/+7qk9Oi5N/L676WJTQoAAAAAMBK 02xeetbJacvWO3X73KaD7rTe6cnj4xfJvTQrAAAAAMC60mza7mOb3ENUfN3q1y9x1IST02YcH//W V48OWOvQSRbGNAhK2XaQlgUAAAAAWEualSi73qmrRFbJrpnffFlc/I3udD1p685Oz8u9ax06X9m8 j8YFAAAAAFR+ms1Lz4ptFCRh9Zuxk4puH9OLstok96pPaG+lZtC+AAAAAIBKTrMn/rxUfSpbkHvE VJRV047Hn5M1j49fRPsCAAAAACozzRbk5KrLPhl+wdhwup60da1D5/VOT97OyqaJAQAAAACVlmav bN4nUXZb6/53jbK/fTwbLutfXvc1TQwAAAAAqLQ0+/27qyWdJo6aYGGaPT7+LVlfHkUTAwAAAAAq Lc2enBYl6fTktBkWpllZ8876UTQxAAAAAKDS0mzJP5v9C5/NAgAAAAAqOc2W/HezEfxuFgAAAABQ yWn2zjWNn7T4msbbuKYxAAAAAKDy0+yv//57sx+ovzdbdPuY+TS7s9Mg/t4sAAAAAMAq0mxeelZs oxCJqd+MnWQm0H4zdqqsE9Mg6FZqBu0LAAAAAKjkNCvSdieq7xt/9egAw68cX0/apj6VXevQ+crm fTQuAAAAAMAq0qwKtDENgiSy3rkoVNj+Z0d8/eSgfz7/+o7HI9Y98Af1qSxRFgAAAABgXWn21ztf OT7x5w/Uh7S6kyw5Pn4RXzAGAAAAAFhjmlUKcnKvbN63u9doybF7gkZfXvc1VzAGAAAAAFh7mlVO TouSNHvq7Q9pSgAAAAAAaRYAAAAAANIsAAAAAIA0S5oFAAAAAJBmAQAAAAAoizSbtjtRkupdp6+f HCFpNr77CEtWvrYnkRYHAAAAAJRjmlUfupbtxEe4AAAAAIDyTbPX9iRK+LzrFN9dfTY70pKV+WwW AAAAAFC+adZC/G4WAAAAAECaBQAAAACANAsAAAAAIM2SZgEAAAAApFkAAAAAAEizAAAAAADSLGkW AAAAAECaBQAAAACANAsAAAAAIM2SZgEAAAAApFkAAAAAAEizAAAAAACQZgEAAAAApFnSLAAAAACA NAsAAAAAAGkWAAAAAECa/a+jr/1N0uyx19+lKQEAAAAAVSPNFubmravVTdKs/CvztCYAAAAAwNrT bHFR0f7+EyTKfm7XSf6VeVlCgwIAAAAArDrNfhu5QELsRueAK1v2y78yL0toUAAAAACA9abZs0u+ kPj6RY0nru1JlJvyr8zLEllOm6LS/fsrA0xVauK9Zrqv6pYB+T4vD/oO3RwMcUxl1e9Kk2avbNq7 9s63iy+t3qYtvBS9VZaste8k91LZqPSRpbj4G6aqMt1jmqUBmapc3TIg3+flwcBFNwdDHFNZ9bsS p9nMY9+vd3xSnub0zI/07jo1Y4Usl3tlHYobjCxMpFkm6hakWdqEbg6GOCZrSbM3L6XGNgqR5zj8 ygyjKxx+eYbcK+v866dU6huMLEykWSbqlgGZ8qBN6OZgiGOq/DR7+3rOtlYD5Ql2B44qul1gdB1Z vjvgdVlH1pT1KXEwsjCRZpmoWwZkyoM2oZuDIY6pMtOs5TH1v6E34HVToRdgZGEizTJxmsuATJpl opuDIY6pItKs+grxl417W/IVYlnnP19IfnkGVQ5GFibSLBN1y4BMeTBw0c3BEMdUOWm2FJd30i4W JY+l0MHIwkSaZaJuGZApDwYuujkY4pgqOs3+90/vbN5Xok3/+w/52N/5Qz7RW6l1MLIwkWaZqFsG ZMqDgYtuDoY4popLs2m7E7+o8YRs9OzSdaV4g88u+UIeK1u4tieRcgcjCxNplom6ZUC+l+n27aOF hcdIs1W9fejmYIhjqog0e+P7Hzc6B8gWv41cUOr3WB4rW5DtyNaoeFTuyLJmzdxvv/1cu/nTT9s+ +2xOmXfClJSdf//7n1NTd1Zw5y8qSly0aILMxMTMlx346KO35cXKwkoflVatmpGZmVDBaVY1gkw7 dizPyztchQZxecs2bVr09tsjRo58bu7cMevXv5eVtbeKHpC0mjx+fG159LUSTZs3Lzp27DMrqVsG ZGne8+c3q/n8/CPSVS9ejNPyWFTUX+Rfo83evfvj06b96a6JbsuWJW+8ETFnzhvx8VFVLs3ey0HE kvYpw25SfhupEu8jYL47V9FTkUrvemWWZm+lZW72ekY2tz9sYnFRUanfY3ns/v4TZDuyNdkmRY9K HFm8vZvOnj1auxkXt7hZs8Zl3gmnTPmjjY3N1KnDy3zLly9v+/HHLabunTTplX/8Y6bMdOjQuk2b FiEhTzg7123SxPXGjX2VOywmJW186qkups5NyynNqkYID+/l6dnIyan2vn0rq8QhJD19d0BAB3d3 t8mThy5dOiky8sVWrXy+/vrvVTTNajX5zjtjyqOvlWgaODB4/vzxlnexcq1bBuRu3dpJkav5AwdW yZg5a9YodXPv3pW+vs3uJa2Fhnbt2LH1u+9GvvRSn2efDaxyabZEBxG948I9pllLusld96F0G6mK 7yNgvjtX0VORSu96ZZZmD4RPkW3t7PhKYW7ePb7NsoUdHV6Rrck2KXpU7zQr576NGzeQUzEPD7cy /7pX377dxo0bZPSudeve/cMfHtVGz4kTX5aZn3/e/sADNdSHY5U7vfnmEFN7Xn5pVjWCTO3a+cnZ VZU4hAwfHubl1TQt7Wu9TzirYpTVrUlrSLOl6GLlV7cMyJK4pJOq+blzx9jZ2cn5k7r51lt/HD16 YKnT7NmzX8rWrlzZUUW/aVzSg4he0d5jmi3zY1OppyrxPgJ3TbNV7lTEGrpeWX42K+GzrD5NLdut AWWeZvfv/7hXr07OznU9PRtdvbpLLZRQERbWUxb6+T2kfT42eHDoggXjR4x4VpZfv67/sefGjfMa NnQ5fDjaxsZm69al2vLU1J1PP93dxaVe27Z+b789on37VuafQiLojBmvyc506fLIoUOfyMK//vV1 R8dasqac5Xz55UK955XYsGrVDL3RMzMzwcmptlpZb7fT03fLEje3+o0a1R8ypO8vv+yRdfr37xEd /Ve1kddeC3/mmR5qPiHhI/Wfc6VuJRkcZU9u3jxYKWlWzrT69XvSzN4afV1Gm0imPn26fvLJf1rp 44+ny9tq9CXLw4cOfbpp04Z16jjKm27m2bVJnkIOIX//+59NfWxrdH+MVoupF2Vm52UjkiKaNHF9 7LGHz5yJldVatPD8/e+9N29eVLruoFuTumlWnqhr17YNGjwYGNhR7a001HvvjdMe+Prr4cuWTTG6 ppk3y7C19fZNbi5ePFG7a+HCN8eOfUHas3lzj5iY+Ua7WPnVLQOyjCr29naqZqQsZYSR4VH9x42c 88ngbKrkJK1NnTpc773T+5zQ1tZ2xYppesvvWsCDBoUarcNSHAjuJc2aOogY7byGRavSrOGAYGYA MdpNJFTLNnUnFZINe6XhPuj2tZIOXFXrfQQsT7NV5VTEGrpeef29WaB6p1k5mkq/knOpixfjtN82 yNF62LD+0s3ef3+yv39z7VzK1dV5zpw35Izf8D/Oe/f+gxq5JK8OGBCg+//lPXq0l5NjGaEkJUrv Nf8UjRs3GD164MmT62QIkJApC7Oz9wcFdR458jkZF27dOqT7pDdu7JPzHu0bLDJ6vvhibxmJZFiU c778/COGuy2bCgjocPr0Bpl69mwfEvKErCN7rhKstED9+vXkXFONm/Kkcs5xL60kJ0ayta++er+C 06y0lQz3NWr8bsOGeWb21ujrMtpEMrVu3Vw7UZs/f/yjj7Y0+pLliXx83KXGZIOnTq038+za9M9/ fiLv4/Hja42+IlP7Y7RaTL0oMzsvR8rp00fKyk888aiEhBdeCPn++41yNNI+QCtRd9CrSd00u379 e99++7nUsFTp888HyZKPPnrby6upSjLXrsXXqlVTfWvRcE0zRWjY2nr7pvuZlcy7u7vNm/d/3333 hRzppdoLCo4ZdrHyq1sGZHmnatd+QMKPvJWSY48cWS0FI7UtI6QUgPofBFMlZ/je6W188uShcjb2 8sv9pJy0hXct4BUrphqtw1IcCO4lzZo6iBjtvIZFa2pAMDOAmOomsk01LV/+loyi6udzhr3S6D5o GynpwFW13kfAkjRbtU5FrKHrkWaB0qTZbt3aBQd31v3lz/nzm+XsauPGeTKCHDv2mZzUpqTsVD1w +PAwo9u/dGmrrCaRVeb//vc//+53Dup/12SJbGrTpkXaNzBVmjXzFBERT6mVP/xwqoeHm/lvc8kI JdvRLhkio+cjj/h26uQvI8XHH09XI4vubl+48O/n1T7gjYmZLzdl53fv/rBOHUdJv9u2vS8jpmxE dlVGGck5SUkb77GVpPFNfepYTmm2Zs0aMhzL7m3fvsz83hq+LlNNZP4Qor1k9UR6vxwz9ezaJBUi K1y+vM3w5ZjZH1PVYviizO/8a6+Faz92bdvWTx1dZJfkgFSK7qBXk0a/abxs2RQ58qmzYUfHWlJ+ Mv/ee+OeeqqLqTXNFKHh7/T09k0vzcrL1P7nWx5+4MAqo12snOqWAVkm9d9tEkp//3tvudm0aUMp 4H/8Y6YsN19yRt87w4uvyMAl21T/pWJJARutw1IcCO4lzZo6iJjpvIbfNDYcEMwPIKa6iZqOHFld u/YDK1e+baZXmvq2cykGrqr1PgJ3TbNV7lTEGroeaRYwObL4+jZ7++0RuuFBTlXVvAwfcgrl4GA/ YcKQ3Nx//+/y11//XXpg585tnnjiUTXt3bvS/K+SZPmDD9YZPXqgTK+80k8e/re/jVXfqZN57UcI Wpq15Ck++eSv7u53SbMSNWU7yclf6X2zRYY8SafqJetuUz2vtj/yQLm5Z8+K27eP1qvnJPeOHPnc 8uVvvfnmkD/9aYDsfKtWPvfeSp6ejQy/uFKuaTYy8kU5EZTzrVGjntd94YZ7a+p1GTaR+UOIXgsn Jv7PVT1NPbs2nTjxhaygt9D8W2amWgxflIU7P2XKHwMCOmjXJlVptqTdQa8mddNsbOyCjh1bt2vn J9NDDzVRC196qc+QIX1lxs/vofXr3zOzpqk3S6+1DfdNL83q3tWwocvChW8a7WLlVLcMyDLNnj3a 37/50qWTRox4Vm4+91wvGTZfeCHk3XcjLS857b0znH75ZU9oaFcpYDnHsnBrhnVYigPBvaRZUweR EqVZwwHBwgHE8KYcROSM9q23/qgtMdorTe1DKQauqvU+AndNs1XuVMQaul4ZpNnPP//8+PHj2s3L ly+vWbOGYkU1GFl0v6Shvt8o/Up3BRkjXF2dlyyZJPPnzm2SHmj4JUNTPbCg4Jgcj994I+L99yer KTi4s/Rnuetf//qnDAfaf8stWzZFpVlLnsKSNHvz5kE7Ozs1wOn9TkNGT5VFdbepksbOnR+om9u2 vS831acBzz4bOH78Sx4ebjJ6ygqS9seMeUHv9ZailfLyDsse7tr194r/3ezu3R/KU6sff5raW8PX ZaaJ5BCyYMF47XI1Rg8h6onUL0a0yfyzy3Tr1qH69eu9+mqYqXBodH/MnxTqvigLd95omi1pd9Cr SS3NnjkTK4dq1RdWrnxbOxuWA56jY624uMVy6qwuI2xqTVNFqNfalqfZa9fi5eHr1r1r2MXKr24Z kGU6dOgTW1tbKbbVq2fJTanMFi08GzR48OTJdRaWnO57Z+qjTvXrUwsL2LAOS1r595JmzRxEzHRe S9KshQOI3s3r1/fJkz7/fJB2ITpTvdLUPpR64Koq7yPwq2W/m61CpyLW0PXKIM16e3vPmTNHu7ll y5ZmzZpRrKgGI8usWaOcnGofObJa/UG/Hj3aa38iIiHhI+l4cszu2LG1dhFgOc2SddS3PnJyDqg/ dWOqB8ogJedhun9PTF3GQ/0vlBzsZayJjv7r1KnDZQySNS18Ct3DfGTki7KyqR9VfvjhVN3RU17O 6dMbHn7YS10dVHebhYXHHnvs4Rdf7C1Pl5mZEB7eq337Vup8RRJ+vXpOnTr5q3BVu/YDcvPEiS/u sZVkT1xc6pn6Y2vlfRUoCeRybFBfbjG6t4avy0wTDRgQEBHxlDTOxx9Pl8YxegiRSZ7F37/50aOf yvwPP8SoL+4afXa9L+/Z29u999449VNAedSmTYvUw03tj6lqMfpmWbLzRtNsSbuDXk1KmlVfSty/ /2M5G75wYbO8HYMG9dZ+QC77KXG3YUMXrUuaWtPo6zLa2ubTbGBgR2lJaefZs0fXr19PvRy9LlZ+ dcuArMJb3bqO2rfr1U9ndVONqZIz+t7pvmty4qiuFyADmlSR+sO2lhSwYR2WovJLnWbNH0RMdV69 ojU6IFg4gOjelF4mWbpz5zbaNzvM9EpT+1CKgatqvY/ArxZfBaqqnIpYQ9cjzQImR5Z//eufMhbI yYG3d1Ppn3JKpF0drkULTzkwywl3nz5dZTXtT9j37v0HSRc+Pu5ubvWNfi9Lm/r1e3L8+Jf0Fj7y iK/60oVsavDgUEmJ0sNXrJjm6dnIwqfQPcxLqpT9lMdqH/Nq044dy9u29VP/Eyajp80dzZt7vPZa uPq2p95unzkTK2OijIAS72Wv1H/1yXTlyg5bW1vt18UhIU+0bPmQ9qhSt9KwYf1nzny9sv5Cj+yq r28zCVcyzhrdW6Ovy1QTxcdHNW3asGbNGv3795g1a5SpQ8jPP2+XJfIuSBzy8HBTF0cx+ux6k5SH nKBLhpSWl7dedkmOQGb2x1S1GH1Rluy8qTRbou6gV5NSh9plnOSpH3igRpMmrlFRf5FXqi3/y19e ldpTR00zaxp9XUZb23yaDQ3tqlpYTi+0//nW62LlV7cMyNpnetrne1IqtWs/IG2u3Wuq5AYODDZ8 73R/7iXbqVPHUd5KGQc+/XR2iQrYsA5LWvmlTrPmDyKmOq9e0ZoaECwZQHRvqovSSUs++GAdNand MNorzexDSQeuqvU+Apan2apyKmINXa980+yBAwd69erl7Owsg1ZaWppaeO3atbCwMFno5+cXHx+v Fg4ePHjhwoUjRoyQ5Tdu3KDWYSUji7pwyLFjnxn+Ka0bN/YZflamfteuXcymTKYXXggJDu5c6qeQ scnopRcXL544b97/lWhPpCkyMxNK9JBStNLBg/948cXe5XS6YP69NjUZ7q2p12W0iQoKjlnYbhkZ Rh5uydt9+fK206c3GP6l2RK9ZUZflOU7b2HTmZnmzh3zyitPf/HF3+Qg+tlnc3RfharhnJwDMpkv UcM1Tb1ZRlvbzN8sleaV3mTYyKqLlWvdMiCXuuSuX9+Xl3fY1Hunff3k3LlNRv9eYqnH85I+sNTX NDYzmem8po4L9z7mW9grze9D6Z7X+t9H4F6GOKs9Fan0rle+abZLly6SUYuLi3/88cf8/Hy1MDAw cNiwYRJZly1b5u/vrxZ2797d1dV17ty5Z8+eLSoqotZRhU6eymOS0/oJE4asXj3rj398xtGxluHn CWUySWywwr/E/eWXC/X+pFClp1mmipkuXozz9GzUr9+Ta9bMVV9bspLprh/IlHfdMiBX+6k80iyT tb2PAN3ZGvpdydJst27dgoODL126pN174cIFGxubmJiYpKSkxMREe3v71NRUlWaHDx9OiYORRU27 d384Y8Zrr7zSb/LkoYYXX2XY4ijCVJHTRx+9bfgn4znN5VSPNMtENwdDXHVIs76+vtOnT9dubt68 WfKtmpcc26tXLwcHhwkTJty6dUuWxMfH37nycucnfrNv3z6VZqdNm0aJg5GFiTTLRN0yIFMetAnd HAxxTBWUZnv27BkSEqLdXLlypWRU3RUSEhJcXV2XLl0q8+fPn7/zF4G3622ENAtGFibSLBN1C9Is bUI3B0McU4Wm2dmzZzs5OR09elTmU1NTe/ToMXnyZHXX3r17CwoKiouLO3bsuHjxYrUwICBA1lFf P75582Z2djZpFowsTKRZJuoWpFnahG4Ohjimik6zubm54eHhd/6KibeDg0NgYGBmZqa6q0WLFs7O zl5eXn369JHV1EJJvL1797a3t/fx8XFzc0tISCDNgpGFiTTLRN2CNEub0M3BEMdU0WlWycjISExM TElJ0VuefYfh+jk5OVevXqWmwcjCRJplom5BmqVN6OZgiGOqzDQLMLIwkWaZmDjNZUAmzdLNAbpz dU6zJ6dFUcqwtpGFqWpNvNdM91XdMiDf5+VB36GbgyGOqaz6nU2ZvIuUMlAxIyaNACoKoMJpbQD0 UNIswEgEKgqgwkFrA/RQ0iwARiJQUQAVTmsDoIeSZgHQ10BFAVQ4rQ2AHlqOaZarQAEVg74GKgqg wmltAPTQskyzAAAAAACQZgEAAAAAIM0CAAAAAEizAAAAAABUhzTL7/6BikFfAxUFUOG0NgB6aFmm Wa7JDlQM+hqoKIAKp7UB0ENJswAjEagoKgpUOGhtgB5KmgXASAQqCqDCaW0A9FDSLAD6GqgogAqn tQHQQ8s3zfK7f6Bi0NdARQFUOK0NgB5almkWAAAAAADSLAAAAAAApFkAAAAAAGm21GJjY6N0fPfd dxX8Uj///PPjx49rNy9fvrxmzRq9fdu5c2d+fr7uPh86dIgqAQAAAIBqmGYt/FVxhw4dWrduPfQ3 27ZtM7NycnLypUuXyvalent7z5kzR7u5ZcuWZs2aafvWpk2b8PBwT09PJyen/fv3a8vHjx9PlcBK cI0NUFEAFU5rA6CHlmWatfCKzyVKhn379h03blxFptmJEyeq+Xbt2g0cOJA0CyvE3z8AFQVQ4bQ2 AHqotaTZwYMHL168eObMmZ6enl26dDl8+LAsnDVrlqOjo7Ozs6+v76ZNm2TJtWvXwsLCZImfn198 fLz22IULF44YMUKW37hx48CBA7169ZJ52VRaWlqp06wE6X79+pFmwUgEKgqgwkFrA/RQ0ux/kmFo aOhnd2zdulUt7N69e+PGjUePHn3q1CnJq/3795eFOTk5QUFBI0eOlBCbl5cnSwIDA4cNGyaRddmy Zf7+/tpjXV1d586de/bs2aKiIgnDEm6Li4t//PFH3d++Wp5m5emio6Nr1KixceNG0iwYiUBFAVQ4 aG2AHkqa/U8ybNWq1ZA7pkyZoiXSiIgINb9ixQoPDw81r/tN4wsXLtjY2MTExCQlJSUmJtrb26em pqrHDh8+XNt+t27dgoODzfza1nyarVmzpq2trTzRjh07dPeZNAtGIlBRABUOWhugh1bPNGv5VaAM k6Ek0mnTpqn56Ohod3d3wzQbHx8vIbNz585P/Gbfvn16jxWSY3v16uXg4DBhwoRbt24Z7oCvr+/0 6dO1m5s3b5Z8q+1bZGRkWlqal5fXqFGjSLOwTlxjA1QUQIXT2gDooWWZZi1U6jR7/vx5SbPbt283 81hNQkKCq6vr0qVLDXegZ8+eISEh2s2VK1dKMNb2Tf1uds+ePXZ2dnFxcaRZAAAAACDNljjNRkZG 9ujRQ1stICBAbqpvEd+8eTM7O9swze7du7egoKC4uLhjx46LFy823IHZs2c7OTkdPXpU5lNTU2WD kydP1kuzYsyYMZKH1ZeZSbMAAAAAQJrtYGNjY/ubXr16mUmzJ0+ebNGihaenp/oVq2TL3r1729vb +/j4uLm5JSQkGKZZWd/Z2dnLy6tPnz65ubmGOyALw8PDZR+8vb0dHBwCAwMzMzMN06ys5uvrGxQU JMFYb5+1z3IBAAAAAPdLmi2FK1euFBUVaTdzcnKuXr1qZv3sO8xvMyMjIzExMSUlhfceAAAAAO7r NMvv/oGykpeeRV9DhaGiQIWD1gboofd7muWa7EBZkd604/EhKVsP0tdQMfVGI4AKB60N0ENJswDK ZqyRaa1dp/V1uyeOma/3US19DRzbACqc1gZADyXNAtabZrVprV1H3Y9q6Wvg2AZQ4bQ2AHooaRao AmlW76Na+ho4tgFUOK0NgB56T2nW6Ak3ExNTBUyX133NiIyywlVbQIWD1gboofdjmuU/54By+p8z 3Wlb64j9YRO3Pvx8XPOwpDmrzF/xGAAAALivkGYBq0uz652e3Bsydm9o5IYHAw48O+nqzsPFBYU0 DgAAAECaBaw3zfJhLAAAAECaBapemuXDWAAAAIA0C1Qx5j+M5RobKFtUFKhw0NoAPZQ0S5oFKgKd C1QUQIXT2gDooaRZgJEIVBQVBSoctDZADyXNMpwBjESgogAqnNYGQA8lzQKgc4GKAqhwWhsAPZQ0 C1QHXGMDVBRAhdPaAOihpFkAAAAAAGmWNAsAAAAAIM0CAAAAAECaBQAAAACQZkmzQGXgGhugogAq nNYGQA8lzQJVD50LVBRAhdPaAOihpFmAkQhUFBUFKhy0NkAPJc0ynAGMRKCiACqc1gZADyXNAqBz gYoCqHBaGwA9lDQLVAeW/4K/uLh448aNkydPHj9+/GeffXb79u2KHjQ///z48ePazcuXL69Zs0bN x8bGRt2xc+fO/Px8bR1ZfujQId5l66wogAoHrQ3QQ0mzAMpdZmZmYGCgr6/vjBkz5syZ07Zt28cf fzw5Obki98Hb21ueWru5ZcuWZs2aqfkOHTq0adMmPDzc09PTyclp//792nLJ3rx9AAAAIM0C96nX X3/9oYceun79urp569YtSbPPPPOM9aTZiRMnqvl27doNHDiQNAsAAADSLHC/y8rKcnBwGD16tO7C uXPn2tjY/PDDDzI/ePDgRYsWjR071s3NrXnz5rGxsWqda9euhYWFOTs7+/n5xcfHq4Wy8uLFi2fO nOnp6dmlS5fDhw+r5QcOHOjVq5esLMvT0tJKnWb79u3br18/0iwAAABIs8D97tChQxJcN2/erLvw 22+/lYUbNmyQ+e7du7u7u8+fP//EiRNDhw6tX79+YWGhLA8MDBw2bNiNGzeWLVvm7++vHigrN27c WLLxqVOnJOv2799fLZdku3DhwuLi4h9//FH3t6+Wp1kJz9HR0TVq1Ni4cSNpFgAAAKRZoDqz5Bf8 kmO1j2E1BQUFtra2H3zwgQqokyZNUsszMjJk5YMHD164cEFmYmJikpKSEhMT7e3tU1NT1coRERFq 5RUrVnh4eKj5bt26BQcHX7p0ydRumE+zNWvWlP2RZ9yxY4e2DmnWOisKoMJBawP0UNIsgHtlSec6 ffq0pMSoqP8Zs5KTk7XoKAF12rRp2l0NGzZctGhRfHy8rNC5c+cnfrNv3z69laOjo93d3dW85Nhe vXo5ODhMmDDh1q1bhrvh6+s7ffp03Ywt+VZLrZGRkWlpaV5eXqNGjSLNWnlFAVQ4aG2AHkqaBVAR I9Ht27ebNGny3HPP6S5cunSpk5NTRkaGXkBNT0+XELt+/frz58/LzPbt2/W2ZirNKgkJCa6urrJx w93o2bNnSEiIdnPlypWSkLXUqn43u2fPHjs7u7i4ONIsxzaACqe1AdBDSbMAI9Gvn3zySe3atb/6 6it189ChQ5I5Z8+erQXUwMDArKyswsLCOXPm1K9fPzs7W5YHBAT06NFDfXn45s2baqGpNLt3796C goLi4uKOHTsuXrzYcB/k6SQ/Hz16VOZTU1Nly5MnT9ZLs2LMmDGyb+pbzaRZjm0AFU5rA6CHkmaB +30kkuTp4uLi5eXVvHnzunXrLlq0SJKnlmZDQ0Nbtmwp0VSS5K5du9RyiZS9e/e2t7f38fFxc3NL SEgwk2ZbtGjh7Ows2+/Tp09ubq7hDsjC8PBwGxsbb29vBwcHyc+ZmZmGaVZW8/X1DQoKkt2T5bK+ 7W+0z3LBsQ2gwmltAPRQ0ixQtZXoF/ySD8+fP3/u3LmioiLd5Sqgyr1XrlzRIq4mJyfn6tWrlmw/ +w7z62RkZCQmJqakpPDeVYOKAqxQXnoWFc54AuB+7qGkWeD+oncVKACouuSUY8fjQ1K2HqQpAOD+ RJoF7i8rV66Mj4+nHQBUjzQr01q7Tuvrdk8cM9/8R7UAANIsaRYAAFhRmtWmtXYd+agWAEizpFkA AFDF0iwf1QIAaZY0C1j1iRoTExMTk4XT5XVfcyipGFwFCqCHkmYB0NdgLQUGVLn/8tvWOmJ/2MSt Dz8f1zwsac4qKpzxBEC176GkWYA0CwoMqMJpdr3Tk3tDxu4NjdzwYMCBZydd3Xm4uKCQCmc8AUCa 5QwbIM2CYxtgvTWs+2Gs3g9lqXDGEwCkWc6wAdIsOLYBVlrDuh/GUuGMJwBIs5xhA6RZ3Be4aguq OvNXLabCGU8AVPseSpoFSLMAAAAAaZYzbIA0CwAAAJBmAdIsfQ0AAAAgzQKkWQAAAIA0yxk2QJpF lcVVW0CFg9YG6KGkWc6wAdIsqluBAVQ4aG2AHkqaBUCaBcc2gAqntQHQQ0mzAEMPfQ0c2wAqnNYG QJrlDBsgzYICA6hw0NoAPZQ0y3AGkGZRNXDVFlDhoLUBeihpljNsgDQLAAAAkGYB0NcAAAAA0ixA mgUAAABIs5xhA6TZUiooKCgqKuKdBQAAAGkWIM3qi42NjYqK+vDDDzds2HDx4sWK3+24uLjExESj d3Xv3n3atGnmH/7dd9+tWbOmrMLz1q1b33jjjblz5+7evbtMXoIl1Fsgdu7cmZ+fr3tXcXHx5s2b p0+fPnLkyHfeeUfeo+vXr1dWgXHVFlRvVDitDaDa91DSLFDd0myHDh3atGkTHh7u7e1tZ2cXExNT wbs9cODABQsWqPnk5ORLly6VKM3+7W9/a9asWZnsSWhoaMeOHd97772XXnrp2WefLd1LMEXvpRl9 Czw9PZ2cnPbv36+WZ2RkBAQEuLu7T548+f3334+MjGzVqlV8fLx1FhhQvYdQ0NoAPZQ0y3AGWGOa nThxoprv2bNncHBwJb6Evn37jhs3rlLS7Llz5yTMp6SkVMxLM/UWtGvXTrKxmh8+fLiXl9e1a9d0 Vy4uLubYBlDhtDYAeihpFiDN/k+Ueu211zw9PWVm8eLFXbt2bdCgQWBg4OHDh9W9V69effrpp11c XNq2bTt9+vT27dur5RK3wsLCnJ2d/fz8DD857N+//+rVq7XtP/PMM2p+79696vPPwYMHL1myRGZm zZrl6Ogo2/H19d20aZOWZmfOnCl71aVLF21PTKVZw90eOnTovHnztJVff/315cuXG10zOTnZ1tb2 o48+0tt+RkaGbKRp06Z16tSRF64Wyj4vXLhwxIgRsrc3btzQXoK6a9GiRWPHjnVzc2vevHlsbKzR l2bqLZDQ269fP5nJzMyUdB0VFVVVCgzg7A20NkAPJc0CqJw0e+7cubp167766qsyv2HDhuPHj+fl 5b344ovPP/+8WlOyZY8ePWS1tLQ0CaWSzdRyCYTDhg2TULds2TJ/f3+97cvGVYLNz8+vX7++vb29 5DS5OXLkSImpv+p8AJuTkxMUFCTLJR7LU6u7GjduPHr06FOnTklglmBsPs0a7vbKlSu9vLzU55np 6em1atVSX/c1+gInT54sgfbll1+WNbXty6vz8fHZsmWL7P/p06e1pnB1dZ07d+7Zs2eLiop0P0OW eXd39/nz5584cUJisLzkwsJCw5dm+BbIXdHR0TVq1Ni4caMsPHTokI2NzXfffcexDaDCaW0A9FDS LECaNZ5mvb29H374YQlyAwYMyM7O1r13+fLlkgZV1pVwtXnzZrV8/fr1Ks1euHBBlsfExCQlJSUm JkpYTU1N1d3Cnj176tSpc/v27a+++iokJOSRRx6Rx0oCbNSo0ffff//r/36d2PCbxhEREWp+xYoV Hh4e5tOs4W5LjHR0dJR9kPl58+Y99dRTptZUYmNjZceaNm2qfryqXp3hb2Jlx4YPH657UzfNTpo0 Sc1nZGTIww8ePPjr3b5pXLNmTWl/WXnHjh1qoTS13ExOTraeAuOqLajeqHBaG0C176GkWaAaptln n3127969uj8Z/fLLLzt27NjujoceeujXO18MlnClraOl2fj4eFneuXPnJ36zb98+3e0XFBTUq1dP Vhs5cuQHH3zw5ptv/ulPf5KttWrVyjAKmvndbHR0tLu7u/k0a7jb4qWXXhoyZIjM+Pn5bdiwwcya SmZmZmhoaK1atSQJq1f3zTffGKZZ3R/06qVZ3bsaNmy4aNGiu6bZyMjItLQ0ydWjRo36z4Hk5El5 ar3GBAAAAGkWIM3+N0ppP9pUzp496+DgoD4k/Pjjj1XYy83NlYCnfXK4fPlylWbPnz8voWv79u1m nlrS8vjx4z08PCQM79q1y9vbe8yYMUbj372kWaO7rfK2o6Pjli1bGjVqJNHazJqan376SV7Utm3b 1KtTP7UtRZpNT0+Xh0vy/9Wyq0Dt2bPHzs4uLi5O5vPy8urXr6+++A0AAADSLECavXuaPXDggIS9 ixcvpqamDho0SPt9rOSxRx99dPXq1VOnTm3dunWDBg3U8oCAgB49eqjfo968eVPvu8q/3vnxar16 9Tp16qRCWu3ateXmyZMnDeNfZGSkbKqkaVZ9VdjUbhcXF0vcbdiw4eTJk828wKSkJAmTt2/fVjss K1y4cEHmZX/8/f2PHTsm82fOnCkqKrprmg0MDMzKyiosLJwzZ44kUtUgei/N1FsgOd/V1VV9W1tS tL29/bx582RTclOeevPmzbIPlDoAAABpFiDNGkmzv965EPEDDzzQpEmTDz/8UPKYuk6SRKzBgwdL KJVY+NFHH6mrH6vlvXv3ltzl4+Pj5uaWkJCgt7WUlBRbW1uJdupmSEhIy5YtjUZBibgtWrSQLasP Ti1Js6+99pp2GSejuy3+8pe/yA6odGpqzdjYWInZderUkR2QNvnss8/UmleuXJHdsLGxcXFx8fDw 0C5PZSbNhoaGyguUvZVcumvXLqMvzdRbkJub6+vrGxQUpK5cJe0su1erVi21wT59+pBmAQAASLMA afa/8tKz9JZkZGSozyFv3qF37wsvvKD3l2lzcnKuXr1aJi9EAqR6ajN++eUXyZ/r1q2ThLlmzRoL d9v8C5Sb58+fN/onZ+XpsrKyLNl5lWwli8qrMPzbsJa8NEPJyclJSUmV+Jdm/xPIuWoLqjUqnNYG UO17KGkWqFZptiAn98SUZTGuwZb0xHfeeWfChAmffvrpH//4R0dHR+1Tx0rx448/+vv79+vX7/PP P1dfD7YSeh/b3j8FBlDhoLUBeihpFkBFpNm03ce+7jp8rX1nWa6mu25/z549M2fOfOWVVyZPnmx4 mV8oK1eujI+P59gGUOGgtQF6KGkWQFn2Nd0PY/UmGhCcfYIKB60NgDRLmgWsMc3qfRhLmgXHNoAK p7UBkGZJs4BVDz0p2w6aCrFMTExMTPynXgXjKlAAPZQ0C6Bkfe3MgjVbfJ+LaRj8pXtfTuMAAABw XyHNAlU4zaqZtN2Jh1+esa5217jmYetqdSXNAgAAgDRLmgWqQJpV8tKz9D6qpQEBAABAmiXNAtae ZjXqo1p6IgAAAEizpFmgKqVZJS89iwaEeVy1BVQ4aG2AHkqaJc0CVpdmgXssMIAKB60N0ENJswBI s+DYBlDhtDYAeihpFmDooa+BYxtAhdPaAEiznGEDpFlQYAAVDloboIeSZhnOANIsqgau2gIqHLQ2 QA8lzXKGDZBmAQAAANIsAPoaAAAAQJoFSLMAAAAAaZYzbIA0CwAAAJBmAdDXUBm4aguocNDaAD2U NMsZNkCaRXUrMIAKB60N0ENJswBIs+DYBlDhtDYAeihpFmDooa+BYxtAhdPaAEiznGEDpFlQYAAV DloboIeSZhnOgEpOs7GxsVE6vvvuO6t6Udru7dy5Mz8/X/eu4uLizZs3T58+feTIke+8886GDRuu X79OGZQfrtoCKhy0NkAPJc2SZgErSrMdOnRo3br10N9s27atXHcyOTn50qVLlq8vu9emTZvw8HBP T08nJ6f9+/er5RkZGQEBAe7u7pMnT37//fcjIyNbtWoVHx9PGQAAAIA0C9wvaXb8+PEVtpN9+/Yd N25cidLsxIkT1Xy7du0GDhyo5ocPH+7l5XXt2jXdlYuLiykDAAAAkGaB+zTNpqWlPf744x9//LG6 uXXr1qCgoNu3b8u8pMewsDBnZ2c/Pz/tg9CMjIyhQ4c2bdq0Tp06bdu2VQv79OkTHR2t5letWvX0 00/LzKxZsxwdHeXhvr6+mzZtMrVBU2lWknC/fv1kJjMz087OLiqKL6oBAACANAvcx2k2NDT0szsk uKqF69atq1Wr1vHjxyWpNmnSZPfu3Wp5YGDgsGHDbty4sWzZMn9/f22hj4/Pli1b8vPzT58+rRa2 bt16yZIlan7BggWPPvqozOTk5EgwHjlypITYvLw8Uxs0TLOyvmTjGjVqbNy4URYeOnTIxsbG2n7i CwAAANIsgApNs61atRpyx5QpU7TlY8eObd68eb9+/WRGLblw4YJkyJiYmKSkpMTERHt7+9TUVLVQ 8qreZo2m2V//95vGRjdouHs1a9a0tbWVNXfs2KEWbt68WW4mJyfzplckrtoCKhy0NkAPJc2SZgHr SrNGfzebnZ1du3btBx98MDc3Vy2Jj4+XDNm5c+cnfrNv3z618JtvvilFmjW6QcPdi4yMTEtL8/Ly GjVq1H8G2ZMn5YGGK6MSCwygwkFrA/RQ0iwAq0izI0aMCA0Nbdiw4d/+9je15Pz585Iht2/frrua Wrh8+XLDNLtw4UI1/9ZbbxlNs0Y3aLh76neze/bssbOzi4uLk/m8vLz69eu/+uqrvOkc2wAqnNYG QA8lzQKk2f9at26dt7f3jRs3du3aVaNGjYSEBLU8ICCgR48e6k/s3Lx5Mzs7W2Zkib+//7Fjx2T+ zJkzRUVFMjNgwICIiAiJnatWrapXr56WZiMjI2V97YmMbtBomhVjxoxxdXVV30aW/Gxvbz9v3rzC wkK5KU+6efNmeXZ115w5c6gHjm0AFU5rA6CHkmaBap5mbWxsbH/Tq1evixcvSmg8cuSIWmHmzJmN GjVSGVL+7d27t8RIHx8fNzc3lXKvXLnSvXt32YiLi4uHh4e6vNPu3bubNm1as2bN/v37z549W0uz J0+ebNGihaenp/oRrNENmkqzubm5vr6+QUFB6i/xfPTRR/Xr169Vq1bLli3d3d379Omj0qy8hIcf fph64NgGUOG0NgB6KGkWqM5pthRycnKuXr2qt/CXX37JysrSXVJYWKi3RCMBWH2Ea2aDFkpOTk5K SuIvzVYArtoCKhy0NkAPJc2SZoGqnWYBAAAA0ixn2ABpFgAAACDNAqRZ+hoAAABAmgVIswAAAABp ljNsgDSLqoqrtoAKB60N0ENJs5xhA5WTZq1k4p2qlgUGUOGgtQF6KGkWQHmlWcZH8N4BVDitDYA0 S5oFSLOMjxQYQIWD1gbooaRZAKRZcGwDqHBaGwA9lDQLMPSQZlG2uGoLqHDQ2gA9lDTLqS1AmgUA AABIswBIswAAAABpFiDNkmYBAABAmiXNAlUgzealZ5FmAQAAQJolzQJVI80W5OSemLIsxjW4wnoi Xb7q4qotoMJBawP0UNIsp7ZA5afZtN3Hvu46fK19Z1muJtIseO9AhYPWBsBf6CHNAlaaZnU/jNWb GB/BewcqHLQ2ANIsaRawxjSr92EsaRa8dwAVTmsDIM2SZgGrHnpSth00FWIrfuKd4tgGUOG0No0A 0ENJswBK0NfOLFizxfe5mIbBX7r3JWSipLhqC6hw0NoAPZQ0S5oFKifNqpm03YmHX56xrnbXuOZh 62p1Jc0CAADgfkCaBap8mlXy0rP0PqqlAQEAAECaJc0C1p5mNeqjWnoiAAAASLOkWaAqpVklLz2L BgQAAABpljQLVLE0C9wVV20BFQ5aG6CHkmY5wwZIs6huBQZQ4aC1AXooaRYAaRYc2wAqnNYGQA8l zQIMPfQ1cGwDqHBaGwBpljNsgDQLCgygwkFrA/RQ0izDGUCaRdXAVVtAhYPWBuihpFnOsAHSLAAA AECaBUBfAwAAAEizAGkWAAAAIM1yhg2QZgEAAADSLAD6GioDV20BFQ5aG6CHkmY5wwZIs6huBQZQ 4aC1AXooaRYAaRYc2wAqnNYGQA8lzQIMPeXT14qLi2/fvl2N27OgoKCoqIi6YrgGFQ5aG6CHkmYZ zgBrTLOxsbFRd+zcuTM/P9/yp1u/fr2zs7Oaj4uLS0xMtMI2SU1NlZd29erVUjy2e/fu06ZN01t4 69atKAMpKSkUGECFg9YG6KGkWQAVmmY7dOjQpk2b8PBwT09PJyen/fv3lyLNDhw4cMGCBfe4/8nJ yZcuXSrpXeZNmTLFxsZm6tSppdgBo2k2Ozt7qI527drJ9q0zyZc5rtoCKhy0NkAPJc2SZgHrSrMT J05U85LNJJeWIs2Wib59+44bN66kd5lRUFDQuHFjX19fDw8PS74zrPcsRtOsrszMzKZNmw4aNIja AwAAIM0CqMw0K3GuX79+av7atWthYWGSV/38/OLj49XC9PT0p59+2sXFpW3btuPHj9fS7ODBg5cs WaLNL1y4cMSIEXLvjRs3jG4nIyNj6NChEgXr1Kkjm5Ils2bNcnR0lNUkfG7atEl3Dw3vkofLs7i5 uTVq1GjIkCGSKo2+tJiYmIYNGx45csTGxmbbtm3a8j59+kRHR6v5VatWySsy+iwqzc6cOdPT07NL ly6HDx/W235ERITk5KysLGoPAACANAugctKsZE4JeDVq1Ni4caNaHhgYOGzYMImjy5Yt8/f3Vwuf euqp4ODgS5cu/fzzz5IJtTSr+zGmzLu6us6dO/fs2bNFRUVGtyMLfXx8tmzZkp+ff/r0aVmSk5MT FBQ0cuRI2ZO8vDzdPTS8S24GBAQk3dGzZ8+QkBCjL613794qqLdv337AgAHa8tatW2vZe8GCBY8+ +qjRZ5EX0rhx49GjR586dUoCef/+/XU3vnbtWltb2507d1J4AAAApFkAlZNma9asKcHMxsZmx44d auGFCxfkZkxMjMTFxMREe3v71NTUy5cvy0KJoGod3W8a66XZ4cOHm9mOWmj4O1sLv2l88eJFebj2 +W1sbKzc/Omnn/QeIkvk6c6dOyfzUVFRv/vd79LS0syk2V+NfdM4IiJCza9YscLDw0O7KyUlxcXF RYIuVQcAAECaBVBpaTYyMlKSnpeX16hRo9TC+Ph4iYidO3d+4jf79u3bs2ePLNSu32smzWrzRrej Fn7zzTelS7Pq4dpu/Pzzz3IzISFB7yGyDw8++ODoO1555RVZ59133y1pmtVeSHR0tLu7u3ZXSEhI y5Ytc3Nz76sC46otoMJBawP0UNIsaRawrjSrvo4rYdXOzi4uLk7mz58/L/Fv+/btumumpqba2toe PHjQ8jRrdDtq4fLly0uXZr///nt5+K5du9TNr776Sm6qz2A1hYWFEj7feOONZb8JDg728/PT0uzC hQvV/FtvvVXSNPvBBx84ODgcOXKEAgOocNDaAD2UNAug8tOsGDNmjKurq6RWmQ8ICOjRo4f6izU3 b97Mzs6Wmccee2zw4MGZmZlHjx595JFH7ppmTW1Hlvj7+x87dkzmz5w5oy44HBkZKcuN7qTuXbKy 7MaLL74om8rKygoPD2/fvn1xcbHu+pLJGzRooPvnc9W1oPbt2yfzAwYMiIiIyMvLW7VqVb169bQ0 q7cDRtOsRHFHR0dZ87oOCc8UGECFg9YG6KGkWQCVlmZzc3N9fX2DgoIkHEqm7d27t729vY+Pj5ub m/oq75YtW+rWrSsLJYsuWbLEkjRrdDtXrlyR1SReuri4eHh4qKsunTx5skWLFp6entrPdzV6d509 e1YSrARRJyenTp066X0wK/r16zd+/Hi9hRK/hwwZIjO7d+9u2rRpzZo1+/fvP3v2bC3N6j2L0TQb FRVlY2DPnj0UGECFg9YG6KGkWQAVmmbNy8nJuXr1qu6SgoICvSWl24745ZdfDP+8jQRdU38bVu+u jIyMUv91nMLCQlOPNbMDFBiNACoctDZADyXNMpwBVSPNAhqu2gIqHLQ2QA8lzXKGDZBmAQAAANIs APoaAAAAQJoFSLO4RwUFBfz4FgAAgDQLgL5Wxehd2BkAAACkWQD0tf+RnJys/pitVT1dtUyzXLUF 1RsVTmsDqPY9lDQLkGatS9++fceNG2dtT1ct0yzDNe7nIRS0NkAPJc0ynAFWl2YHDx68cOHCESNG ODs737hx49q1a2FhYTLv5+cXHx+v1jlw4ECvXr1koaenZ1pamvbARYsWjR071s3NrXnz5rGxsWp5 RkaG3CULGzVqNGTIkMzMTG39xYsXz5w5UzbSpUuXw4cPm9m40d0wNGvWLEdHR1nN19d306ZNL7/8 8pQpU7R733zzzXfeecfMrlr4LKaezsyL1dLs9evXZX7t2rVmntFUy3BsA6hwWhsAPZQ0CzD0mLxX sparq+vcuXPPnj1bVFQUGBg4bNgwibXLli3z9/dX60jEksRbXFz8448/5ufnaw90d3efP3/+iRMn hg4dWr9+/cLCQlkeFBQUEBCQdEfPnj1DQkK09Rs3bjx69OhTp05Jouvfv7+ZjRvdDUM5OTnydCNH jpSUmJeXt2rVqgcffPDWrVsqRkryPHnypJldNfoshw4d+ocBFUf1ns78i5U0Ky9HFsr62g4bfUZT LcOxDaDCaW0A9FDSLMDQYy7NDh8+XM1fuHDBxsYmJiZGslliYqK9vX1qaqos79atW3BwsN7vReWB kyZNUvMZGRnywIMHD168eFFm1OeWIjY2Vm7+9NNPav2IiAi1fMWKFR4eHmrecOOmdsMo3a/+/utf /6pbt+6nn34q80uWLJGcbGZXTT3LF198McaA9pGv7tOZf7FTp04dNGhQaGioSs5mXpepluHYBlDh tDYAeihpFmDoMZdmtV94xsfHS9zq3LnzE7/Zt2+fLJeo2atXLwcHhwkTJqhPPn81+Glow4YNFy1a pLaQkpKiFv78889yMyEhQW/96Ohod3d3NW+4cVO7cdc0K/70pz8FBATIzO9///t//OMfd91Vw2e5 fft2rgHtVes+nfkX26lTJ7l54MAB7XlNPaOplrE2XLUF1RsVTmsDqPY9lDQLVOc0e/78eYlb27dv N7qm5DRXV9elS5caPjA9PV0euH79+u+//15mdu3apZZ/9dVXcvPcuXN3zWy6Gze/G+bT7NGjR21t bSXHOjs7Gw3e2q6aepZJkyY1MdCqVSvDp7vrix0zZkyjRo3kicw3b1VJswAAAKRZ0ixgpWlWBAQE 9OjRQ33v9+bNm9nZ2TKzd+/egoKC4uLijh07Ll68WHtgYGBgVlZWYWHhnDlz6tevLysXFRU99thj L774oszLXeHh4e3bt5cHmslsRjdudDeMioyMlDV1l7Rp06ZWrVqSJHVfo+GuluhZjD7dXV+szA8e PNjb21v7prTRZyTNAgAAkGYB0uy9plnJXb1797a3t/fx8XFzc1Pfm23RooWzs7OXl1efPn1yc3O1 B4aGhrZs2VLSl6urq/YR5dmzZyXU1atXz8nJqVOnTuqzSjOZzejGje6GUSdPnpQteHp67tixQy2R SGxjY5OUlKT7Go3uquXPYurp7vpiJajL65KALXHX1DOSZgEAAEizAGm2lPfmpWfp3szJybl69aru kuw7DGNwcXHxlStX1AeSujIyMlR+s4Thxk3thimyD0VFRWr+3Xff7dq1q+W7avmzGH26kr7Y0j0j AAAASLMAafa/CnJyT0xZFuMaXIqeqPehbnnrbmDVqlVGXlFBgYeHx+rVqytxV6srrtoCKhy0NkAP Jc2SZoHKT7Npu4993XX4WvvOslxNJX26lStXxsfHV9ir+9aA0T/b89NPP02dOlX9MdjK2tX7s8AA Khy0NkAPJc0CKMc0q/thrN5EA4KzT1DhoLUBkGZJs4A1plm9D2NJs+DYBlDhtDYA0ixpFrDqoSdl 20FTIZaJyfKJXgbO3kBrA/RQ0izDGVDRQ4/ce2bBmi2+z8U0DP7SvS9BBSXFVVtAhYPWBuihpFnS LFA5aVbNpO1OPPzyjHW1u8Y1D1tXqytpFgAAAPcD0ixQ5dOskpeepfdRLQ0IAAAA0ixpFrD2NKtR H9XSEwEAAECaJc0CVSnNKnnpWTQgAAAASLOkWaCKpVngrrhqC6hw0NoAPZQ0yxk2QJpFdSswgAoH rQ3QQ0mzAEiz4NgGUOG0NgB6KGkWYOihr4FjG0CF09oASLOcYQOkWVBgABUOWhugh5JmGc4A0iyq Bq7aAioctDZADyXNcoYNkGYBAAAA0iwA+hoAAABAmgVIswAAAABpljNsgDQLAAAAkGYB0NdQGbhq C6hw0NoAPZQ0yxk2QJpFdSswgAoHrQ3QQ0mzAEiz4NgGUOG0NgB6KGkWYOipyn2tuLj49u3bvLkc 2wAqnNYGQA8lzQKkWSOJcePGjZMnTx4/fvxnn31mVelx/fr1zs7Oaj4uLi4xMbEcG/Dzz48fP67d vHz58po1a9R8bGxs1B07d+7Mz8/X1pHlhw4dosAAKhy0NkAPJc0CqOg0m5mZGRgY6OvrO2PGjDlz 5rRt2/bxxx9PTk62wjQ7cODABQsW3OMG5aVdunTJ6F3e3t7SAtrNLVu2NGvWTM136NChTZs24eHh np6eTk5O+/fv15aPHz/+PikwrtoCKhy0NkAPJc2SZgErSrOvv/76Qw89dP36dXXz1q1bkmafeeYZ K0yzZaJv377jxo0rRZqdOHGimm/Xrp3k6vswzQIAAJBmSbOAtaTZrKwsBweH0aNH6y6cO3eujY3N Dz/8IPODBw9etGjR2LFj3dzcmjdvHhsbq9a5du1aWFiY5Ew/P7/4+Hi1UFZevHjxzJkzPT09u3Tp cvjwYcNnlHUWLlw4YsQIeeyNGzeMbic9Pf3pp592cXFp27atZEUtzcpjlyxZYvl2MjIyhg4d2rRp 0zp16simZMmsWbMcHR1lNV9f302bNpUuzUoe7tevH2kWAACANEuaBSotzR46dEiC6+bNm3UXfvvt t7Jww4YNMt+9e3d3d/f58+efOHFCkmH9+vULCwtleWBg4LBhwyRGLlu2zN/fXz1QVm7cuLFk41On Tkm27N+/v+Ezyjqurq4SmM+ePVtUVGR0O0899VRwcPClS5d+/vnnPn36aGlWHjtt2jTLtyMLfXx8 JJTm5+efPn1aluTk5AQFBY0cOVLSb15eXknTrDwqOjq6Ro0aGzduJM0CAACQZkmzQKWlWcmx2sew moKCAltb2w8++ECFxkmTJqnlGRkZsvLBgwcvXLggMzExMUlJSYmJifb29qmpqWrliIgItfKKFSs8 PDyMptnhw4ereaPbuXz5siyUJKnW0f2msV6aNb8dtdDwd7al/qZxzZo1pVlkmzt27NDWIc0CAACQ ZgFUQpo9ffq0xLOoqP/5rX9ycrKW2XQDpGjYsOGiRYvi4+Nlhc6dOz/xm3379umtHB0d7e7ubjTN ausY3c6ePXtkYUpKyl3TrPntqIXffPON5WnW19d3+vTpulFf8q2WWiMjI9PS0ry8vEaNGnV/plmu 2gIqHLQ2QA8lzZJmAWtJs7dv327SpMlzzz2nu3Dp0qVOTk4ZGRl6oTE9PV3yocTL8+fPy8z27dvN JFVL0qzR7aSmptra2h48eNDyNGt0O2rh8uXLLU+zPXv2DAkJ0W6uXLlSgrGWWtXvZiVs29nZxcXF 3YdpluEaVDhobYAeSpplOAOsJc2KTz75pHbt2l999ZW6eejQIVdX19mzZ2uhMTAwMCsrq7CwcM6c OfXr18/OzpblAQEBPXr0UH/q5ubNm2phSdOsqe089thjgwcPzszMPHr06COPPHLXNGtqO7LE39// 2LFjMn/mzJmioiKZiYyMlOVGm0JetcR4eVIVqmW1yZMn66VZMWbMGGki9eVq0ixAhYPWBuihpFkA lZNmVfJ0cXHx8vJq3rx53bp1Fy1aVFxcrIXG0NDQli1bSjSVCLdr1y61XLJc79697e3tfXx83Nzc EhISSpdmjW5ny5YtshuyULLokiVLLEmzRrdz5coVWc3GxkZenYeHh7rs08mTJ1u0aOHp6an781cl Nzc3PDxc1vf29nZwcJAYL4naMM3Kar6+vkFBQdJKslzWt/2N9lkuxzaACgetDdBDSbMAKqKvSTA7 f/78uXPn1AeYeuFT7pVkqEVcTU5OztWrV+99zw23U1BQUIotG92fX375JSsrS2+hvBy9V6rJyMhI TEzUfrgLhmtQ4aC1AXooaZbhDLDeNGuK3keguJ9x1RZQ4bBcXnoWrQ0wHpJmAVRmX1u5cmV8fDxt CwAo6SFpx+NDUrYepCkAkGYB0NcAAFXpkCTTWrtO6+t2Txwz3/xHtQBAmgU4daCvAQCsKM1q01q7 jnxUC4A0C4C+BgCoYmmWj2oBkGYB3FNfY2JiYmJispLp8rqvOXAD1omrQJFmAWtMszQRyq/AACoc Zv4LdVvriP1hE7c+/Hxc87CkOatobYDxkDQLgL4Gjm0AFW69aXa905N7Q8buDY3c8GDAgWcnXd15 uLigkNYGGA9JswDoa+DYBlDh1tueuh/G6v1QltYGGA9JswDoa+DYBlDhVtqeuh/G0toA4yFpFgB9 DZWmGl8TAqDCy5z5qxbT2gDjIWkWAH0NAAAAIM0CpFkAAACANMsZNkCaBQAAAEizAOhrAAAAAGkW IM0CJcFVW0CFg9YG6KGkWc6wAdIsqluBAVQ4aG2AHkqaBUCaBcc2gAqntQHQQ0mzAEMPfQ0c2wAq nNYGQJrlDBsgzYICA6hw0NoAPZQ0y3AGkGZRNXDVFlDhoLUBeihpljNsgDQLAAAAkGYB0NcAAAAA 0ixAmq0GCgoKioqKqtxup6WlZWZmUswAAACkWYA0e5d7Y2Njo6KiPvzwww0bNly8eNGqXlFqaqrs 29WrV0vx2O7du0+bNs3o642Pj9ddEhcX98MPP8jMrVu3ogykpKTobUHWT0xMLPMXm5+fHxQU5OPj 4+7u/v3331PPAAAApFmANGvu3g4dOrRp0yY8PNzb29vOzi4mJqbCdjg5OfnSpUtmVpgyZYqNjc3U qVNLsTVTaVZeb61atc6fP68tefLJJyXMy0x2dvZQHe3atZNnNwyuAwcOXLBgwT2+NEM7duxo1qyZ NRcYV21B9UaF09oAqn0PJc0C1TDNTpw4Uc337NkzODi4wna4b9++48aNM3VvQUFB48aNfX19PTw8 LPnOsN7WzKRZe3t7ube4uFgvzerKzMxs2rTpoEGDyuOlGSV726NHj6pbYED1HkJBawP0UNIswxlg 1Wn2tdde8/T0lJnBgwcvXLhwxIgRzs7ON27cuHbtWlhYmMz7+flpX9M9cOBAr169ZKE8JC0tTS00 uqZsbfHixTNnzpQ1u3TpcvjwYVk4a9YsR0dHWVPy6qZNmwx3LCYmpmHDhkeOHLGxsdm2bZu2vE+f PtHR0Wp+1apVTz/9tNGtqTSr96Tq9f7f//2fg4PDBx98YCbNRkRESIrOysoy3DF5OUuWLCnRSzPV LFojz5s3z8XFpXbt2vIQtTOy2a5duzZo0CAwMFDb+YyMjKFDh0rMrlOnTtu2bc20Occ2gAqntQHQ Q0mzwP2SZs+dO1e3bt1XX31VRUFXV9e5c+eePXu2qKhIAtWwYcMk1i5btszf3189UMKbhLHi4uIf f/wxPz9fLTS6pmytcePGo0ePPnXqlOSu/v37y8KcnJygoKCRI0dKGMvLyzPcsd69e6sda9++/YAB A7TlrVu31sLkggULHn30UaNbM/qk6vV++umnU6ZMkRebnJxsNM2uXbvW1tZ2586dRltM91NfC1+a qWbRGlkeEhkZ+Yc//EEekpubK/du2LDh+PHj8vAXX3zx+eef15rXx8dny5Yt0uCnT5820+Yc2wAq nNYGQA8lzQLVP816e3s//PDDkt8kNGZnZ6ugNXz4cLXChQsXbGxsYmJikpKSEhMT7e3tU1NTZXm3 bt2Cg4N1fx1qak3ZWkREhFpnxYoVHh4eat7M13F/+uknebgEbJmPior63e9+p338azTN/mrsm8ZG n1SlWUmJv//970NDQw3TbEpKiouLiwRUUy2pl2bv+tLMNIvWyOLPf/5zz549DZ9u+fLlXl5e2nb0 frJrauMc2wAqnNYGQA8lzQLVP80+++yze/fu1b14r25gi4+Pl7zUuXPnJ36zb98+WS45tlevXg4O DhMmTLh165aZNXW3Fh0d7e7uftc0K+s/+OCDo+945ZVXZLPvvvtuSdOs0SdVaVZmDh06ZGdnt3r1 ar00GxIS0rJlS/UBqSVp9q4vzZJmMUyzX375ZceOHdvd8dBDD2nb+eabb3R3xtTGywNXbUH1RoXT 2gCqfQ8lzQLVMM1qv5s1GtjOnz8veWn79u1GH56QkODq6rp06VIza5Y0zRYWFso6b7zxxrLfBAcH +/n5aWl24cKFav6tt94qdZoVsn6DBg1atWqlpdkPPvhA8vmRI0fMtGRJ06wlzaKXZs+ePSu7sWPH Dpn/+OOPVZpV21m+fLnuRsy/OwAAACDNAvdvmhUBAQE9evRQXyq+efOm+jby3r17CwoKiouLO3bs uHjxYjNrmop8kZGRRq/iGxcXJyFT+y2uUNeCUp86DhgwICIiIi8vb9WqVfXq1dPSrN7WLEmzubm5 zZs3ly2rNCvJ0NHRUbZzXYdE61KkWb2duWuz6KXZAwcOSJq9ePFiamrqoEGDnJ2d1XLZiL+//7Fj x2T+zJkz6lLPRjcOAAAA0ixAmv1VMlXv3r3t7e19fHzc3NwSEhJkYYsWLSRleXl59enTR/tertE1 TUW+kydPykY8PT3Vh5Cafv36jR8/Xm+XHnnkkSFDhsjM7t27mzZtWrNmzf79+8+ePVtLs3pbsyTN /nrns2VbW1uVZqOiomwM7NmzpxRpVm9n7tosvxp801he3QMPPNCkSRPZt/r166sLQV25ckUeJXvl 4uLi4eGhLjFldOMAAAAgzQLVPM1aLicn5+rVq7pLsu+wZE0zJKFZ8udkdRUWFhr92zml21r50duZ EjXLr3f+Ho96+M07tOW//PKL4csv6cYBAABIs6RZoDqk2bz0LBoQ5nHVFlDhoLUBeihpljQLWEua LcjJPTFlWYxrMD0R91hgABUOWhugh5JmAVREmk3bfezrrsPX2neW5WqiAcHZJ6hw0NoASLOkWcBK 06zuh7F6Ew0Izj5BhYPWBkCaJc0C1phm9T6MJc2CYxtAhdPaAEizpFnAqoeelG0HTYVYJiYmJiam ip84agNWi6tAkWYBq/uPNLn3zII1W3yfi2kY/KV7X04sAAAAcF8hzQJVOM2qmbTdiYdfnrGudte4 5mHranUlzQIAAIA0S5oFqkCaVfLSs/Q+qqUBAQAAQJolzQLWnmY16qNaeiIAAABIs6RZoCqlWSUv PYsGhHnV+JoQABVOawO4H3ooaRaonmkWuMcCA6hw0NoAPZQ0C4A0C45tABVOawOgh5JmAYYe+ho4 tgFUOK0NgDTLGTZAmgUFBlDhoLUBeihpluEMIM2iauCqLaDCQWsD9FDSLGfYAGkWAAAAIM0CoK8B AAAApFmANAsAAACQZjnDBkizAAAAAGkWAH0NlYGrtoAKB60N0ENJs5xhA6RZVLcCA6hw0NoAPZQ0 C4A0C45tABVOawOgh5JmAYYe+ho4tgFUOK0NgDTLGfY9KigoKCoqqnK7nZaWlpmZSd8mzYICA6hw 0NoAPZQ0e5d7Y2Njo6KiPvzwww0bNly8eNGqWiE1NVX27erV/2fvXuCqqvL//3OxFPGSKKJyKUDJ Gyo5ilo4IgLeDXVUVMZyzNRyFMe8NjrmmDpNSVriFy1tsJoeyoAKeQ0Vw9GK/pa3QkUNFVCCFEOQ i//Pg/Vt/8733DigcvP1fJxHj30W+6y99tprnbPf7XO2mZV4bb9+/ZYuXWp0fxMTE3VL4uPjf/jh B1m4c+dOlIFr167p1SDrp6SkPPCdLSwsDAoK8vT0dHFxOXv2LNObNItHFndtASMc9DbADCXNWvTX nj17dunSZcyYMR4eHjY2NrGxsVW2k+np6ZcuXTKzwqJFi6ysrJYsWVKJ2kylWdlfOzu78+fPayW/ //3vJczLwq1btybreOaZZ2TrhsF13Lhxa9asuc9dM7Rv374nn3ySWU2aBQAAAEizlqbZ+fPnq+X+ /fsHBwdX2U4OGzZszpw5pv5aVFTUunVrLy8vV1dXS74zrFebmTRra2srfy0tLdVLs7pycnKcnZ0n Tpz4MHbNKGmtv78/Q580CwAAAJBmK5xmZ8yY4ebmJgthYWERERHTpk1r1qzZzZs3r1+/PnLkSFlu 37699jXd5OTkwMBAKZSXZGVlqUKja0pta9euXb58uazZp0+f48ePS+GKFSvs7e1lTcmrO3fuNGxY bGxsy5Ytv/rqKysrq927d2vlQ4cOjY6OVstbtmwZMWKE0dpUmtXbqNrfv/zlL/Xq1duwYYOZNBsa GiopOjc317Bhsjvr1q2r0K6Z6hatk99++20HB4eGDRvKS1RjpFo/P78WLVoMGDBAa3x2dvbkyZMl Zjdu3NjHx8dMn4M0CwAAADwqafbcuXNNmjR56aWXVBR0dHRctWpVampqSUmJBKopU6ZIrF2/fr23 t7d6oYQ3CWOlpaUXL14sLCxUhUbXlNpat249c+bMU6dOSe4KCQmRwry8vKCgoOnTp0sYKygoMGzY 4MGDVcN69OgxatQorbxz585amFyzZk23bt2M1mZ0o2p/P/7440WLFsnOpqenG02zn332mbW19f79 +432mO5VXwt3zVS3aJ0sLwkPD3/uuefkJfn5+fLXmJiYEydOyMsnTJgwduxYrXs9PT0TEhKkw0+f Pm2mz0GaBQAAAOp+mvXw8OjQoYPkNwmNt27dUkFr6tSpaoULFy5YWVnFxsaeOXMmJSXF1tY2IyND yvv27RscHKz761BTa0ptoaGhap1Nmza5urqqZTNfx718+bK8XAK2LEdFRT322GPa5V+jafaesW8a G92oSrOSEjt27DhkyBDDNHvt2jUHBwcJqKZ6Ui/NlrtrZrpF62Tx+uuv9+/f33BzkZGR7u7uWj16 P9k1VTlIs6i9uGsLGOGgtwFmKGnW0jQ7evTopKQk3Zv36ga2xMREyUu9e/d+9jdHjhyRcsmxgYGB 9erVmzdv3p07d8ysqVtbdHS0i4tLuWlW1n/iiSdmlnnxxRel2rfeequiadboRlWalYVjx47Z2Nhs 3bpVL80OGjTo6aefVhdILUmz5e6aJd1imGZ37Njh6+v7TJmnnnpKq+fbb7/VbYypykGaRV0dYAAj HPQ2wAwlzf6/NKv9btZoYDt//rzkpb179xp9+eHDhx0dHd977z0za1Y0zRYXF8s6f/7zn9f/Jjg4 uH379lqajYiIUMuLFy+udJoVsn6LFi06deqkpdkNGzZIPv/qq6/M9GRF06wl3aKXZlNTU6UZ+/bt k+XNmzerNKvqiYyM1K3E/NEBaRZ8tgGMcHobADP00U2zIiAgwN/fX32p+Pbt2+rbyElJSUVFRaWl pb6+vmvXrjWzpqnIFx4ebvQuvvHx8RIytd/iCnUvKHXVcdSoUaGhoQUFBVu2bGnatKmWZvVqsyTN 5ufnt23bVmpWaVaSob29vdTziw6J1pVIs3qNKbdb9NJscnKypNm0tLSMjIyJEyc2a9ZMlUsl3t7e 33zzjSz/+OOP6lbPRisHaRZ8tgGMcNDbADOUNHtPMtXgwYNtbW09PT2dnJwOHz4she3atZOU5e7u PnToUO17uUbXNBX5Tp48KZW4ubmpi5Ca4cOHz507V69JXbt2nTRpkiwcPHjQ2dm5fv36ISEhb775 ppZm9WqzJM3eK7u2bG1trdJsVFSUlYFDhw5VIs3qNabcbrln8E1j2bsGDRq0adNG2ta8eXN1I6ir V6/Kq6RVDg4Orq6u6hZTRisHaRZ8tgGMcNDbADO0jqdZpeBGbrn15+XlZWZm6pbcKmPJmmZIQrPk n5PVVVxcbPTfzqlcbQ+PXmMq1C33yv49HvXy22W08p9//tlw9ytaOUizqLG4awsY4aC3AWYoabb8 vxbl5X+/aH2sYzDn3wBpFgAAAKgFaTbr4Ddf+E39zLa3lKsHnQ6QZgEAAIAammZ1L8bqPeh0gDQL AAAA1MQ0q3cxljQLkGYBAACAGp1mr+0+airE8uDBoxIP0iweHu7aAkY46G2AGUqa1f/rj2s+TfD6 Q2zL4B0uw7g2C1QaaRbVOMAARjjobYAZ+iimWbWQdTDl+AtvbGvoF9925DY7P9IsQJoFn20AI5ze BsAMrQVpVim4kat3qZbxBJBmwWcbwAintwEwQ2t6mtWoS7W82QGkWfDZBjDC6W0AzNDalGaVghu5 jCeANIuagLu2gBEOehtghpJmOcMGSLMAAAAAaRYAcw0AAAAgzQKkWQAAAIA0yxk2QJoFAAAASLMA mGuoDty1BYxw0NsAM5Q0yxk2QJpFXRtgACMc9DbADCXNAiDNgs82gBFObwNghpJmAd56mGvgsw1g hNPbAEiznGEDpFkwwABGOOhtgBlKmuXtDCDNonbgri1ghIPeBpihpFnOsAHSLAAAAECaBcBcAwAA AEizAGkWAAAAIM1yhq2vtLT07t27VbChoqKikpKS2rg7VdPyOna4mWsAAABAjUizcXFxUVFRGzdu jImJSUtLq0uduH379mbNmt1/PfHx8SkpKWZW6Nev39KlS2vL7jzAlpfbMxam0LVr19ao/vnoo49y c3NJs6gu3LUFjHDQ2wAzlDRr0V979uzZpUuXMWPGeHh42NjYxMbGVtlOpqenX7p0qQbGP72GjRs3 bs2aNXUjzert2n22vNyescSCBQv+9a9/1ag0e/bs2YEDBxYVFZFmUS0YQmCEg94GmKGkWUvT7Pz5 89Vy//79g4ODq2wnhw0bNmfOnBoY/yrasFqUZvV2rWpabn6nnnvuuZrTP5rXXnvNzBggzYLPNoAR Tm8DYIbWrDQ7Y8YMNzc3WQgLC4uIiJg2bZrEg5s3b16/fn3kyJGy3L59+8TERLVycnJyYGCgFMpL srKyVKHRNaW2tWvXLl++XNbs06fP8ePHpXDFihX29vayppeX186dO/ValZ2dPXnyZGdn58aNG/v4 +Gj1lNuqGzdujBgxwsHBQV41d+5cLd7cT8NktXXr1qmXyPp+fn4tWrQYMGCAWl8vExrtFl1GazDa EjO7U26FQ4cOjY6OVstbtmyRSozummq54Xal/6VJTk5OrVq1mjRpUk5OjtFDoPVMUVGR1//1t7/9 zVS365Io+9FHH1Voo7ovv//D/cILLyxatEg3xK5evVoWzp0716hRo19//ZU0Cz7bAEY4vQ2AGVrT 06ycvjdp0uSll15SIcfR0XHVqlWpqaklJSUSk6ZMmSJBYv369d7e3uqFkgckY5SWll68eLGwsFAV Gl1TamvduvXMmTNPnTolGSMkJEQK8/LygoKCpk+fLsGjoKBAr1VSj6enZ0JCgtR8+vRprZ5yWzVw 4MDg4OBLly5duXJFEp0Wb+6nYbphNSYm5sSJE1I+YcKEsWPHGqZZo92iy1QNhi0xszvlVti5c2ct ga9Zs6Zbt26mds3odmW1gICAM2X69+8/aNAgo4dAd8ev/2bDhg2PP/74wYMHTXW75tatW1ZWVl9+ +WWFNqpbw/0fbon6TzzxxJ07d2T5l19+kbR/8uRJlc9tbW337t1LmgWfbQAjnN4GwAytuWnWw8Oj Q4cO1tbWo0aNkoChzvunTp2qVrhw4YJEjtjYWMkYKSkpcoqfkZEh5X379lVBQqvK1JpSW2hoqFpn 06ZNrq6uatnUF3pVPYY/yCy3VT/99JMUSgZW62hfPb3Phhn9Om5kZKS7u7vhCobdYopeDYYtMbU7 llRoNM0a3TXD7aalpcl2tQvmcXFx8vTy5ct6h8Boz3z99dcNGzbcvHmzmW7XnD59WlbIzMys0EY1 D+Rw//rrr02aNPn4449lWXqsT58+Wv0yL6KiokizqHrctQWMcNDbADOUNGtpmh09enRSUtK1a9eM ppTExETJBr179372N0eOHJFyCWyBgYH16tWbN2+eurRlak3d2qKjo11cXMynWVXPt99+a5hmzbfq 0KFDUqjtiBZv7rNhuqvt2LHD19f3mTJPPfWU4QqG3aKn3Bq0lpjaHUsqtDzNGm5XdZe23StXrsjT w4cPG8ZXvacSPlu1arV48WLzI0dz9uxZWUHqr9BGNQ/qcL/88ssBAQGy0LFjR+1rz8LNze2DDz4g zQIAAAA1N81qv5s1mlLOnz8v2cDUVy4lbzg6Or733ntm1qxomlX1REZGVrRVGRkZ1tbWR48e1Ys3 99kwbbXU1FSJqfv27ZPlzZs3G82iht2iy5IatJaY2h1LKpQ0GxERoZYlXlYozaqQeeDAAVW+Z88e eXru3DnzafbmzZuy0bFjx5aWlloycu6VXRe1sbFRkdXyjT7ww/31119LPZJj5eXa/4AoLCyUtn3x xRekWQAAAKC2plkREBDg7++vvj17+/Zt9W3kpKSkoqIiiS6+vr7avxdqdE1TKSI8PFxWNtoqKff2 9v7mm29k+ccff1S/lrSkVd27dw8LC8vJyZGI0rVrVy3+3U/DtNWSk5MlOqalpUmOmjhxola5bj1G u0VjSQ26LTG1O+VWOGrUqNDQ0IKCgi1btjRt2lRLs6Z2TXe70tuy3QkTJkgv5ebmjhkzpkePHiqj mkqzssvBwcG9e/fWuxxttNt1BQUFbdq0qUIb1fVADrfo0qWLnZ3drFmztJIzZ844ODgY/eUzaRYA AACoNWlWktLgwYNtbW09PT2dnJzUxbR27dpJeHB3dx86dGh+fr6ZNU2liJMnT0olbm5u6tKirqtX r8qrrKysJFG4uroa3o3J1LYSEhKaNGkihRKG161bp8Wb+2mY7mohISENGjRo06bNxo0bmzdvru66 pLuC0W7RVW4Nui0xtTvlVnjw4EFnZ+f69evLX998800tzZrZNd3tpqamSpiUGNyoUaNevXqpa6Rm 0uyxY8fkYDVs2PCJ30yaNMlUt+vav3+/j4+P+pddLdyorgdyuO+V3Rda2i8JViuZMmXK3//+9wc7 1wAAAADSbPWcYefl5akb9mhulbFkTTMkuOrdqFbz888/5+bmVrRVEo1Mbf2BNCw7O1uV3y5juIKp brG8Bgt3x3yFxcXFpnrPTJ/rVVtu/1du5OiSFPrOO+9UeqMP5HC/9dZbfn5+2tP//ve/EyZMqMa5 hkccd20BIxz0NsAMJc1yho3aYdu2bdW4dcnDrq6uW7du1Up27tx582omcw3VhSEERjjobYAZSprl 7Qwo3+XLl5csWaL3jx7LfNn3u0nXPj/KXAOfbQAjnN4GwAwlzQK16c1FHp/Z9NrepF/KrHcKbuQy 18BnG8AIp7cBMENJs0DtSLPa4zMbX91Ltcw18NkGMMLpbQDMUNIsUAvSrN6lWuYaHiru2gJGOOht gBlKmi3/7JwHDx6Ve/y07QvSLAAAAFBFaZZuBSyfTbqP3Z1Dvxw5//MOY+PbjjyzcgtzDQAAACDN AjU3zW5v9PukQbOThoTHPBGQPHpB5v7jpUXFzDUAAACANAvU3DSrezGWexoDAAAApFmgdqRZ3Yux zDVUJe7aAkY46G2AGUqa5QwbqCS9i7HMNVQlhhAY4aC3AWYoaZa3M6Aa3nqYa+CzDWCE09sASLOc YQOkWTDAAEY46G2AGUqaBUCaBZ9tACOc3gbADCXNArz1MNfwwHHXFjDCQW8DzFDSLGfYAGkWAAAA IM0CYK4BAAAApFmANAsAAACQZjnDBkizAAAAAGkWAHMN1YG7toARDnobYIaSZjnDBkizqGsDDGCE g94GmKGkWQCkWfDZBjDC6W0AzFDSLMBbD3MNfLYBjHB6GwBpljNsgDRb0xQVFZWUlFR7M0pLS+/e vWvqr1lZWTk5OTWhJZUWZeVTZbsAcPZGbwNghpJmAd56yvlrXFxcVFTUxo0bY2Ji0tLSauOO9+vX b+nSpZV7bXx8fEpKygNpxvbt25s1a2ZYXlhYGBQU5Onp6eLicvbs2SroEFMtqTS1C67NHB/qLvz7 3/8+ceKE9vSnn3769NNPmdeoMtyXiN4GUOdnKGkWqGtptmfPnl26dBkzZoyHh4eNjU1sbGyVNTg9 Pf3SpUvVm2bHjRu3Zs0ao+2paPNMZch9+/Y9+eSTVTkSyk2zFd21qtkFGYErV67UniYkJFRxvwEA gLqNNAvUwTQ7f/58tdy/f//g4OAqa/CwYcPmzJlTvWnWTHsq2jxTGVLa5u/vX6PSbEV3rWp2gTQL AABIswBptpJpdsaMGW5ubrIQFhYWERExbdo0CUU3b968fv36yJEjZbl9+/aJiYlq5eTk5MDAQCmU l2RlZalCo2tKbWvXrl2+fLms2adPn+PHj0vhihUr7O3tZU0vL6+dO3fqtcpo5UOHDo2OjlbLW7Zs GTFihJZmlyxZMnv2bCcnp7Zt28bFxelud/HixW3atOnevXtqaqq8vF27dh07doyPj9fWWbdunWF7 DJtndNdu3LghzXBwcPDx8Zk7d65hhnz//fflrw0bNpR6Nm7cKCXZ2dmyUWlqq1atJk2apP0SVa/P LWm8LlMtkUr8/PxatGgxYMAAUz1vuI75XdBrqpk9qtAumEmzFRpsum3jbQEAAJBmgbqfZs+dO9ek SZOXXnpJ5UNHR8dVq1ZJAikpKZGQM2XKFMkG69ev9/b2Vi+UXCqxobS09OLFi4WFharQ6JpSW+vW rWfOnHnq1CmJHyEhIVKYl5cXFBQ0ffp0ySQFBQV6rTJaeefOnVXyFGvWrOnWrZtWv4uLyzvvvPP9 999Pnjy5efPmxcXFqlzy1RtvvCGVPPvssxJ0x48f/8MPP7zyyiuy19pr1XVdvfYYNs/org0cODA4 OPjSpUtXrlyRsG2YZn/99dfw8PDnnntO6snPz5cSqTYgIOBMmf79+w8aNEhriW6fW9J4XaZaEhMT c+LECdmFCRMmjB071mjPG65jfhf0mmpmjyq0C2bSbIUGm27beFsAAACkWaAup1lJER06dLC2th41 atStW7dUJJg6dapa4cKFC1ZWVrGxsZJVUlJSbG1tMzIypLxv374qPmlVmVpTagsNDVXrbNq0ydXV VS2b+b6rYeXm0+yCBQvUcnZ2trTh6NGjqnzGjBmqXFbw8fFR8WbXrl12dnZ6afae2W8aG921n376 SQoldKl1TH2/9/XXX5eMp5bT0tLkJdq16Li4OHl6+fJlvT63sPEaS1oSGRnp7u5uvud11zHcBe2e ELpNNb9Hlu+C+TRbocGm242A5bgvEb0NoM7PUNIsUAfT7OjRo5OSkq5du6YbpbSMl5iYKLGhd+/e z/7myJEjUi7RIjAwsF69evPmzbtz546ZNXVri46OdnFxKTfNGlZuPs3q/m62ZcuW7777rl75okWL AgIC1HJ8fHxF06zRXTt06JAUav1mSZpV9WgvuXLlijw9fPiw4V5Y0niNmZbs2LHD19f3mTJPPfWU 0T01uo7hLmhDyHB4lLtH5e6C8PLyWrZsmfZUQq/kW1PjwZLBBjzAt1DQ2wAzlDTL2xlQE9Os9rtZ o1Hq/PnzEhv27t1r9OWSWxwdHd977z0za1YizRpWrtJsRESEWl68eLHRNHvjxg1pg8S5B5tmje5a RkaGtbW1ug5sYZo9e/as1HPgwAH1dM+ePfL03Llz95lmTbUkNTVVEuC+fftkefPmzUbTrKl1LEyz Fu6RJWlW91vK4sMPP5SMej+DDeDsjd4GwAwlzQKPdJoVkkP8/f3V9zxv376tvo2clJRUVFRUWlrq 6+u7du1aM2uaSrPh4eGm7pRrtPJRo0aFhoYWFBRs2bKladOmuml2wIABubm5xcXFK1eubN68ueF2 LUmzeu3Re2p017p37x4WFpaTk/P111937dq13DRbUlIiL5kwYYK8XBo8ZsyYHj16yG7eZ5o11ZLk 5GRJqmlpaRJ3J06cqDVPd9dMrWNhmrVwjyzZhTfffLNRo0bSfpXPpYULFy40Mx7KHWwAZ2/0NgBm KGkWeNTTrESLwYMH29raenp6Ojk5qe+RtmvXTpKPu7v70KFD1c2BTK1pKs2ePHlSKnFzc1MXBnUZ rfzgwYPOzs7169cPCQmR5KObZseNG/f0009LzY6Ojtp1woqmWb326D01umsJCQlNmjSRQm9v73Xr 1pWbZu+VXQuVvCdpXJJbr1691GXM+0+zploifdWgQYM2bdps3LhRcr66yZPerhldx8I0a+EeWbIL cqAlDFtZWXl4eEjAHjBggHZ75MoNNoCzN3obADOUNAvU5TRruby8vMzMTN2SW2UsWdOMq1evGr33 rNHKi4uLc3Nz9Qpv3rxZWFhYWloqVamrgvdDrz16Tw13raioyPKd1WRnZxvuyH0y1RLZltqF22WM 7pqpdXSZvyfEg9ojqSclJUX3V9wPcLABZnBfInobQJ2foaRZ4NFNswAAWKjgRi6dAIA0C4C5BgCo fR9J+3436drnR+kKAKRZAMw1AEBt+kiSx2c2vbY36Zcy6x0u1QIgzQJgrgEAak2a1R6f2fhyqRYA aRYAcw3Vg7u2gBGOSqdZvUu1/99ra+kigPdD0iyACsw1Hjx48ODBo4Y8ftr2BR/cQG08pSTNkmaB 6kmzdBH4bAMY4VXWn7qP3Z1Dvxw5//MOY+Pbjjyzcgu9DfB+SJoFwFwDn20AI7zmptntjX6fNGh2 0pDwmCcCkkcvyNx/vLSomN4GeD8kzQJgroHPNoARXnP7U/dirN49jeltgPdD0iwA5hqqDvfIASMc FfpI0r0YS28DvB+SZgEw1wAAtQD/wCwA0iwA5hoAAABAmgVIswAAAABpljNsgDQLAAAAkGYBkGZR c3HXFjDCQW8DzFDSLGfYAGkWdW2AAYxw0NsAM5Q0C4A0Cz7bAEY4vQ2AGUqaBXjrYa6BzzaAEU5v AyDNcoYNkGbBAAMY4aC3AWYoaZa3M4A0i9qBu7aAEQ56G2CGkmY5wwZIswAAAABpFgBzDQAAACDN AqRZAAAAgDTLGTZAmgUAAABIswCYa6gO3LUFjHDUrt7OysrKycl5qJsoLS29e/dubT8cRUVFJSUl j0gjH9Ihq4LBxvshaRYgzQIPa4ABjHDcZ2/v3bv34MGDeoWxsbGpqamW1BkfH5+SkqKWCwsLg4KC PD09XVxczp49+/B2ZPv27c2aNasJXZqRkREVFZWZmVmJ1/br12/p0qWG5XFxcYmJiXqd/MMPP5ip 6vvvv//qq6+qrJF37tyJMnDt2rWqPGRVM9j+/e9/nzhxQnv6008/ffrpp7wfkmYB0izAZxvACK8R vR0RESF5QPf6W3Z2dv369S9dumRJnePGjVuzZo1a3rdv35NPPlkFO1KhaJSenm7hvlTCokWLrKys lixZUomWmEqzPXv2tLOzO3/+vFby+9//fuPGjWZqHjNmTExMTJU18tatW5N1PPPMM1K/9j81KnfI KnqYqmaweXh4rFy5UnuakJDwUDdKmuUMGyDNgnN9gBGOCvT2jRs3Hnvssb1792ol77//ft++fStR v8Qef3//mpZmhw0bNmfOnIfRjKKiotatW3t5ebm6ulrydVy9lphJs7a2tvLX0tJSS9Ls3bt3W7Zs mZeXV5WN1OTk5Dg7O0+cOPE+D1lFD1PVDDbSLGkWIM0y18BnG8AIr9G9PXLkyHHjxmlPe/XqpbLT 9evX5U8SQtq3b6999zUsLCwiImLatGlSfvPmTXm6bt06lYEdHBwaNmwowUle/sILLyxatEir87XX Xlu9erXedteuXevn59eiRYsBAwYcP35cq1/Kly9f7ubm1qdPH61cUveIESNkEz4+PnPnzjUajZKT kwMDA+VP8tqsrCwpWbFihb29vZRIq3bu3Hmv7MqzbMLJyalVq1aTJk3SfnWpt19G911PbGysxMiv vvrKyspq9+7dWvnQoUOjo6PV8pYtW6TZRluigqLhnkqa/ctf/lKvXr0NGzZYkma/+OKLoKAgU399 SI3UhIaGSk7Ozc01+j9KjB4yw+NuuF2jY0P3f7joDjbDw2fmKEvNixcvbtOmTffu3VNTU6UT2rVr 17Fjx/j4+AqlWcPBZuGUIc1yhg2QZvEI4R45YITjYff2rl27GjRooAKJnN/L8i+//CLLEiSmTJki 59/r16/39vZWK0u8cXR0XLVqlaxZUlKiXbv79ddfw8PDn3vuOTmhz8/Pl4D0xBNP3LlzR/4ktUlW OXnypN52Y2JiTpw4UVBQMGHChLFjx2r1t27deubMmadOnZJgEBISosoHDhwYHBx86dKlK1euSBIz mmYlbklsKC0tvXjxYmFhoZTk5eVJ0ps+fbq0SjYkJfI0ICDgTJn+/fsPGjTI6H4Z3Xc9gwcPnj9/ viz06NFj1KhRWnnnzp1Vwhdr1qzp1q2b0ZaY2lNJsx9//PGiRYuaNGmSnp5ebpqdPXu2trkqa6Ty 2WefWVtb79+/3+imTR0yw+NuuF2jY0OjN9gMD5+Zoyz59o033pAR8uyzz7Zt23b8+PE//PDDK6+8 It1eoTRrONgsnDKP5vshaRYgzQIA8FAUFRU5OTlFRkbK8l//+tc//OEPsnDhwgUrK6vY2FjJAykp Kba2thkZGerUfOrUqdprdb+J+vrrr0ty0PKGhDFJZbIsqUlO/c00QDbt7u6uVRgaGqqWN23a5Orq eq/s7jvSGMkSqtzU11b79u2r4pNuoe5XWNPS0qQedfXvXtn9luTp5cuX9fbL1L7rkldJ+blz52Q5 Kirqscce0y7QGQ2K94x9iddwT7U0K0GuY8eOQ4YMKTfNSiQz9YvTh9dIce3aNQcHBwm6RjdtySHT Pe6mvmmsu44u3cGmd/jMH+UZM2ao8gULFvj4+Kh4uWvXLjs7uwqlWcPBZuGUeTSRZgHSLAAAD8vc uXMlRJWWlkpyUDEgMTFRTs179+797G+OHDlyz+CHlKbSrHj55ZcDAgJkQVLZRx99ZLjRHTt2+Pr6 PlPmqaeeMqwwOjraxcVFFg4dOiSN0e6aayrNSrQIDAysV6/evHnz1GVhvZikdkqr58qVK/L08OHD ets1te+6ZOUnnnhiZpkXX3xR1n/rrbcqGhQN91RLs7Jw7NgxGxubrVu3mkmzEpxMXTp+qI0UgwYN evrpp9WlUUNmDpnR4663XaPrmE+zeoev3KO8aNEiNT7vld012mia9fLyWrZsmfZUQq/kW1ODzcIp Q5rlDBsgzQIA8CCdOnVKTsT/53/+p0WLFurfBT1//ryU6N4dyjA2mE+zX3/9tbW1teRYiTFattSk pqZKEti3b58sb9682XyazcjIkKqOHj1qPs0qklscHR3fe+89w5h09uxZ2akDBw6op3v27JGn6tKl 7nZN7bumuLhYGvbnP/95/W+Cg4Pbt2+vBcWIiAi1vHjx4kqnWSHryxHp1KmTqTT7j3/8Q/f3yVXW yA0bNsjhM//PAhk9ZKaOu+52Ta1jYZq18ChbkmZ1v6UsPvzwQ8mopgabhVOGNMsZNkCaBQDgAevR o4ec0L/66qtaiZzr+/v7q+9S3r59+9atWxVKs6JLly5S56xZsww3l5ycLIklLS1NYs/EiRO1dGoq PnXv3j0sLCwnJ0dCcteuXY2m2aSkpKKiotLSUl9f37Vr16rC8PBw7ea3JSUlUs+ECRNkX3Jzc8eM GSN7rW4drLdfRvddI+FHQqb2a0mhbrOkrsWNGjUqNDS0oKBgy5YtTZs21YKibkssTLP5+flt27aV mk2lWT8/Py0x6nl4jZTYZm9vL2v+okPCs14DjB4yU8ddd7um1rEwzVp4lC1Js2+++WajRo2k/Sqf SwsXLlxoZrBZMmUiIyN1v71MmuUMGyDNoi7jHjlghKNqenv9+vUSdY4dO6aVyOn74MGDbW1tPT09 nZycDL+rWW6albN8qfPMmTNGtxgSEtKgQYM2bdpIVGvevLm62Y+pjJeQkNCkSRNpjLe397p164wm nHbt2km5u7v70KFDtW/Anjx5Usrd3NzUtb7U1FTJNpLfJKX06tVLXbIz3C+j+64ZPnz43Llz9bYu gW3SpEmycPDgQWdn5/r168sOShzSgqJeSyxJs/fKrv5ZW1sbTbPZ2dmtW7c2dWOhh9fIqKgoKwOH Dh3S25apQ2b0uOtt1+g6FqZZC4+yJWlWRpGEYdk7Dw8PCdgDBgzQbo9sdLBZMmUCAwM7dOjwqL0f kmYB0iwYYAAjHNXQ23l5eZmZmZXb4ltvveXn52dmBcljKozdLmO+tqKionJbcquMYfnVq1d1U59s 1+g/KvOg9r24uNhU/XotuR8SL1944YVKv7wKGmnqkJk67rrbrdDYMDW6LDnKltSTkpKi/RC33MFW 6WHDv9DDGTZAmgVnnwAjHDWityXJuLq6bt26lZ5/SGbNmrVr1y76gRlKmgVAmgWfbQAjnN5+kC5f vrxkyRL1z4cCIM1yhg2QZsEAAxjhoLcBZihpFgBpFjUe98gBIxz0NsAMJc1yhg2QZgEAAADSLADm GgCgVn1g1ZAHxwIgzXKGDZBmAQCoU5+bAEiznGEDpFkAAEizAEizAJhrqCbctQWMcNSx3uaTEXjU 3g9JswBpFgwwgBGOutDbHHTgUZsapFmANAsGGMAIB2kWYIaSZnkfAUiz4LMNYITT2xx0gBlKmgV4 62Gugc82gBFOb3PQAaYGaRYgzQL/i3vkgBGOquntghu5nLIDvB+SZgHSLHMNAFA7FOXlf79ofaxj cJV9YPHJCDxqSLMAaRYAgAcp6+A3X/hN/cy2t3xUqQdpFgBpFiDNMtcAADWU7sVYvQdpFgBpFiDN MtcAADWO4cVY0iwA0ixAmmWu4WHhHjlghOOBuLb7qKkQW/UPDgfwSL0fkmYB0iwYYAAjHPfb2z+u +TTB6w+xLYN3uAwjZAK8H5JmAd56mGvgsw1ghNem3s46mHL8hTe2NfSLbztym50faRbg/ZA0C/DW w1wDn20AI7zW9HbBjVy9S7V0EcD7IWkW4K2HuQY+2wBGeK3pbXWplmMB8H5ImgV462Gu4UHiHjlg hKNqervgRi5dBPB+SJoFSLPMNQAAAIA0C5BmAQAAANIsZ9gAaRYAAAAgzQKkWeYaAAAAQJoFSLOA Du6RA0Y46G2AGUqa5QwbIM2irg0wgBEOehtghpJmAZBmwWcbwAintwEwQ0mzAG89zDXw2QYwwult AKRZzrAB0iwYYAAjHPQ2wAwlzfJ2BpBmUTtw1xYwwkFvA8xQ0ixn2ABpFgAAACDNAmCuAQAAAKRZ gDRridLS0rt379LthoqKikpKSthHAAAA0iyAhzjX4uLiosrs37+/sLDQ8s1t3769WbNmajk+Pj4l JaXmdMVHH3104cIFtSyRW/bu4sWLWgzbuHFjUZnPP//8z3/+86pVqw4ePFjRTZjZ5X79+i1dutSS SjIyMqRtmZmZ1dtdn3zySZQxt2/fNvUSy/fx/vvT/LhVvvvuO94BAAAAaRZ4tNJsz549u3TpMmbM GDc3t0aNGn355ZeVSLPjxo1bs2bNfbY/PT390qVLFf2TUX379l24cKFaPnr0qJWV1ZtvvqmeHjly xMvLSxaGDBni6+v7z3/+849//OPo0aMr2lrdXdZrnuVJb9GiRdK2JUuWVO/ImTt37uQynTt3dnR0 nPybnJwc3dV07wnxwNNsRYeQjFtprdbU3bt317T5WNFBi2rHfYnobQB1foaSZoE6mGbnz5+vlp95 5hkJFZVIsw/EsGHD5syZU9E/GfW3v/1N9kstr1692sbGRrKrerp48eKZM2eeO3dOCq9du/YwWm5h 0isqKmrdurVEa1dX1xryrV3Zi169elkyhB54mq0oOb4SwmvyfKzooEUNfwsFvQ0wQ0mzvJ0BNTrN yvn38OHD1fL169dHjhwpebV9+/aJiYmq8MaNGyNGjHBwcPDx8ZEsoaXZsLCwdevWacsRERHTpk2T v968edNoPdnZ2ZMnT3Z2dm7cuLFUJSUrVqywt7eX1STd7dy5U7eFhn+Sl8tWnJycWrVqNWnSJL1L iCIpKcnW1la2LstDhw4dPXq0tLm0tFQl9oSEhPT0dGtr6w8++MBUd4WEhGzdulUtz5gx4/nnn9dq VhdytV02bJ5KesuXL3dzc+vTp8/x48eNbiI2NrZly5ZfffWVlZWV7qVFw84xVWi0b5OTkwMDA6VQ tp6VlWWm0JI0q9vVv7dqoXW1lmZ/+eUXWf7ss8/MNElqWLt2rfkO0RtC5a5vNM3qjT2pxM/Pr0WL FgMGDNAqyczM1MbwsmXLevToobvRxYsXt2nTpnv37qmpqdHR0e3atevYsWN8fHxF987MeAZnb6C3 AWYoaRbAg0yzcpou5+6PP/74f/7zH1UuAWDKlCkSCdavX+/t7a0KBw4cGBwcfOnSpStXrkhK1NKs 7pU6WXZ0dFy1apXkgZKSEqP1SKGnp6ekysLCwtOnT0tJXl5eUFDQ9OnTpSUFBQW6LTT8kzwNCAg4 U6Z///6DBg3S2ymptmHDhpIiJMFKbvn6668lMcrKEuTs7Ox+/fVXWWfhwoUSaF944QWJ6IbdIn2i EqxU1bx5c8nGKshJMyS36O6yYfPkT61bt545c+apU6ck/EgwNtrzgwcPVv8fQQLVqFGjtHLDzjFT aNi3Eqgk0cmOX7x4UfshtNFCS9Ksbld3smqidbXafalK+l/2Xbfxhk2ypEP0hlC568u4nTBhwrEy 2o9m9cZeTEzMiRMn5KDImmPHjtXW8ff3P3funAwGOcS6Y1gS+xtvvCFd9Oyzz7Zt23b8+PE//PDD K6+8ol3nt3zvzIxncPYGehtghpJmATywNFu/fn3JdZL39u3bpwovXLggT2NjYyXDpKSkSJbLyMj4 6aefpFAClVpH95vGelFk6tSpZupRhYY/krTwm8ZpaWnycu16V1xcnDy9fPmy3ksCAwNnz579/fff d+zYUZ46Oztv2rTpX//6l5Rr68hrJcDInwx/LXzo0KHGjRvfvXt3z549EuG6du0q+ysBSdY/e/as 3i4bftM4NDRULctGXV1dDfdIGiy9IZlKlqOioh577DF1ydRo55gp1Ovbe2W/GVb/x0F3ZaOF5aZZ va6ea9VO62rZxyVLlkycOHHIkCHFxcXmm2RJh+gNoXLXl3ErB86vTFhYmOHY0xUZGenu7i4L0uHS wl27dhkdwzNmzFDLCxYs8PHxUV//lpXt7OwqsXd805izN9DbADOUNAvgoafZ8PBwiVJyuv/qq6+q wsTERDlx792797O/OXLkiAQ8KdR+a2omzWrLRutRhd9++23l0qx6udaMK1euyNPDhw/rvWTlypXe 3t7vv//+tGnT5Okf/vCHF198cfz48f/85z91V8vJyZE8JnElLy9Pt7yoqKhp06ayrenTp2/YsOG1 1157+eWXk5KSOnXqZLibZn43Gx0d7eLiYrhHssITTzwxs4w0THbhrbfe0vZOr3PMFOr1rZRLZJXE Xq9evXnz5t25c0etbLSw3DSr19VfzPmH1tWyj7KmPE1OTi63SZZ0iKkhZGp9o9801vs1744dO3x9 fZ8p89RTT90r+6K4JWN4VPAuNQAAWoJJREFU0aJFAQEBajk+Pl6l2YruHWm21uG+RPQ2gDo/Q0mz QB1Ms+r7rhJWbWxs1E8Ez58/Lyfue/fu1V0zIyPD2tr66NGjlqdZo/WowsjIyMql2bNnz8rLDxw4 oJ7u2bNHnqqLnLqOHz8urZVM8vHHH8vTiIiIdu3atWjR4tSpU3prXr58We+Xq8ro0aMlL7m6ukr4 kc15eHjMmjXL6G5WNM0WFxdL4Z///Of1vwkODm7fvr2pzjFTqNe3Gsmcjo6O7733XrmFZtKsma5W +ygd0qpVK2mJ+SZVS5pNTU2V9K6+brB582aVZvPz8yWaat9BkC61PM1WdO9IswAAkGYBVFGaFRJO JO2o70/K2by/v7/6burt27dv3bolC927dw8LC8vJyfn666+7du1abpo1VY+UeHt7f/PNN7L8448/ qq90hoeHS7nRRur+SVaWZkyYMEGqys3NHTNmTI8ePdQdnvQSY5MmTSR+pKeny1P101ktaZw5c0bS +927d2X5ww8/lNij/fu0Gilv2rSpSncFBQUNGzaUpydPnjTcTb2WlxvGJCBJrtb9/aq6F5S61me0 c4wWGu3bpKSkoqIi6RBfX9+1a9eq+o0WlptmzXS12kdZlvEgOV+NGVNNqpY0m5ycLIc1LS1N2jZx 4kRtrErI7Nat29atW5csWdK5c2c5EBam2YrunZnxDAAASLMAHnCazc/P9/LyCgoKkpQiGWDw4MG2 traenp5OTk7q+6UJCQkSEaVQktW6dessSbNG67l69aqsJvnNwcHB1dVV3SZHgmK7du3c3Ny0S2ca vT+lpqZKrJJs2ahRI0lfhhdmtdyirsjdK/vmsMTRKVOmqKdxcXHytHHjxlKt9MAnn3xi+PJr165Z W1uvXLlSPR00aNDTTz9tNDjpNa/cMDZ8+HDDJNa1a9dJkyaZ6hyjhUb7Vloix8Xd3X3o0KFyQFXl RgvLTbNmulrbR+lYqbNLly4Sd001qbq+aRwSEtKgQYM2bdps3LixefPm6kZQ0kJJ4LIvCxcu/OCD D+SoWZ5mK7R3ZsYzAAAgzQJ46HMtLy8vMzNTt0TSi15J5eoRP//8s4pAuiS2mfrHV/X+lJ2dbfhy y0lV58+ff1D/5Kz5lleC0c4xWmjYt7fK6K1mtNBCFe1qo4e7WkjL1UG5XUbvr+PHjw8ODn4gg7lq RgUAACDNAqRZfQU3culAmFc37gmxevXqefPmffzxx3/605/s7e21XwUD3JeI3gZQ52coaRaoU2m2 KC//+0XrYx2DmYm4zwFWWxw6dGj58uUvvvjiwoULDW+sDUY46G0A/As9pFmgpqfZrIPffOE39TPb 3lKuHnQgOPsEIxz0NgDSLGkWqKFpVvdirN6DDgRnn2CEg94GQJolzQI1Mc3qXYwlzYLPNoARTm8D IM2SZoEa/dZzbfdRUyGWBw8ePHjwqPoHn9pAjcVdoEizQI37H2ny1x/XfJrg9YfYlsE7XIZxYgEA AIBHCmkWqMVpVi1kHUw5/sIb2xr6xbcduc3OjzQLAAAA0ixpFqgFaVYpuJGrd6mWDgQAAABpljQL 1PQ0q1GXapmJAAAAIM2SZoHalGaVghu5dCDMq8P3hAAY4fQ2gEdhhpJmgbqZZoH7HGAAIxz0NsAM Jc0CIM2CzzaAEU5vA2CGkmYB3nqYa+CzDWCE09sASLOcYQOkWTDAAEY46G2AGUqa5e0MIM2iduCu LWCEg94GmKGkWc6wAdIsAAAAQJoFwFwDAAAASLMAaRYAAAAgzXKGDZBmAQAAANIsAOYaqgN3bQEj HPQ2wAwlzXKGDZBmUdcGGMAIB70NMENJswBIs+CzDWCE09sAmKGkWYC3ngc314qKikpKSgyXq15p aendu3era+tZWVk5OTkMsEoPngd+iKt3PIARDnobYIaSZgFUQ5qNi4uL0vHdd9+ZqaRfv35Lly41 XK5627dvb9asmVqOj49PSUl52OF57dq1slBYWBgUFOTp6eni4nL27NlHcIBVurcrOmB0D/GDXbnK yOQ6duyYbsmmTZvOnz8vC5988kmUMZs3bzZafvv2bTVVN27cGBMTk5aWJpV89NFHubm5vPVx9kZv A2CGkmaBRzTN9uzZs3PnzpN/s3v37lqXZseNG7dmzZr7rDA9Pf3SpUum/rpgwYJ//etfsrBv374n n3yyZg4A87tw/1Wpe0JUurcfwTQrk2vu3Lm6Jba2tp9++qksSLmacTL7HB0dtQn46quvGi3PycmR 2rp06TJmzBgPDw8bG5vY2NizZ88OHDiwqKiId78HgvsS0dsA6vwMJc0CdTDN6p1w17o0+0AMGzZs zpw5prb13HPPqWXZZX9//5o5AMzsQjVWRZo1mmY10s+9evUyfK1hudQ2f/58tdy/f//g4GBZeO21 1x74kQIAgDRLmgVqcZrNzs4OCwtzcnJq1arVpEmTtN+ImkqzRtcPCQnZunWrWmHGjBnPP/+8Wk5K Sho9erTeFuXlERER06ZNk0xy8+bN69evjxw5Upbbt2+fmJio1rlx48aIESMcHBx8fHykzVp6kdeu W7fO8nqktZMnT3Z2dm7cuLFUJSUrVqywt7eX1by8vHbu3KnXNomyH330kSy8//77svWGDRvKahs3 bjTc3Nq1a/38/Fq0aDFgwIDjx4+rl2dmZmrNXrZsWY8ePbSmyvqLFy9u06ZN9+7dU1NTo6Oj27Vr 17Fjx/j4eLWO0farFy5fvtzNza1Pnz5qQ+Z3wehLTB24cqvS7W1T1er1sN6AGTp0qOysWt6yZYv0 j/lDXKHxoMvoEUlOTg4MDJT1pdlZWVmGr5L9evfdd2fPni0907Zt27i4OPOHQ3cMVE2alQkljZeF c+fONWrU6Ndff+UNEAAA0izwKKbZCRMmHCuj/Wg2KCgoICDgTJn+/fsPGjTIfJo1ur6ceasEW1hY 2Lx5czmPV2Fp+vTpkn/0miG1OTo6rlq1SkJdSUmJZI8pU6ZINli/fr23t7daZ+DAgcHBwZcuXbpy 5YrEIS296LWq3Hqk0NPTMyEhQRp2+vRpKcnLy5NdkIZJXCkoKNBt2K1bt6ysrL788ktZlswQHh4u 4VZWy8/PN9xcTEzMiRMnpAbp0rFjx2pN8vf3l9QhwUk6RLfZkiHfeOONixcvPvvss5Kaxo8f/8MP P7zyyityULSmGrZfXti6deuZM2eeOnVKwlVISIj5XTD1ElMHrtyqdHvbaLWGPaz3ws6dO2uReM2a Nd26dTN/iCs0HnQZPSISvCV/lpaWSs9LCw1fJU11cXF55513vv/+e4nlMnqLi4vNHA7dMaA3uSQ2 /48OGxub+0+zMpaaNGny0ksv3Su7t5bMrL179/IGCAAAaRZ4FNOss7OzX5mwsDApSUtLk/ymXZSL i4uTp5cvXzaVZk2tf+jQocaNG9+9e3fPnj0Sk7p27bp9+3Y53ZcIZ3j/JKlt6tSpavnChQtSQ2xs rESslJQUOVnPyMj46aefpFACklpH95uleq0yX48qNPzlp6nv1koYk/UzMzPV09dff11Sn9Fm64qM jHR3d1fBQ16+a9cuo82eMWOGWl6wYIGPj4/KQrKynZ2dqfarF4aGhqoXbtq0ydXV1fwumHqJmQNt vird3jas1lQPl5tmTR3iio4Ho7QjIvr27atisKmVpalyRNRydna2bOjo0aNmDofRMaAmlwz7aTqs ra3vJ816eHh06NBBKhk1atStW7dUuRRGRfETRAAASLPAI5lm9b4MmZiYKGft165dU0+vXLkiTw8f PmwqzZpav6ioqGnTpvLX6dOnb9iw4bXXXnv55ZeTkpI6depkPiOpCnv37v3sb44cOSLZWHcrZtKs +XpU4bfffmthmpXgLevLTplKs7q/Bd2xY4evr+8zZZ566ql7ZV+rtqTZixYtCggIUMvx8fEqzRpt v94Lo6OjXVxcLEmzhi8xc6CNVqXuCWGqt/WqNezhctOsqUNc0fGgy/CICMmxgYGB9erVmzdv3p07 d8x3l2jZsuW7775ryeEod3Ld5zeNR48eLSNK22vFzc3tgw8+4A3w/nFfInobQJ2foaRZoO6nWZXf Dhw4oJ7u2bNHnp47d85UkjGzvpx8S+Wurq5y/i0reHh4zJo1y+ipv27N58+flxr0vjyZkZFhbW19 9OhRy9Os0XpUYWRkpIVp9tdff7WxsVEZz3yaTU1NlYC0b98+Wd68ebPKTvn5+RJNVeG9siuElqdZ o+1/gGnWzIEzWpUaQuWmWVM9rJdmIyIi1PLixYtVmjV1iCs6HjRGj4hGjqmjo+N7771nvrtu3Lgh W5f6LTkcDzvNar+b1RQWFsr4/OKLL3gDfNhvoaC3AWYoaZa3M6AWpNmSkpLu3btPmDDh1q1bubm5 Y8aM6dGjR2lpqakkY2b9Dz/8sGnTpuqkvKCgoGHDhvL05MmT5vODkGjn7++vvgt6+/Zt9aVK2UpY WFhOTs7XX3/dtWvXctOsqXqkxNvb+5tvvpHlH3/8UX2/Nzw83NTNioOCgjZt2lRumk1OTpbslJaW JkFr4sSJWvMkGUpa27p165IlSyTFtWjRwsI0a6r9ptKsmV0w+hIzB85oVRamWVM9rLvyqFGjQkND ZUhs2bJFhoT2u1lTh7hC40Fj6ogkJSUVFRXJnvr6+qp/RtiwuwYMGCB9UlxcvHLlyubNm6stlns4 qj7NnjlzxsHBweivf8HZG70NgBlKmgUeuTR7r+yilgQbiRmNGjWSU2p1vc5MkjG1/rVr16ytrSUP qKeDBg16+umny41b98quvA0ePFhO/T09PZ2cnNSl0YSEhCZNmkihJKV169ZZkmaN1nP16lVZzcrK SmKAq6urutGRZOx27dq5ublp11E1+/fv9/HxUf+qp/lvGoeEhDRo0KBNmzYbN26UCKRuOyRtkNAl 3bJw4cIPPvhA3YrWwjRrtP2mMqSZXTD1ElMHzmhVlqdZoz2su/LBgwednZ3r168vPfbmm29qadbU Ia7QeNBl9IjIrsnK7u7uQ4cOVXfzMuyuIUOGyFiVPXJ0dNQuX5d7OKo+zU6ZMuXvf/87736cvdHb AJihpFngUUyzZmRnZ+fm5j689cuVl5en3X5JkUipV1K5esTPP/9s2FqJYXq3pVUkLL3zzjsWdoKq 4XYZvb+OHz9e/TOh999+U0ztQiUOnF5VFR1CRntYU1xcbPSvZg5x5caD0SNyq4ypl6iAWlpaKj2g LlZX+nA8VP/9738nTJjAWx9nb/Q2AGYoaRYgzcKcbdu2Ve6Fq1evnjdv3scff/ynP/3J3t5eu9BX 6zw6d20xc7m1Rtm5c6fhP6EEMwpu5DLCeT8B8CjPUNIsQJpFxRw6dGj58uUvvvjiwoULDe/0ixro ww8/TExMpB/q5Jvkvt9Nuvb5UboCAB5NpFmANAsAtfVNUh6f2fTa3qRfyqx3zF+qBQCQZjnDBkiz AFCD0qz2+MzGl0u1AECa5QwbIM0CQC1Ls1yqBQDSLGfYQK1Jszx48ODBw8zjp21f8FFSNbgLFMAM Jc0CYK6hpgwwoFaMYd3H7s6hX46c/3mHsfFtR55ZuYURzvsJgDo/Q0mzAGkWDDCgFqfZ7Y1+nzRo dtKQ8JgnApJHL8jcf7y0qJgRzvsJANIsZ9gAaRZ8tgE1dwzrXozV+6EsI5z3EwCkWc6wAdIs+GwD augY1r0Yywjn/QQAaZYzbIA0i0cCd21BbWf+rsWMcN5PANT5GUqaBUizAAAAAGmWM2yANAsAAACQ ZgHSLHMNAAAAIM0CpFkAAACANMsZNkCaRa3FXVvACAe9DTBDSbOcYQOkWdS1AQYwwkFvA8xQ0iwA 0iz4bAMY4fQ2AGYoaRbgrYe5Bj7bAEY4vQ2ANMsZNkCaBQMMYISD3gaYoaRZ3s4A0ixqB+7aAkY4 6G2AGUqa5QwbIM0CAAAApFkAzDUAAACANAuQZgEAAADSLGfYAGm2koqKikpKSjiyAAAAIM0CpFl9 cXFxUVFRGzdujImJSUtLq/pmx8fHp6SkGP1Tv379li5dav7l33333aefflq9PW9mFyyhDoHYv39/ YWGh7p9KS0t37dq1bNmy6dOnr169Wo7RL7/8Ul27yV1bULcxwultAHV+hpJmgbqWZnv27NmlS5cx Y8Z4eHjY2NjExsZWcbPHjRu3Zs0atZyenn7p0qUKpdl//OMfTz75ZPX2vO4umKK3a0YPgZubW6NG jb788ktVnp2dHRAQ4OLisnDhwvfffz88PLxTp06JiYk1c4ABdfstFPQ2wAwlzfJ2BtTENDt//ny1 3L9//+Dg4GrchWHDhs2ZM6fWpdlK7JqpQ/DMM89INlbLU6dOdXd3v379uu7KpaWlfLYBjHB6GwAz lDQLkGb/T5SaMWOGm5ubLKxdu9bPz69FixYDBgw4fvy4+mtmZuaIESMcHBx8fHyWLVvWo0cPVS5x a+TIkc2aNWvfvr3hlcOQkJCtW7dq9T///PNqOSkpafTo0bIQFha2bt06WVixYoW9vb3U4+XltXPn Ti3NLl++XFrVp08frSWm0qxhsydPnvz2229rK7/yyiuRkZGmdjA5OTkwMFAaIJvLyspShdnZ2VKJ s7Nz48aNZcdVobQ5IiJi2rRpsvLNmze1XVB/evfdd2fPnu3k5NS2bdu4uDiju2bqEEjoHT58uCzk 5OTY2NhERUXVlgEGcPYGehtghpJmAVRPmj137lyTJk1eeuklWY6JiTlx4kRBQcGECRPGjh2r1pRs 6e/vL6tJ0pNQKtlMlUsgnDJlioS69evXe3t769UvlasEW1hY2Lx5c1tbW8lp8nT69OkSU+/pXIDN y8sLCgqSconHsmn1p9atW8+cOfPUqVMSmCUYm0+zhs3+8MMP3d3d1fXMGzdu2NnZqa/7Gt1BCcyS UWXlixcvar9flb3z9PRMSEiQktOnT2td4ejouGrVqtTU1JKSEt1ryLLs4uLyzjvvfP/99xKDZZeL i4sNd83wEMifoqOjH3/88f/85z9SeOzYMSsrq++++47PNoARTm8DYIaSZgHSrPE06+Hh0aFDB2tr 61GjRt26dUv3r5GRkZIGVdaVcLVr1y5Vvn37dpVmL1y4IOWxsbFnzpxJSUmRsJqRkaFbw6FDhxo3 bnz37t09e/YMGjSoa9eu8lpJgK1atTp79uy9//t1YsNvGoeGhqrlTZs2ubq6mk+zhs2WGGlvby9t kOW333574MCBptYUffv2DQ4O1v11q9o7w9/ESsOmTp2q+1Q3zS5YsEAtZ2dny8uPHj16r7xvGtev X1/6X1bet2+fKpSulqfp6ek1Z4Bx1xbUbYxwehtAnZ+hpFmgDqbZ0aNHJyUlXbt2TSvcsWOHr6/v M2Weeuqpe2VfDJZwpa2jpdnExEQp792797O/OXLkiG79RUVFTZs2ldWmT5++YcOG11577eWXX5ba OnXqZBgFzfxuNjo62sXFxXyaNWy2+OMf/zhp0iRZaN++fUxMjJk1JccGBgbWq1dv3rx5d+7c0fbu 22+/NUyzuj/o1Uuzun9q2bLlu+++W26aDQ8Pz8rKklz96quv/u8HycmTsmm9zgQAAABpFiDN/r8o pf1oU0lNTZVEpy4Sbt68WYW9/Px8Ozs77cphZGSkSrPnz5+X0LV3714zm5a0PHfuXFdXVwnDBw4c 8PDwmDVrltH4dz9p1mizVSK1t7dPSEho1aqVRGszayqHDx92dHR87733tL1TP7WtRJq9ceOGvFyS /z3L7gJ16NAhGxub+Ph4WS4oKGjevLn64jcAAABIswBptvw0m5ycLGEvLS0tIyNj4sSJ2u9jJY91 69Zt69atS5Ys6dy5c4sWLVR5QECAv7+/+oLu7du39b6rfK/sx6tNmzbt1auXCmkNGzaUpydPnjSM f+Hh4VJVRdOs+qqwqWaXlpZK3G3ZsuXChQvN72BSUpLEXVnf19d37dq1qlDa4+3t/c0338jyjz/+ WFJSUm6aHTBgQG5ubnFx8cqVKyWRqg7R2zVTh0ByvmRp9W1tSdG2trZvv/22VCVPZdO7du2SNqg/ SeWMeQAAANIsQJr9P0JCQho0aNCmTZuNGzdKHlP3SZKIFRYWJqFUYuEHH3yg7n6sygcPHiy5y9PT 08nJ6fDhw3q1Xbt2zdraWktfgwYNevrpp41GQYm47dq1k5rVhVNL0uyMGTO02zgZbbb461//Kg24 cOGC+R2UTUuylWw8dOjQ/Px8tebVq1elGVZWVg4ODq6urtrtqcyk2SFDhsgOSmsllx44cMDorpk6 BLJdLy+voKAgdecq6Wdpnp2dnapQGqbSbGBgYIcOHRjzAAAApFng0U2zSsGNXL2S7OxsdR3ydhm9 v44fP17vX6bNy8vLzMx8IDsiAVJt2oyff/45Li5u27ZtkjA//fRTC5td7g7eKmN0c7m5uZY0XiVb yaKyF4b/Nqwlu2YoPT39zJkz1fgvzf5vIOeuLajTGOH0NoA6P0NJs0CdSrNFefnfL1of6xhsyUxc vXr1vHnzPv744z/96U/29vbaVcdqcfHiRW9v7+HDh//73/++e/duzTkKepdtH50BBjDCQW8DzFDS LICqSLNZB7/5wm/qZ7a9pVw9yq3/0KFDy5cvf/HFFxcuXGh4m18oH374YWJiIp9tACMc9DbADCXN AniQc033Yqzegw4EZ59ghIPeBkCaJc0CNTHN6l2MJc2CzzaAEU5vAyDNkmaBGv3Wc233UVMhlgcP Hjx48D/1qhh3gQKYoaRZABWbaz+u+TTB6w+xLYN3uAzjNA4AAACPFNIsUIvTrFrIOphy/IU3tjX0 i287cpudH2kWAAAApFnSLFAL0qxScCNX71ItHQgAAADSLGkWqOlpVqMu1TITAQAAQJolzQK1Kc0q BTdy6UCYx11bwAgHvQ0wQ0mzpFmgxqVZ4D4HGMAIB70NMENJswBIs+CzDWCE09sAmKGkWYC3HuYa +GwDGOH0NgDSLGfYAGkWDDCAEQ56G2CGkmZ5OwNIs6gduGsLGOGgtwFmKGmWM2yANAsAAACQZgEw 1wAAAADSLECaBQAAAEiznGEDpFkAAACANAuAuYbqwF1bwAgHvQ0wQ0mznGEDpFnUtQEGMMJBbwPM UNIsANIs+GwDGOH0NgBmKGkW4K2HuQY+2wBGOL0NgDTLGTZAmgUDDGCEg94GmKGkWd7OgGpOs3Fx cVE6vvvuuxq1U1rz9u/fX1hYqPun0tLSXbt2LVu2bPr06atXr46Jifnll18YBg8Pd20BIxz0NsAM Jc2SZoEalGZ79uzZuXPnyb/ZvXv3Q21kenr6pUuXLF9fmtelS5cxY8a4ubk1atToyy+/VOXZ2dkB AQEuLi4LFy58//33w8PDO3XqlJiYyDAAAAAAaRZ4VNLs3Llzq6yRw4YNmzNnToXS7Pz589XyM888 M27cOLU8depUd3f369ev665cWlrKMAAAAABpFnhE02xWVtbvfve7zZs3q6eff/55UFDQ3bt3ZVnS 48iRI5s1a9a+fXvtQmh2dvbkyZOdnZ0bN27s4+OjCocOHRodHa2Wt2zZMmLECFlYsWKFvb29vNzL y2vnzp2mKjSVZiUJDx8+XBZycnJsbGyioviiGgAAAEizwCOcZocMGfJJGQmuqnDbtm12dnYnTpyQ pNqmTZuDBw+q8gEDBkyZMuXmzZvr16/39vbWCj09PRMSEgoLC0+fPq0KO3fuvG7dOrW8Zs2abt26 yUJeXp4E4+nTp0uILSgoMFWhYZqV9SUbP/744//5z3+k8NixY1ZWVjXtJ74AAAAgzQKo0jTbqVOn SWUWLVqklc+ePbtt27bDhw+XBVVy4cIFyZCxsbFnzpxJSUmxtbXNyMhQhZJX9ao1mmbv/d9vGhut 0LB59evXt7a2ljX37dunCnft2iVP09PTOehVibu2gBEOehtghpJmSbNAzUqzRn83e+vWrYYNGz7x xBP5+fmqJDExUTJk7969n/3NkSNHVOG3335biTRrtELD5oWHh2dlZbm7u7/66qv/+yZ78qS80HBl VOMAAxjhoLcBZihpFkCNSLPTpk0bMmRIy5Yt//GPf6iS8+fPS4bcu3ev7mqqMDIy0jDNRkREqOXF ixcbTbNGKzRsnvrd7KFDh2xsbOLj42W5oKCgefPmL730EgedzzaAEU5vA2CGkmYB0uz/s23bNg8P j5s3bx44cODxxx8/fPiwKg8ICPD391f/xM7t27dv3bolC1Li7e39zTffyPKPP/5YUlIiC6NGjQoN DZXYuWXLlqZNm2ppNjw8XNbXNmS0QqNpVsyaNcvR0VF9G1nys62t7dtvv11cXCxPZaO7du2Sras/ rVy5kvHAZxvACKe3ATBDSbNAHU+zVlZW1r8JDAxMS0uT0PjVV1+pFZYvX96qVSuVIeW/gwcPlhjp 6enp5OSkUu7Vq1f79esnlTg4OLi6uqrbOx08eNDZ2bl+/fohISFvvvmmlmZPnjzZrl07Nzc39SNY oxWaSrP5+fleXl5BQUHqX+L54IMPmjdvbmdn9/TTT7u4uAwdOlSlWdmFDh06MB74bAMY4fQ2AGYo aRaoy2m2EvLy8jIzM/UKf/7559zcXN2S4uJivRKNBGB1CddMhRZKT08/c+YM/9JsFeCuLWCEg94G mKGkWdIsULvTLAAAAECa5QwbIM0CAAAApFmANMtcAwAAAEizAGkWAAAAIM1yhg2QZlFbcdcWMMJB bwPMUNIsZ9hA9aTZGvLgSNXJAQYwwkFvA8xQ0iyAh5VmeX8Exw5ghNPbAEizpFmANMv7IwMMYISD 3gaYoaRZAKRZ8NkGMMLpbQDMUNIswFsPaRYPFndtASMc9DbADCXNcmoLkGYBAAAA0iwA0iwAAABA mgVIs6RZAAAAkGZJs0AtSLMFN3JJswAAACDNkmaB2pFmi/Lyv1+0PtYxuMpmIlO+9uKuLWCEg94G mKGkWU5tgepPs1kHv/nCb+pntr2lXD1Is+DYgREOehsA/0IPaRaooWlW92Ks3oP3R3DswAgHvQ2A NEuaBWpimtW7GEuaBccOYITT2wBIs6RZoEa/9VzbfdRUiK36B0eKzzaAEU5v0wkAM5Q0C6ACc+3H NZ8meP0htmXwDpdhhExUFHdtASMc9DbADCXNkmaB6kmzaiHrYMrxF97Y1tAvvu3IbXZ+pFkAAAA8 CkizQK1Ps0rBjVy9S7V0IAAAAEizpFmgpqdZjbpUy0wEAAAAaZY0C9SmNKsU3MilAwEAAECaJc0C tSzNAuXiri1ghIPeBpihpFnOsAHSLOraAAMY4aC3AWYoaRYAaRZ8tgGMcHobADOUNAvw1sNcA59t ACOc3gZAmuUMGyDNggEGMMJBbwPMUNIsb2cAaRa1A3dtASMc9DbADCXNcoYNkGYBAAAA0iwA5hoA AABAmgVIswAAAABpljNsgDQLAAAAkGYBMNdQHbhrCxjhoLcBZihpljNsgDSLujbAAEY46G2AGUqa BUCaBZ9tj66ioqKSkpIHXm1WVlZOTg7dywintwGQZjnDBkizYID9r7i4uCgd3333XU1obUZGhjQm MzOzepvxySefRBlz+/ZtUy/p16/f0qVLH2AbCgsLg4KCPD09XVxczp49+5D2tGYOA87e6G0AzFDS LECaBUwOoZ49e3bu3Hnyb3bv3m2mkvT09EuXLt1/Y8qtZ9GiRVZWVkuWLKneTps7d67qFukiR0dH rZfMXCZ94Gl23759Tz755MPe0woNg2pR7pjhTZJzZQCkWc6wAdIs6iZT94SQGCOZzcJKhg0bNmfO nPtvjPl6ioqKWrdu7eXl5erq+jC+tVsJ0tpevXpZsuYDT7NSm7+/fxWkWcuHQbUod+xxX6Ka8H4C gBlKmgVIs8w1VB3DGJOVlfW73/1u8+bN6unnn38eFBR09+7dFStW2NvbN2vWTHLmzp075U9hYWER ERHTpk2Twps3b65du9bPz69FixYDBgw4fvy4enl2dvbkyZOdnZ0bN27s4+MjJYb16ImNjW3ZsuVX X31lZWWle5HQsCpThdevXx85cqRson379omJiaowOTk5MDBQCt3c3GQfzRRakmZlu7L7Tk5OrVq1 mjRpkna1Vkuzv/zyiyx/9tlnZpokNUinLV++XLbep08frdM077//voODQ8OGDaWvNm7caNjnppqh al68eHGbNm26d++empoaHR3drl27jh07xsfHW5hmLTm+mZmZI0aMkEZK5y9btqxHjx6WN8DyPil3 zAAAHgWkWYA0C+jHmCFDhnxSRoKrKty2bZudnd2JEyckLEkaOXjwoBTm5eVJrJ0+fbqEkIKCApXc HB0dV61aJVmlpKQkJiZGXiJ/mjBhwtixY1VVknw8PT0TEhIKCwtPnz5ttB49gwcPnj9/vixINBo1 apRWbliVmcIpU6ZIAFu/fr23t7cqlGgk2ay0tPTixYuysplCS9Ks7EJAQMCZMv379x80aJBumpWq pFD2Ubfxhk2SlVu3bj1z5sxTp05JrgsJCdHb7q+//hoeHv7cc89JX+Xn5xv2uZlmSL594403ZL+e ffbZtm3bjh8//ocffnjllVfkiBsdBnLUjpXRfjRryfGVdfz9/c+dO5eVlfX8889L4LS8AZb3Sblj BgBAmuUMGyDN4lFMs506dZpUZtGiRVr57NmzJYEMHz5cFrRCvW97SvCYOnWqYZ2RkZHu7u6ycOHC BSsrqzVr1uitYOZbo5cvX7a1tZV0JMtRUVGPPfaYumRqtCozhbGxsRLwUlJSpLaMjAwp79u3b3Bw sN5vL40Wlptm09LSZBPaRcK4uDh5Ki1XfbJkyZKJEycOGTKkuLjYfJNk5dDQULXOpk2bXF1dDTf9 +uuvS0w12ufmmzFjxgxVvmDBAh8fH/Wd7V27dtnZ2RkdBs7Ozn5lwsLCLDy+cphki1KnKt++fbtu mjXfgIr2yYP6ljsA/P/t3Ql8TWf+x3HEoAQlIqksRVBqCTXEMrZGxN5aaimZoMagFP1rUDMoY5ku CMq0FFOmHaW111axxlSJMdaxq5JYIpYYQhb/3+T59/xv7z3n5Ga/9+bzfp2X170n557znOc8z3PP 17n3XJBmOcMGSLNwnTSr+4XJ+/fvlyxZ8tlnn1WXBI3SrOV3RNevXx8UFPRSusqVK8ucqKgoSSxH jhyxP83KCmWjI9MNHDhQXv7BBx8YrcpkZtOmTZv/bN++fTJfImtISEjRokUjIiIePXqkFtadmWGa VZuIjY1VT69evSpP9+zZo+pElpSn0dHRGRbJsgJXrFjh6+trT5rVXmJeDG2xd999Nzg4WD3etGmT UZq1bQYZHt+9e/daFsAqzZoXILN1QpoFAJBmAdIsCqjM3gVq6NChnTp1qlix4vvvv29Pmj179qxk wu3bt8vjZcuWqbRz/vx5SSyLFi2yM82mpKRIennrrbcW/iw0NLRmzZpGqzKZuW3bNt39lbDn6em5 YMGCDGeapNnTp0/LJr777jv1dOvWrfJUXU9WdTJq1Chvb28piXmRsplmMyxGDqZZ3eP78OFDWZua +TT9mq39aTazdcJdoJxiPAFADyXNAqRZ+hryroHpxpjVq1dXrVr13r17kpSKFSumLveJMWPGWN5f 1zJ4REdHS9q5ePFiXFxc//79tVQjy9etW/fw4cPy+MyZM+rjplbr0UjUqVChguX3V9W9oNRVO91V 6c6U7CTz1eeHHzx4cP/+/afpFxKTk5PT0tKCgoLmzZun1q87M8M0K1tp2LBhv379ZM137tzp1atX o0aNZCVancjjsLAwqUP16VmjImUzzWZYjBxMs0bHV0Jm/fr1V65cOWnSpDp16sjhszPNZrZOjNoM g6QDvmEBoIeSZgGGHvoa8ijNSlws/LOQkBBJLJ6enhIj1QLTpk3z9vZWqez48ePVq1f39/dXl+Os PonarVu3EiVKVKpUafHixR4eHupGQdeuXZPFZBPly5f38/NTt/CxWo+ma9eutpkqMDAwPDzcaFW6 M6W0HTt2dHNzCwgI8PLyUmlctigZrEqVKp07d9Y+Pq07M8M0+zT9WqVEx7Jly7q7u8uf1BVRyzqR kCzrrFevnuRMoyJlM83aU4ynOfdJY93jK/sluV02PWHChM8++0yOqf0FyFSdGLUZBknOlQGQZjnD Bkiz4L3NXhIgjX4GNj4+Xv3pQTpt/u3bt1Wos3M9JnRXpTszMTHx+vXrlnPup7NaTHemnWR/bbdr wrZIOSKzxcjOhnSPr/L666+HhoZmdp2ZqhOTNsMgybkyANIsZ9gAaRa8twH2+vOf/xwREfG3v/3t jTfeKFWqlPYlXlo44wkAeihpFmDooa8hZ3DXFuSG3bt3T5s2beDAgRMmTLC9eTUtnPEEAD2UNAuQ ZulrAAAAKNBIswBpFgAAACDNcoYNkGYBAAAA0ixAmqWvIfcamINMHAsAAECaBUizgL0c5J4QtGS4 dguntgHQQ0mzAGmWvgbXjJG0ZNC0qG0A9FDSLECaBUizAE2L2gZAmuUMGyDNgvc23mJBCwe1DdBD SbMA6GvgvY2WDJoWtQ2AHkqaBUiz9DVkC3eBAi0c1DZADyXNcl4CkGYB0iwAACDNAqCvIb8l3bpD mgUAAKRZAKRZOIfkxIfH3l241jM0zxoYLRkAAJBmAdIskHU3dh3e2WLIKrem0rTURJoFAACkWQCk WTgcdU8Iy4uxVhNpFi7QwkFtA+AuUJxhA6RZuGADs7oYS5pFwRlCQW0D9FDSLMMZQJqFU4rdcsAo xOb9xOEAZ2/UNgB6KGkWIM0CmWhgZ+Z8ubnGa2srhq737ULIBGdvoLYBeihpluEMIM3CmRrYjV0x BwdMXV2yxaZq3Vc/04I0C87eQG0D9FDSLADSLByX1T0hkm7dsbpUSxXBlVo4qG2AHkqa5QwbIM3C xalLtTQwAABAmgVAmoXzSbp1h0oAAACkWQCkWQAAAIA0C5Bm6WsAAAAgzXKGDZBmUQBx1xbQwkFt A/RQ0ixn2ABpFq7WwABaOKhtgB5KmgVAmgXvbQAtnNoGQA8lzQIMPfQ18N4G0MKpbQCkWc6wAdIs aGAALRzUNkAPJc0ynAGkWTgH7toCWjiobYAeSprlDBsgzQIAAACkWQD0tXRz5sxp5erCw8MnAwAA wJScMsmJU2RkJGkWIM06h8DAwEIAAABAuvr165NmAdKsc5ABS41cv3FFatdat249BQAAAKYqV65M mgVIs86kVatWKsomuKJx48bJ3k2ePDm/qpe7tsC10cKpbQCu1EPVaWHr1q1JswBpljRLmmW4RoEe QkFtA/RQ0izDGUCaJc2SZgHO3qhtahugh5JmAdDXspdmhw8f3rVr19jYWNIsZ59gCKUSqG0ApFnO sAHSrNOk2Vq1aslLrly54vhpdtiwYaRZgBZObQOgh5JmAdIsadaZ0uzRo0fVPY25CxRAC6e2AdBD SbMAaZY0+4s0++9//7t3797e3t5lypRp3rz5tm3b1DJG89u3b1+tWrWtW7c2atRI/tSlS5eLFy/m RpQ9ceLE888/L+X09fW9dOkSTR0AAIA0C5BmSbP/l2Zv3rxZp06dIkWKREREfPLJJ15eXsWLFz94 8KDRfO21tWvXHjFiRNWqVeXxxIkTcy/KVq5cmSgLAABAmgVIs6TZX6TZr7/+Wh4EBgaq+ZJd5env fvc7o/naa6Ojo+Xxrl275HHjxo1z/APGWpQ9d+4cjRwAAIA0C5BmSbO/SLMffvihPAgLC1PzV65c KU9DQkKM5lt9SjkuLk4e/+pXv7p9+3YORtmAgACiLAAAAGkWIM2SZg3T7BdffCEPgoKC1Pz33ntP noaHhxvNt0qz6tqsr69vjkdZx/muLHdtgWujhVPbAFyph5JmAdJsAUqzV69e9fPzK1as2KJFi6Ki ol588cXChQtv3brVaL722sGDB+/Zs6d9+/byeNSoUS582yeGaxTkIRTUNkAPJc0ynAGkWQdNs/I4 Ojq6QYMG6odwKlasuHjxYrWM0Xz12tdee61wuk6dOv30008ufNsnhmtw9gZqG6CHkmYZzgDSrKOk WVuXL18+c+aMPfO1JCwkdrr8bZ8YrsHZG6htgB5KmmU4A0izuSIwMFBdQR2XJzw9PWVbY8aMyakV Dhs2TJXfMW/7xHANzt5AbQP0UNIswxlAms0V6qqms3Oo78pa4q4tcG20cGobgCv1UNIsQJp1Mura bOXKlSc7M8eMsgAAAKRZ0ixAms3TYQsAAACkWdIsQJolzQIAAIA0S5oFSLOkWQAAAJBmAdIsaZY0 m3u4awto4aC2AXooaZY0C5BmSbOu1sAAWjiobYAeSpoFQJolzfLeBtDCqW0A9FDSLMDQQ5oF720A LZzaBkCa5QwbIM2SZmlgAC0c1DZADyXNMpwBpFnSrHPgri2ghYPaBuihpFnSLECaJc0CAACANAuA vkaaBQAAAGkWIM06qQEDBsiwJf/SGAAAAAoy3dNC0ixAmnVckydPlmFrypQpNAYAAICCTPe0kDQL kGZJswVU3twTIjk5OTU11TVqLC0t7cmTJwW2wTjdobSnhbtS+ywI4wmAgtxDSbMAaZY0i4yb0Lp1 6z618K9//Ss7W2ndurUcR9eosTVr1pQrV861W8WmTZtiYmJc41DaM0i6Uvt0/NoGQA8lzQIMPaRZ 5G4Da9y4cZ06dQb9bMuWLUZr+Omnny5fvpzvacGeYuTICwtCmu3Tp8+cOXN068e5gp8UfkGhQNIs 58oASLOcYQOkWdJswUqzY8eOtWcNXbp0efvtt/M9LdhTjBx5YUFIsyb141zBTwrfqZA3aZZzZQCk Wc6wAdIsabagp9mbN292795dslzNmjWjoqJkzvTp00uVKiVzatSosWHDBpkTHx8/aNAgHx+f0qVL N2jQwDItTJs2zd/fv1mzZgcPHrTdYlhYWGRk5OjRo728vKpVq7Zu3Tpt/ty5c4cOHSpbuXfvnqxf 5sgy3t7e4eHhCQkJusWwLapu2ex84a1bt1555ZXy5cvLq6RadNOsVTl11xMdHR0SEiIzpR5u3Lih lcp2j0Tnzp1XrFihHi9fvlwKYFQhthWuu3VNt27dVq5cqR4PHz781VdfVY/37t3bs2dPtYn58+fr 1o89h3LevHktWrSoUKFC27ZttQV0y2l/4XWrTnemRhW+VKGilo1Tt6q1NHv37l15vGrVKpOSyBpk B81rgPEEAD2UNAuAvkaazXVG94SQNNuvX7/v02lfmpVwMnjwYElQCxcurFu3rsxJTExs167dsGHD 5Lw/KSlJLRMQELB58+bHjx+fPHlSSwvPPffcyJEjT5w4IfFA0pTtFmUZX1/f2bNnHzt2TBKOh4dH SkqKmu/p6Tlr1qyzZ8+mpqbK5oKDg0+le/nllzt06GBUDKui6pbNzhe2b98+NDT08uXLV69elZCp m2atyqm7Hgk/EkTT0tIuXbokZVAzdfdI1KlTR0VKMWfOnPr16xttyLbCdbeuGTdunEqw8hKpZzc3 N5XrpB4kpFmmO9v6sedQfv3110ePHpXlpQn17t3bqPJNZtpZdbozNarwvX/dSiu8UVWr/ZU1yEzZ WW0NuiWxpwYYTwDQQ0mzAOhrpNl8I2nWx8enRbqwsDCZc+HCBTkQa9eulSQQExMjESguLu7pLz+J qpbRvnJpmfT69u2rHi9ZssTPz083DY4fP149jo+Pl/UcOHBAzR8yZIiaf/HiRZmvrrM9Tb9VlTz9 8ccfdYthVVSjsmX4witXrshMSVxqGaNPGluW06iuWrZsqVKx9iqTPTJJs1Ybstopo61rdu/eXbp0 6SdPnmzdulUSXWBgoOyUBGNvb+/Tp08//eUnb20/aZzhodQsWrSoSpUq5uW0s/C2VWc00+jgmlS1 7NSkSZP69+/fqVMn9X8oJiXJVA0AAEizAGmWNEuazYc0a/VJ46ioKDkQTZs2bf6zffv2WQUGtcyR I0dsk56WjlasWOHr66ubBi2/u1ixYsXIyEir+Wr9sbGx6unVq1fl6Z49e3SLYVVUo7Jl+ELJfpYb NUmzVuW0rSvJXSEhIUWLFo2IiHj06JH5HpmkWasNWe2U0dY1ycnJZcuWlcWGDRv2l7/85Z133vn9 73+/d+/e2rVr227C5HuzRody/fr1QUFBL6WrXLmyeTntLLxt1RnNND+4ulUtO9WkSRN5Gh0dnWFJ 7KkBAABpFgB9jTTrQGn2/PnzciC2bdtmEhjUMosWLcpmmr1165asR3Kj1fzTp0/L/O+++0493bp1 qzw9d+6cbjGsimpUtgxfGBcXV7hwYXWh2M40a1RXiiQoT0/PBQsWmO+RpNm5c+eq+RMnTtRNs7o7 Zb51pWfPnnJ8/fz8JN3J1qtWrTpq1ChttdlJs2fPnpV4uX37dnm8bNkylWZNypmpwltWnflM28Kb VLXaKakBb29vKYB5SUizAECaBUBfI806WZoVwcHBbdq0UR/sfPDgwf379+XBmDFjZKa2jDyuW7fu 4cOH5fGZM2dSU1PtT7Nt27a9c+dOSkrKzJkzPTw81PotXytra9iwYb9+/eRPsmSvXr0aNWqUlpZm WwzdouqWzZ4XykbDwsISEhIOHToUGBiYYZo1Ws/evXuTk5OlwEFBQfPmzTPfox49evTt2zcpKWn5 8uVly5bVTbNGO6W7dUtLly6VdTZp0kQeyyZKliwpT48fP267Cav6yfBQRkdHS5q9ePFiXFxc//79 tbrSLaf9hbetOqOZliwLb1LVaqfksRxlCfbaB7N1S2JUAxLLpd0ydAAAaRYAfY00m0dM7gJlm2bl LL9jx45ubm4BAQFeXl7qU5oSgapXr+7v768ux127dk1O9+WQlS9f3s/PT7t1kD1ptlOnTi+88IL8 1dPTU7uGZhXezp49KyFEope7u7uEMXVtzbYYukXVLZs9L9y8eXOZMmVkpkSv+fPn25NmddcjG5LX VqlSpXPnzg8fPjTfo127dvn4+BQvXrxbt24zZswwSrO6O6W7dUuxsbGFCxfW0leHDh2k5nX3xap+ 7DmUUuASJUpUqlRp8eLFHh4e6kZQuuW0v/C6Vac78xfN+/jx58tX1ApvVNXaTkk2llXVq1dP4q5R SYxqICQkpFatWownDKoAPZQ0C4C+Rpp1iAamKzEx8fr161YzJZaoC2vK7du3VR6wn3Z9TFalrpiZ iI+P112/VTF0i6pbtgxfKDnHdlVZqKv76ezco5SUFDurUXendHc/a6zqJ0OyO2r5B+nMy2ln4XWr zqg+LVu4VeGNGk+mGjw4/QMcU9KtO67dQ0mzAGmWNAtHbEJWlxwB8hW1DSAL3XD7r8Njvz1AmuUM GyDNkmY5+8w7S5cujYqK4oiAfEVtA8hON5RpVZEma8q0jhk12/JSLWmWM2yANEua5ewToIWD2gYc Os1q06oiQdqlWtIsZ9gAaZY062q4awto4aC2AVdNs5aXarcHDTL5Vi1pljQLkGZJsy7ytsfExMTE xMTkktOV1TtJs5xhA6RZ0iwAAIBD/yf1ljp993cf922t3puqdT81cznXZjnDBkizpFkAAADHTbNr 3Fvt7TB6b6cxXz8bHN1z/PUdB9OSU1z4tJA0C5BmSbMAAABOf97oYhdjSbMAaZY0C0PctQW0cFDb gCudNxpdjHWNHkqaBUizpFkwXIMWDmobcEEmF2P5hR7OsAHSLGmWs0+AFg5qG6CHkmYB0NdIs7y3 AbRwahsAPZQ0C5BmSbPg7BOghVPbAEiznGEDpFnSrOvjri2ghYPaBuihpFnSLECaJc0CAACANAuA vkaaBQAAAGkWIM2SZgEAAECa5QwbIM2SZgEAAECaBUBfI83mB+7aAlo4qG2AHkqaJc0CpFnSrKs1 MIAWDmoboIeSZgGQZkmzvLcBtHBqGwA9lDQLMPSQZsF7G0ALp7YBkGY5wwZIs6RZGhhACwe1DdBD SbMMZwBpljTrHLhrS45IS0t78uQJ9UALp7apBIAeSpoFQF8jzeazdevWfZpux44djx8/pkLMrVmz ply5ctQDAACkWQD0NdJsPmvcuHG9evV69erl7+/v7u6+f/9+k4V/+umny5cvO+BeZLlgmX0haRYA ANIsAPoaadZR0uy4cePU45deeqlPnz4mC3fp0uXtt992wL3IcsEy+0LSLAAApFkA9DXSrMOlWYl2 Xbt2VY9v3rzZvXt3SW41a9aMioqSOdOnTy9VqpTMqVGjxoYNG2RO586dV6xYoZZfvnz5K6+8oh6H hYXNnTt36NChsvC9e/fk6bx586ZNm+bv79+sWbODBw/aFkOWiYyMHD16tJeXV7Vq1datW6e7qvj4 eJkjy3h7e4eHhyckJOgWzLbwQl47aNAgHx+f0qVLN2jQwP4X3rp1S3atfPny8qqxY8fqplmrcuqu Jzo6OiQkRGZKPdy4cUMrle0e2V+3tjtltBcAAJBmSbMAaZY065SM7gmh0qzkH8lOxYoV++abb9T8 tm3bDh48WPLSwoUL69atK3MSExPbtWs3bNgwWTgpKUnm1KlTZ/78+Wr5OXPm1K9fXz1u3bq1p6fn rFmzzp49m5qaKk+fe+65kSNHnjhxQlJWt27dbIshy/j6+s6ePfvYsWMSzzw8PFJSUmxXJQUIDg4+ le7ll1/u0KGDbsFsC69mBgQEbN68+fHjxydPnrT/he3btw8NDb18+fLVq1clZOqmWaty6q5HkrwE 0bS0tEuXLmlfUdbdI/vr1nanjPaiwLZwUNsAPZQ0S5oFSLOkWddsYJJmixcvXrhwYan87du3q5kX LlyQp2vXrpWIFRMT4+bmFhcX99Tmc7kmiWvIkCGWSa9v377q8ZIlS/z8/HTT4Pjx49Xj+Ph42fqB AwesVnXx4kWZry6iPk2/f5U8/fHHH60Kplt4NVMKabXdDF945coVmSlxUS1j9Eljy3Ia1V7Lli1V KtZeZbJH9tSt7k4Zbb2AD6GgtgF6KGmW4QwgzZJmXTDNjhkz5saNG1WqVBkxYoSaGRUVJceiadOm zX+2b9++TKVZOZqWSU97umLFCl9fX900aPmSihUrRkZGWs1XpYqNjVVPr169Kk/37NljVTDdwquZ R44cMUmzui/cvXu35UZN0qxVOW1rT3JsSEhI0aJFIyIiHj16ZL5H9tSt7k4ZbZ2zN1DbAD2UNMtw BpBmSbOulmbV92YlthUpUmTTpk3y+Pz583Istm3bZpL9VOKaO3euejxx4sScSrO3bt2SrUtutJp/ +vRpmf/dd9+pp1u3bpWn586dsyqYbuHVzEWLFpnske4L4+LiChcurC4U25lmjWpPkbDq6em5YMEC 8z2yp251d8p865y9gdoG6KGkWYYzgDRLmnW1NCtGjRolQUt9MDU4OLhNmzbqY7EPHjy4f/++PBgz ZozM1F7bo0ePvn37JiUlLV++vGzZstlMs23btr1z505KSsrMmTM9PDzUFi1fm5qa2rBhw379+smf ZMlevXo1atQoLS3NtmC6hZc5devWPXz4sDw+c+aMrM3OF8pGw8LCEhISDh06FBgYmGGaNVrP3r17 k5OTpcBBQUHz5s0z3yM761Z3p3S3LqFXKpazN1DbAD2UNMtwBpBmSbNOxvwuUOrxw4cPa9So0a5d OwlUkmk7duzo5uYWEBDg5eWlPv56/Pjx6tWr+/v7q2/Y7tq1y8fHp3jx4t26dZsxY0Y202ynTp1e eOEF+askau1ypdWqzp49K3lP0p27u3uTJk3UZUzbgukW/tq1a7I2aWPly5f38/NTt32y54WbN28u U6aMzJTcOH/+fHvSrO56ZEPy2ipVqnTu3Fmq2nyP7Kxb3Z3S3XpISEitWrUKYAsHtQ3QQ0mzpFmA NEuaLYgSExOvX79uNVMSlLoGKFJSUu7cuZP9DamQJilaVq4uTpqIj4/X3ahlwYwKf/v2bdvXZvjC 5ORk21Vlofbup7Nzj+yvW92d0t19AABIs6RZgDRLmnUpSbfu5G8BrC45AgAA0ixpFiDNkmZhKDnx 4bF3F671DM33BrZ06dKoqCiOCAAAIM0CpFnSLMzc2HV4Z4shq9yaStNSE3UCAABIswBIs6RZh6Pu CWF5MdZqoorgAi0c1DYA7gLFGTZAmiXNumADs7oYS5pFwRlCQW0D9NCCm2bNJ1oMkFNDTwHva6TZ 3BO75UCGDYyJiYmJiYnJZSbSLP8bB/D/aqRZl2pRZ+Z8ubnGa2srhq737cJ/TYIxE9Q2QA8lzQJg JCLNOlOLurEr5uCAqatLtthUrfvqZ1qQZsGYCWoboIcWlDTL9/6BvFEA+xppNi9bVNKtO1aXaqki MGaC2gbooS6eZgGANOtK1KVa0iwAACDNAgBp1vkk3bpDJQAAANIsAJBmAQAAQJoFQJoFAAAAaTab +N4/kDe4CxRoUQAtnNoGUDB7KL/QAzi3AtjXwsPDZdhq3br1ZOSCnoV8qATQwkFtA/RQp9CqVSs5 LRwwYABpFiDNOgc1bAEAAADqIgdpFiDNOofIyEgZswYMGDAFuaBnIR8qAbRwUNsAPdQpyAmhnBbK ySFpFiDNArQo0MJBbQP0UOfGXaAAp0FfAy0KoIVT2wDooTmZZgEAAAAAIM0CAAAAAECaBQAAAACQ ZgEAAAAAcIU0y/f+gbxBXwMtCqCFU9sA6KE5mWa5JzuQN+hroEUBtHBqGwA9lDQLMBKBFkWLAi0c 1DZADyXNAmAkAi0KoIVT2wDooaRZAPQ10KIAWji1DYAemrtplu/9wwF7LJNzTRxrpgLVbhmQC3jz oO/QzcEQx5RT/Y5f6IFrjixpaUeYnGXKZpqlApmcrt0yIBfw5sHARTcHQxxTTvU70iwYWZhIs0xM nOYyIJNmmejmYIgjzQKMLEykWSbaLUiz1AndHAxxTPmSZv/+978fPXpUe3rlypUvv/ySxgpGFibS LBMTp7l0UtIsxxGgOzt0mq1aterMmTO1p5s3b37++edprGBkYSLNMjFxmksnJc1yHAG6M2kWYGRh Is0ycZrLgEyaZaKbgyGOKa/SbHR0dEhISLly5fz9/W/cuKFm3rx5s3v37jKzZs2aUVFRamZYWNjc uXOHDh0q8+/du0dbByMLE2mWiXbLgEzzYOCim4Mhjinf0myzZs0ko6alpV26dOnx48dqZtu2bQcP HiyRdeHChXXr1lUzW7du7enpOWvWrLNnz6amptLWwcjCRJplot0yINM8GLjo5mCIY8q3NNuyZcvQ 0NDLly9rf71w4UKhQoXWrl176tSpmJgYNze3uLg4lWaHDBlCEwcjCxNplol2y4BM86BO6OZgiGPK ozRbo0aN9957T3u6ceNGybfqseTYkJCQokWLRkREPHr0SOZERUVJmm3atGnzn+3bt0+l2cmTJ9PE wcjCRJplot0yIOfU9OTJoZSUw6RZZ68fujkY4phyMc2+/PLLHTp00J4uXbpUMqrlAnv27PH09Fyw YIE8Pn/+vKTZbdu2Wa2ENAsHHFm+/HLWP//5d+3pjz9u+eKLmTneCWNjd3zyyR/i4nbkcedPTY2J jIyQB2vXzpYCfPbZFNlZmZnvo9Ly5VMTEvbkcZpVlSDT9u2LkpIOOtEgLodsw4bIKVOGDhv22qxZ o9as+fDOnb1O+oaktcmjR1flRl/L1LRxY+Thw184SLtlQJbqPX9+o3r8+PEP0lUvXtyk5bFPP/2j /Ktb7a1b/3ry5N9nmOg2b57/1lt9Z858KyrqU6dLs9l5E7GnfnKwm+TeSpziOALm3dlJT0Xyvevl QJqdMWOGu7v7oUOH5HFcXFybNm0mTJig/rR3797k5OS0tLSgoKB58+apmcHBwbKM+vjxgwcP7t+/ T5qFY44sVav6zJgxUnu6adO8559/Lsc74bvvvlGoUKFJk4bk+JqvXNly6dJmo7+OHz/wr3+dJg8a N65Tr171Dh2alytXplIlz3v39uXvsHjq1Dft2zczOjfNpTSrKqFXrxB/f29395L79i11ireQW7d2 BQc39vX1mjBh0IIF48eM6Ve7dsDOnZ84aZrV2uSf/zwqN/papqY+fUJnzx5rfxfL1XbLgNyy5UvS yNXj6OjlMmZOnz5CPd27d2mNGs9nJ6116tQiKKjOBx+M+e1vO/fs2dbp0mym3kSs3heymWbt6SYZ liFrK3HG4wiYd2cnPRXJ966XA2n24cOHvXr1kpG0atWqRYsWbdu2bUJCgvpT9erVy5UrV6VKlc6d O8tiaqYk3o4dO7q5uQUEBHh5ee3Zs4c0iwKbZuXc97nnKsipmJ+fV45/3KtLl5Zvv91f90+rV3/w m9/U10bPceMGyIOrV7eVKFFMXRzL3+mdd8KNSp57aVZVgkwvvVRTzq6c4i1kyJDuVar43Lix0+oK pzNGWcs26QhpNgtdLPfaLQOyJC7ppOrxrFmjihQpIudP6unEiW+MHNkny2n27Nn1srZr17Y76SeN M/smYtVos5lmc/y9KcuTUxxHIMM063SnIo7Q9XIgzSrx8fExMTGxsbFW8++ns10+MTHx+vXrtGk4 aZrdv39ZSEiTcuXK+Pt7X7/+nZopoaJ795dlZs2albXrY2FhnebMGTt0aE+Zf/eu9WXPb775qGLF 8gcPrihUqNC33y7Q5sfF7Xjlldbly5dt0KDmlClDGzWqbb4JiaBTpw6XwjRrFvj995/LzD/96c1S pZ6RJeUsZ/36uVbbldiwfPlUq9EzIWGPu3tJtbBVsW/d2iVzvLw8vL09wsO73L69W5bp1q3NihV/ UisZPrzXq6+2UY/37PlM/edclmtJBkcpyYMHB/IlzcqZVteurUxKq7tfulUkU+fOLT7//P9qadmy 9+Sw6u6yvHzQoFd8fCqWLl1KDrrJ1rVJNiFvIZ988gejy7a65dFtLUY7ZVJ4WYmkiEqVPBs2rHXm zDpZrHp1/xdfrLpxY2TWuoNlm7RMs7KhFi0aVKjwbNu2Qaq0UlEffvi29sI33+y1cOG7ukuaHCzb 2rYqmzydN2+c9qe5c98ZPfp1qc9q1fzWrp2t28Vyr90yIMuo4uZWRLUZaZYywsjwqP7jRs75ZHA2 anKS1iZNGmJ17KyuExYuXHjJkslW8zNswP37d9Jth1l4I8hOmjV6E9HtvLaNVqVZ2wHBZADR7SYS qmWdlpMKyba90rYMln0tswOXcx1HwP406yynIo7Q9XIszQIFKs3Ku6n0KzmXunhxk/bdBnm3Hjy4 m3Szjz+eULduNe1cytOz3MyZb8kZv+1/nHfs+Bs1ckle7dEj2PL/y9u0aSQnxzJCSUqU3mu+ieee qzByZJ/jx1fLECAhU2bev7+/Xbumw4a9JuPCo0ffW2703r19ct6jfYJFRs9+/TrKSCTDopzzPX78 g22xZVXBwY1PnvxappdfbtShQ3NZRkquEqzUgIdHWTnXVOOmbFTOObJTS3JiJGvbuvXjPE6zUlcy 3Bcr9quvv/7IpLS6+6VbRTLVqVNNO1GbPXts/fov6O6ybCggwFfamKzwxIk1JlvXpn/843M5jkeP rtLdI6Py6LYWo50yKby8U7733jBZuHnz+hISXn+9w+nT38i7kXYBLVPdwapNWqbZNWs+/Oc//y5t WFpp797tZM5nn02pUsVHJZmbN6Oeeaa4+tSi7ZImjdC2tq3KZnnNSh77+np99NH//OtfX8k7vbT2 5OTDtl0s99otA7IcqZIlS0j4kUMpOfaHH1ZKg5G2LSOkNAD1PwhGTc722FmtfMKEQXI2NmBAV2lO 2swMG/CSJZN022EW3giyk2aN3kR0O69tozUaEEwGEKNuIutU06JFE2UUVV+fs+2VumXQVpLZgcu5 jiNgT5p1rlMRR+h6pFkgK2m2ZcuXQkObWn7z5/z5jXJ29c03H8kIcvjwF3JSGxu7Q/XAIUO6667/ 8uVvZTGJrPL4k0/+8KtfFVX/uyZzZFUbNkRqn8BUadZkE337tlcLL148yc/Py/zTXDJCyXq0W4bI 6BkYWKNJk7oyUixb9p4aWSyLfeHCf7erXeBdu3a2PJXC79q1uHTpUpJ+t2z5WEZMWYkUVUYZyTmn Tn2TzVqSyje66phLabZ48WIyHKffpm6heWlt98uoiszfQrRdVhuy+uaY0da1SVqILHDlyhbb3TEp j1Frsd0p88IPH95L+7JrgwY11buLFEnekLLQHazapO4njRcufFfe+dTZcKlSz0jzk8cffvh2+/bN jJY0aYS239OzKptVmpXd1P7nW14eHb1ct4vlUrtlQJZJ/XebhNIXX6wqT318KkoD/utfp8l88yan e+xsb74iA5esU/2Xij0NWLcdZuGNIDtp1uhNxKTz2n7S2HZAMB9AjLqJmn74YWXJkiWWLp1i0iuN Pu2chYHLuY4jkGGadbpTEUfoenmXZpMTH8ZuOXD6g5XHJ38q/15ZvVPm0KbhyCNLjRrPT5ky1DI8 yKmqeizDh5xCFS3qFhER/vDhf/93eefOT9J/fape8+b11bR371LzbyXJ/GefLT1yZB+ZBg7sKi9/ //3R6jN18lj7EoKWZu3ZxOef/8nXN4M0K1FT1vPTT1utPtkiQ56kU7XLlutU29XKIy+Up7t3L3ny 5FDZsu7y12HDXlu0aOI774T//vc9pPC1awdkv5b8/b1tP7iSq2l2zJh+ciIo51sjRvS23HHb0hrt l20Vmb+FWNVwTMwv7upptHVtOnbsK1nAaqb5ITNpLbY7ZWfh3333jeDgxtq9SVWazWx3sGqTlml2 3bo5QUF1XnqppkyVK1dSM3/7287h4V3kQc2aldes+dBkSaODZVXbtmWzSrOWf6pYsfzcue/odrFc arcMyDLNmDGybt1qCxaMHzq0pzx97bUQGTZff73DBx+Msb/JacfOdrp9e3enTi2kAcs5lp1rs22H WXgjyE6aNXoTyVSatR0Q7BxAbJ/Km4ic0U6c+IY2R7dXGpUhCwOXcx1HIMM063SnIo7Q9fIizSbd unN88sI17i1lY5bTGvdWR8dGyl9p2XDMkcXyQxrq843SrywXkDHC07Pc/Pnj5fG5cxukB9p+yNCo ByYnH5b347fe6vvxxxPUFBraVPqz/Ok///mHDAfaf8stXPiuSrP2bMKeNPvgwYEiRYqoAc7qexoy eqosarlOlTR27PiLerply8fyVF0N6Nmz7dixv/Xz85LRUxaQtD9q1OtW+5uFWkpKOigl/O67T/L+ e7O7di2WTasvfxqV1na/TKpI3kLmzBmr3a5G9y1EbUh9Y0SbzLcu06NH33t4lP3d77obhUPd8pif FFrulJ2F102zme0OVm1SS7NnzqyTt2rVF5YunaKdDcsbXqlSz2zaNE9OndVthI2WNGqEVrVtf5q9 efO/v5q+evUHtl0s99otA7JM33//eeHChaWxrVw5XZ5Ky6xe3b9ChWePH19tZ5OzPHZGlzrVt0/t bMC27TCzLT87adbkTcSk89qTZu0cQKye3r27Tzbau3c77UZ0Rr3SqAxZHric5TgCT+373qwTnYo4 QtfL9TR7Y9fhDb4dVHz9tmbXmBERxydPPTp24tb6PVYVbSIz11ZoF7vlAI0bDjiyTJ8+wt295A8/ rFQ/6NemTSPtJyL27PlMOp68ZwcF1dFuAiynWbKM+tRHYmK0+qkbox4og5Sch1n+npi6jYf6Xyh5 s5exZsWKP02aNETGIFnSzk1Yvs2PGdNPFjb6UuXixZMsR0/ZnZMnv65Vq4q6O6jlOlNSDjdsWKtf v46yuYSEPb16hTRqVFudr0jCL1vWvUmTuipclSxZQp4eO/ZVNmtJSlK+fFmjH1vL7btASSCX9wb1 4Rbd0trul0kV9egR3Ldve6mcZcvek8rRfQuRSbZSt261Q4f+Jo///e+16oO7ulu3+vCem1uRDz98 W30VUF61YUOkerlReYxai+7Bsqfwumk2s93Bqk1KmlUfSty/f5mcDV+4sFEOR//+HbUvkEs5Je5W rFhe65JGS+rul25tm6fZtm2DpCalnmfMGOnhUVbtjlUXy712y4CswluZMqW0T9err85aphqjJqd7 7CyPmpw4qvsFyIAmrUj9sK09Ddi2HWah5Wc5zZq/iRh1XqtGqzsg2DmAWD6VXiZZumnTetonO0x6 pVEZsjBwOddxBJ7afRcoZzkVcYSul7tpVqLsGvcWsg3JrglH1ltt++6pb3c06S1/XVW06bWN+2jf cLSR5T//+YeMBem/PuUj/VNOibS7w1Wv7i9vzHLC3blzC1lM+wn7jh1/I+kiIMDXy8tD93NZ2tS1 a6uxY39rNTMwsIb60IWsKiysk6RE6eFLlkz29/e2cxOWb/OSKqWc8lrtMq82bd++qEGDmup/wmT0 LJSuWjW/4cN7qU97WhX7zJl1MibKCCjxXkql/qtPpmvXthcuXFj7dnGHDs1feKGy9qos19Lgwd2m TXszv36hR4pao8bzEq5knNUtre5+GVVRVNSnPj4Vixcv1q1bm+nTRxi9hVy9uk3myFGQOOTn56Vu jqK7datJmoecoEuGlJqXQy9Fkncgk/IYtRbdnbKn8EZpNlPdwapNSjvUbuMkmy5RolilSp6ffvpH 2VNt/h//+Dtpe+pd02RJ3f3SrW3zNNupUwtVw3J6of3Pt1UXy712y4CsXdPTru9JUylZsoTUufZX oybXp0+o7bGz/LqXrKd06VJyKGUc+NvfZmSqAdu2w8y2/CynWfM3EaPOa9VojQYEewYQy6fqpnRS k88+W1pNqhi6vdKkDJkduJzrOAL2p1lnORVxhK6Xi2k26daddd7tZANHRo9PfWL4G2jyV3WF9lFc PE0cjjayqBuHHD78he1Pad27t8/2Wpn6Xrt2M5scmV5/vUNoaNMsb0LGJt1bL86bN+6jj/4nUyWR qkhI2JOpl2Shlg4c+Gu/fh1z6XTB/FgbTbalNdov3SpKTj5sZ73Fx+u83J7DfeXKlpMnv7b9pdlM HTLdnbK/8HZWnck0a9aogQNf+eqr9+VN9IsvZlruhWrDiYnRMpk3UdsljQ6Wbm2b/GapVK/0JttK Vl0sV9stA3KWm9zdu/uSkg4aHTvt4yfnzm3Q/b3ELI/nmX1hlu9pbDKZdF6j94Xsj/l29krzMmRt u45/HIHsDHEOeyqS710vF9PssT8sUFdlkx/+YF6I7b9+TZY8OjaSJg5nPHnKjUlO6yMiwleunP7G G6+WKvWM7fWEHJkkNjjgL3GvXz/X6ieF8j3NMuXNdPHiJn9/765dW3355Sz1sSUHmTK8IJPb7ZYB 2eWn3EizTI52HAG6syP0O3vTbHLiQ3XbJ9sPGNtOd099u6po0zXurZ7cuU8rByOLugHA1KnDBw7s OmHCINubrzJs8S7ClJfTZ59Nsf3JeE5zOdUjzTLRzcEQ57Jp9trGfbLqLXW62VmO7b/uJctfWb2T Vg5GFibSLBPtlgGZ5sHARTcHQxxTvqXZ0x+slFXHjIiwsxxHx06U5eVVtHIwsjCRZplotwzINA8G Lro5GOKY8i3NHp/8qaz6+OSpdpZDlkxf/lNaORhZmEizTLRbBmSaBwMX3RwMcUxOdG32j1ybBSML E2mWiXbLgEzzoE7o5mCIY3K678325XuzYGRhIs0y0W4ZkGke1AndHAxxTPmcZtPvadzK7nsab+Ge xmBkYSLNMtFuQZqlTujmYIhjyv80+/S/vzf7F/V7s6lPMviF7h1N+vN7s8jfkYXJuSaONVOBarcM yAW8edB36OZgiGPKqX6XiTSbdOvOOu8OsoEjo8ebBNojoyfJMmsrtHsUF08TBwAAAADkhkKZWvrG rhj1eeOt9XvYfuT47qkt6qrsqqJNr23cR+UCAAAAABwizapAu7ZCO3UVeEud7vt7Dt3Zqv8/er+5 /dd9V5f4jboqS5QFAAAAADhWmn2a/pHjY3/4i7pIaznJnKNjI/mAMQAAAADAEdOskpz48NrGfbtC RkqO3d1u5JXVO7mDMQAAAADA0dOscnzyp5JmT0xZTFUCAAAAAEizAAAAAACQZgEAAAAApFnSLAAA AACANAsAAAAAQE6k2Ru7YiSpZjjtbDVU0mxU66H2LHxzdww1DgAAAADIxTSrLrrm7MQlXAAAAABA 7qbZm7tjJHxmOEW1Vtdmh9mzMNdmAQAAAAC5m2btxPdmAQAAAACkWQAAAAAASLMAAAAAANIsaRYA AAAAQJoFAAAAAIA0CwAAAAAgzZJmAQAAAACkWQAAAAAASLMAAAAAANIsaRYAAAAAQJoFAAAAAIA0 CwAAAAAAaRYAAAAAQJolzQIAAAAASLMAAAAAAJBmAQAAAACk2f93aPj7kmYPv/kBVQkAAAAAcI40 m/IwafUzLSXNyr/ymNoEAAAAADh6mk1LTd3fLUKi7N+LNJF/5bHMoUIBAAAAAA6dZv85Zo6E2G/K BV/bvF/+lccyhwoFAAAAADhumj07/yuJr18Va35zd4w8lX/lscyR+dQpAAAAAMAR0+y1DXtXpX+6 +PLKLdrMyyu+lTmr3JrIX6lWAAAAAIBjpdmEw6fXlGolwfXktM+s/nRi6hKZL3+VZahZAAAAAICj pNkHl+PWeXeQyHpw4FTdBQ4OmCp/lWX+82MclQsAAAAAyP80++Ru4pbafSSs7mo7IvVJsu4yMn9X 8JuyjCwpy1O/AAAAAID8TLP2x9T/D73BbxqFXgAAAAAA8iLNqo8Qr3+uoz0fIZZl/u8DyQOmUsUA AAAAgPxJs1m4vZN2syh5LbUMAAAAAMjrNPv/P72zcV+mVv3fH/JxS/8hnxXfUtEAAAAAgLxLszd2 xXxVrLkk0rMLVmdh7WfnfyWvlTXc3B1DXQMAAAAA8iLN3jt96ZtywRJH/zlmTpY3IK+VNch6ZG1U NwAAAAAgd9PsoxsJG6u8KkF0f/dxaampWd6AvHZ/twhZj6xN1kmNAwAAAAByMc1G93pXIuiOoIEp D5OyuQ1Zw/bGA2Vtsk5qHAAAAACQi2n20Y0ECZ85dTU1Z9cGAAAAACDNAgAAAADgZP4XQZl+a636 7EcAAAAASUVORK5CYII= --00c09fa21bcdfaf6a3048cdd0a05 Content-Type: image/png; name="native.png" Content-Disposition: attachment; filename="native.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gcdrsxhc2 iVBORw0KGgoAAAANSUhEUgAABKcAAAQuCAIAAACGXck6AAAANXRFWHRjb3B5bGVmdABHZW5lcmF0 ZWQgYnkgaHR0cDovL3BsYW50dW1sLnNvdXJjZWZvcmdlLm5ldDpnVRsAAAJaelRYdHBsYW50dW1s AAB4nK1UwW7aQBC9+ytGXAoHU0MTUFFVJbGo2ig0kQ1t1Uu1rCfCwva6u2OI+vWdtU0CxhBV6mUt eWbevDdvNFeGhKYiTRwhSWlYGNROzr9iGeciI+gEaFShJYKvMlOkqKH7VVC8QbjO814HhIHAPyiZ PhHqTCQ3Wm2bcNN0iVGEUVusc13QSun4D8OrDELUG9RlAxv4eYLWXloQOpY/uB+Z0gTmYo3AsiwY rQSBxt9FrLHCe2lEylaKhOB7TCvAmiIsK47QzRMUBiFS2Rvil8Fi03MC3zZqCJrAfY5ZRRgWwZ3T iNuSMlgntqV8cHcpD0wWWW0FF2c810chsVLJaUfNzxa0sd0VSI0Rf2ORGBBZBKKeEJ4RsKst+Ldr imUaE/HYHpVOIRIkzggLMGIjJNnZ+yJJlkKuy1nwUNt0+SKnQiPIvdySJz6RFiXOGrN+7UnL9F7c 9lWEdZtnMozNnkmJxsDcIjmYsOHVOtTbvFuHne+HS37s+2G81fdGyj/43mz+qu+nCs74flLA676f FHbge2FIpTyJLxDKFaZoEewtqXegSTlAifbsPGNsrT0t5mIW/b9FSJTKa7QgnMAnJLmCXCtiBixa 787Q9u1+Wb8GtiU16nFNv2R6xY+9v85DwodtMbsDPmfGErz0RuNuyHfrtkhgMIbBxeTSmwwH4E/D OQy9gddzbsVGdOezHoRTCAo2ksc4zTaxVlnKkss4fFYU5orKvNGFexNTfTXh28wZ9Ed979fQc5fe 0B2O37sDb/bOG106MyHhPoQffwFNMhsmJ5gmxQAAgABJREFUeNrs3Ql8TXf+/3GSFCW2ELEkIQlp OrW3BK3WEkntDRoyGK1Rg9YSYyg6tPws/+mCUEwomabTVi2xRBVt7MaW1q+22vdEiCBREln8P+M7 Pb879557cxNJ3Hvzej7Ow+Pek3O/95zvds7b3Uo9BAAAAAA4rlJFVG5W+r3ETXtPfPjFkalR8u+l lT/IGqobAAAAAOw+9WXcuHVk6sJVri9/Xaql4bLK9ZXD4+bJX6l0AAAAALDX1Je87dB6z84q5n0b 0CPhnfFHpk47PG7yd017r3BpJStjqwcnbtpLvQMAAACA/aU+iXyrXNtKtJOMl/rjutzcHw2X28e/ 3dqqr/x1hUvrqxt2UfUAAAAAYE+pL+PGrbU1gyXU/Tjm3ZwHh4win7bIX9UrfveTUqh9AAAAALCb 1PfzewvUq3xZ9w6Yi3xq2fLC67Ll4XHzqH0AAAAAsI/Ul5V+T319i+kbO02X28e/XeHSepXrKw9u pdEAAAAAAGAHqe/qhl0S+TY1DM0z8v32cl+YbH9p5Q80AAAAAADYQeo78eEXkuIS3hlvZeo7PG6y bC+PogEAAAAAwA5S35GpUZLijkydZmXqky0fbR9FAwAAAACAHaS+/L/W91de6wMAAAAAu0l9+f9c Xzif6wMAAAAAu0l9j77D8xWrv8NzE9/hCQAAAAD2lPoe/vv3+har3+uz8BPtatnaagC/1wcAAAAA dpb6Mm7cWluzs8S5H8e8ayH4/ThmimwTWz34flIKtQ8AAAAAdpP6RPK2BPU+z++a9jZ9q+ft45vU q3wrXFpf3bCLqgcAAAAAO0t9KvjFVg+WaPfoy1167e4z7IdXBvyr79tbXghfWe4l9SofkQ8AAAAA 7DX1PXz0Vs+f31usXvQzXGTN4XHzeGMnAAAAANh36lOy0u9d3bBrW6eRkve2B4+8tPIHvrETAAAA ABwn9SlHpkZJ6jv6/hIqGgAAAABIfQAAAAAAUh8AAAAAgNQHAAAAACD1AQAAAACpT0/ytgRJdHku P7wyTFJffLth1mx8fXsC7QEAAAAANpH61It4hbvwkiAAAAAA2Erqu749QUJankt8O/Va33BrNua1 PgAAAACwldRnJT7XBwAAAACkPgAAAAAAqQ8AAAAAQOoDAAAAAJD6AAAAAIDUR+oDAAAAAFIfqQ8A AAAASH2kPgAAAAAg9QEAAAAASH0AAAAAAFIfAAAAAIDUBwAAAACkPlIfAAAAAJD6SH0AAAAAQOoD AAAAAJD6AAAAAAD2kfoOjvibpL5Db39IRQMAAACAo6W+7HsZK59+WVKf/Cu3qWsAAAAAcJzUl5uT szt0vES+r51ayb9yW9ZQ3QAAAADgIKnvp4g5EvbWVO14deNu+VduyxqqGwAAAAAcIfWdmv+NxLxv yrx4fXuC3JV/5baskfXUOB7Hv189ZmGxsYWByYi2oz5J5TBjMBWwPJEOTNU98eYo/NR3df3OFY/e 1Xnhi03aygsx38qaFc6t5K/MbnicKSM390cWFttZuIZjRNtXn6TOmTGYClieSAemlZ94cxRy6ks9 dGJVhVdkJ45N/8zoT0enLZX18lfZhgkOTBksnALBiCb10TqgW5L6WOwv9d29kLS2ZmfZg/1vTtPd YP8b0+Svss2vF5OY48CUwcI1HCOaLkTqo3VAtyT1sdhT6ntwO33Tc/3k6bcFvZPzIEt3G1m/rePb so1sKdszzYEpg4VrOEY0C6mP1mEqoG+Q+ljsI/VZH+f+Lxx2fNtcOASYMli4hmNEs5D6mDGYClhI fSy2lfrUWzfX1epizVs3ZZv/vBH0jWnMdGDKYOEajhHNQuqjdZgKWEh9LLae+grwNS3al77IY5ns wJTBwjUcI5qF1EfrMBWwkPpYbDf1/d9PMmzYla8H/vsHHpwf/cBDzLfMd2DKYOEajhHNQupjxmAq YCH1sdhi6kve9tvPry9YWYCHG/2YO8CUwcI1HCPa1pYHDw5mZx8i9RV6/eTkJGRmHrB+fb4KYcZg KrDT8UvqY7HF1HfnxPk1VTvK8/0UMafAhchjpQQpR0pj1kOBp4zY2E/+/vf3ZNmyZVFGxn47GrFy ybJ+/bz33x82fPjrs2ePXrXqo1u3dtrp7CPHMm/eeNUcP/zwd8M/bdgw78SJNdYXJdsfOvTl4+9S YuJW6RVJSVsLXEJ09LTU1B1cwz2pEa2Ww4dXPMGO3a7dC1On/slwxz777P2ffvpaOrwjpb4C17lh /eRrWbnyw6pVK1m/Ps9CHKB1mAoKfSYvcP8sxJNRYZ3RJMFu3Dh/1KjwWbNGxcdHOUzqs9NLOHts jgKmvvvJqRt8XpMn291rQm5OToF7gDx2d+h4KUdKkzKZ+FCwKaNly4aNGzcIC+vk7V3T1bX8rl3L 7GLKuHFjW8eOLT09PSZOHLxgwbsREf2fe87PKC/Z0fLuu2/+4x/TVXM8/XTZ06fXa3965ZXno6L+ auGxly5tOn9+o3a3X7+QTz4Z9/i7NGnSH0uVKjVlytACl3D8+JpXX20jkzvXcMU8ohs2rD94cE+1 fPvtAus7T5GmPjXVdO78oiSN2rXd79zZ5TCpL191bpupzwFah6ng8WdyownhMVNfwU5GRXRG69q1 bWBgww8/jPjDH7r16RPkMKnPTi/h7LE5Cpj69oRNkmfaGvhm9r2MxxzqUsKWlm9KaVImEx8KPGVM mPCGut28eYDMsHYxZQwd2svHp05y8g9Gr5jZY+STa6+XXmqqNYezs5Oca7VjyTP1de/+8tixAwr9 /+Fq1aru71/Xy8vjcd7h85e/DLKwb1zDFdGIHjfuD1Y2UFF0HgupT001V65sLleujHpx22FSn/V1 brOpz95bh6ng8WdyownhMVNfwZaimJROnVrn5OR09eoWx3uHpz1ewtlpcxT8tT4JaYX16lzhloYS nvpktu3R4xV1WwJVr14d5JogIKCe9hra7t3LO3VqJSu9vWteu/a99rLbwIFdPTyq1axZbdCg7jdv blfru3Vr+/nn/6NuL1/+Qc+e7dRt2XjOnHHDhvWRcm7f3iUPHzy4Z506NSpWrNCsWYCFZ9cWeQqZ Mv7+9/fMvQyouz+yUi5lpk0bITvfpk2Tffs+t3BQFnZeCpk8+Y+1a7s///yzJ0+ulc0aNPD+3e98 N2yYZ2HnjY7acIcl8kVHT9Oa489/Huji4rxo0WTT1CdP3bZts+rVqwQFBar9/5//ebtChaelTDmv r1s3Vz1RZOQEuSG1+tFHY7VnefvtsIULJ+VZt2pZs+bjGjXc9u+PKVWqlOELF1L43Ll/GTPm91K9 9et7xcZ+Ynm9TO6uruXv3t3LNdwTTH3Sq1944XfLlr2v7m7cOD84uHVm5gHTzmNN1zU3jkw7p7nU l5q6Q3qF1l2NZgPTwRsa2j4m5j+DccSIsNdea69u79jxmfpPYt0hnN9hWOipz5q5QupnypShpgNH d+evX4+XicjNrbLMk/J0WmAztz5fhThA6zAVWD+T657gTCcENX5NB7uFk6zRXKFORhI+pUzDRU0L +TqjFeDkbvj6YenSpZcunWq0Ps9+OGBAV+tPo0XagR3pEs5Om6MUcw0cJvXJmJHhXabMU6tXf6zW yyw8ZEioDJVPP53YqFF9tVLmUxlFOTkJ587Fae8glyvIjh1bHju2WpYOHVp07vyiWt+wYX1tsv7k k3FNmz6jXei4u1edNWuUXAZlZx+SJ/Lz84yLi5QCjx5dZeHZteVf//pczmHmPjxjbn/keWvVqj5y ZL8jR1bKBCEXKxYOysLOy8z4wQfDZeMXX2wqF2q//33nEyfWyOwjNWlh542OWtvbO3d2ybFo78qQ Qr74YsakSX+sVKmCzIxGqW/Vqo9++unr+/f39e/fpW/fYFmTlrZbjnf48NelBWW94XX2Z5+97+NT R71mKJd6Tz9dVr1txnLdqqVLl5fUiaRFi+d69+5o+F+/np4eH3/85//9329koq9WrXJW1iEL6+Vk 7+zs9N13n5L6inNEd+3a9p//nCmLBDy18ptv/iYdQDqPnKElhKjPUZh2Hmu6rrlxZNo5TVOf/EnO 9HLZITlHfY+IUeG6g1e6osoSMjyla0mPUtclsudynWduCOdrGD5+6jOtc2vmCnMDR3fnX321TUhI axnFly9/JxdkWmAztz5fhThA6zAVWD+T657gdM8muoPdwknWaK7Qhr+UqZZFiybLlYaagvJ1RivA yd1wmThxsCSNN97oIWdDbWWe/XDp0inWn0aLtAM70iWcnTYHqQ8Oco1YtmwZGX6SPTZvXqhWnjmz Qe6uWfOxzAKHDn0pJ/LExH9/Fvzll5urKwbt4WfP/ntL9X9y6oPFcvfChW8tTxlDh/YyfCKjd+2b e3ZtWb9+nmygQpHRYmF/5HnDw19V65csmeLl5aFumx6U5Z0fMSJM+zBes2YBajaRXZIJyMLOGx61 4SKzpGyvfdRepT452/3ud75yHWnuHZ4LF06Suc/ye3Lk9FmhwtPbti2R2x99NFau9qypW1mkumT9 qVPr5Pbf//7eU0+5aP8pKIXLUWv/QShF7dkTbWG9LL6+dcy9Kss1XBGN6Oee8xs0qLsskyb9UVsv l/ISPHr0eEVu6L6Zysqua24c6XZOo9TXpIl/q1aN5Ey8fPkH6sxtWLi5wSt9uGLFCpJDNm36VK5I pJCVKz+UcSeZ6vjxNbpDOL/D8PFTn2md5zlXmBs4ujt/8eImWSmXVkZvzjS3Pl+FOEbrMBVYP5Ob O8GZnk1MB7vlk6zRXGH0BtEDB74oX76c9r6DfJ3RCnByN/3iE+mWderUUP/Nak0/zNdptEg7sCNd wtlpc5D64CDXiBER/eVkIHPuO+/0VSt/+OHvMopat2784otN1bJz57+HpUwWnTq1cnFxHj9+0L17 +7QttfdnX778ndzdvn2p5SlDOxOohyck/Nc3dJl7dm35+edvZAOjlYaP1d0fw+f9/PP/8fT8z4nB 9KCs3Hm5vOvYsaX2PWPqSs7czpv7gIRcGMn2sp+GqU+9nunk5BQT8z+GqW/t2jmBgQ2bNw+QpV69 2nl+EuMPf+gml6FyIyCg3qpVH1lTt7LIw6tUqThyZD9Z3nyzh2z/t7+N0T2L16jhNnfuXyysl8Xb u6bpGzm4hivSEa37GbM7d3bJ9Za07K+//ks39VnZdc2NI93OqfsOT7mkkJzw/vvDdGcD08H74MHB ypVd5a/Dh7++aNHkv/xl0J/+1HvHjs8kaJkbwvkdhkXxDs885wpzA0d35+VCx7BytMBmbn2+CnGM 1mEqsH4mtz71mQ52K0+ypnela8lV/uTJ//dfUfk6oxXg5G663Ly5vWvXtjIAJT9Y2Q+tP40WaQd2 pEs4O22OfKe+r7/++vDhw9rdS5cuffXVV0xYeOLXiOpkLxcEEjPUB05On14vo8jcG/NkRnB3rzp/ /rtaaNm6dbH606ZNn8pd9Z+LMmXMmfOf/wGSiV53ylBPpN6ZrS2Wn12W+/f3VatW+a23epkLUbr7 Y/nEYHhQVu687pWcuZ03NwHdvbtXql1NsoapTxY581WvXkUunlTqO3lyrUzW6j/zli1735rUJ7Nh hQpPx8VFyrlWfZdmnnWblXVIambUqPBPP52olpCQ1jK9mhZ+/Xq8FCUXjhbWZ2Tsl6P7/vu/cw33 xFPfsGF95PwqueL//b/RuqnPyq6rO47MdU7d1CeLXJ2oVGC4gYXB26dPkByUl5eHXJ3IBr6+dUaP /r3RgDIcwvkdhraQ+rSBo7vziYlbS5curb2ErgU2c+vzVYhjtA5TgfUzubkTnDWpz8qTrNHd27d3 yZP27RusfVFZfs9oBT65m74Eqj7laGU/tP40+qRSn91dwtlpc+Q79fn6+s6aNUu7u3Hjxrp16zJh wUZSnyxyqpa5QL04Ltco7du3UO8ESE/fo77Ie8eOz2SYyawdGNhQfclbdvah559/tn//LrJBauqO sLBOLVo8p6b13r07hoe/Kglt+fIPKld21Z0yZJFnadSo/sGD/5Tbv/wSq94EpfvsRm8IcXZ2+uij sepjMPKo9evnqYeb2x9zJwbTg7Jy581dyenuvIUJKDi49ZIlU0xT36+//qt+fS+ZzlTq2717uZwj z57dIA00YEAX7XItIqK/PJ3uTCcHVbduLbnQnzhxsLaB5bqVA5GoafizP+qbALT/PAsKCpSKlWqf OXOkZG/t6HTXHzu22s2tsrkfEeIarthS3zff/E2uxeXCS87uZco8pf0vg1Hnsabr6o4jc53TNPXJ WJNe8eyzPiNH9jPawMLg/eyz92UYtmrVSP2nT/ny5eTuzz9/Y2EI53cYPqnUpztwdHdeKmfgwK43 b24/cOCLJk38tUo2tz5fhThA6zAVWD+TmzvBWTibaIPdypOs4V3pAJI5W7durL2bpgBntAKc3LVF erWEIvVpVemu8rxnzmywsh9afxp9sqnPji7h7LQ5SH1wtNQnMcPfv66EEBlXMnF06fKSJCs/P08P j2rqMrFBA2+Zmn186nTr1lZ7n9jJk2tlmpBJwdW1vJz41f8SyRIfH1WnTo2yZcuEhrafMeMdc1PG lSubZY2cjSQeeHl5qA9w6z670bJ06VS5SJLrp2eeqSezvOySzDgW9sfciUH3oKzZeXNXcro7b2EC 2rJlUbNmAep/rQxTn/o/udKlS2vv8JSdKVeuTO3a7rJGjl19/F2uruQQvL1rqv80NXqiv/71LSlB TakWdk9bevR4xfT6Va4O1XsqpPCuXduqCpezi/YfhObWDxkSOn3621zDFfOIltFU+jedOrWS6ypp FLnmUxtMmzaiZs1q6srAqPNY03XNjSPdzmmU+ko9Ur++14gRYepdzUaFmxu8V69ukWORXKTudu78 onQ27VG6Qzi/w/AxU59RnVuf+vr1CzEdOLo7HxcXWalSBVkp11iRkRO0q2Rz6/NViAO0DlOB9TO5 uROchbOJ4WC35iRreFd9AZt6h7la1G7k94yW35O74UfI5NkrVqwgJUtX/+c/Z+arH1p5Gn3iqc9e LuHstDkKM/Xt2bOnU6dOVatWlZ6enJysVl6/fr1Xr16yMiAgID4+Xq0cOHDg3Llzhw0bJuvv3LnD fIfHnDIsL2lpu7UvGtE+HaT7A743bmxLTd1h+iYT05W6S0qKzsNNn133F12PHVtt+kt9uvtjbtE9 KOt33sqqs7DI5dfHH//Zyp+nV/+Xlp6+RxbDmTdfP6yXr90zOotLbcvTGda57vq9e//Rv38XruFs akTrLkadp2B9w0LnLEA5+R165ual/B5LwVJfgZfbt3dlZOw3HVDmdv7Bg4O6h2Nufb4KsffWYSrI 12LhBGfl2aQAPaFQzmgFe14p7fTp9bq/EVfgGa84O7CDXcLZY3MUZupr06aNZLnc3Nzz589nZmaq lUFBQUOGDJFot3DhwkaNGqmV7dq1c3d3nz179qlTp3JycpjvUPzXiCxFsXzzzd9sfyfN/eeZ7vp1 6+aq//bjGo4RbS9LMac+Fn6lnamADkwrO+avtFtIfS+//HJISMiFCxe0v549e7ZUqVKxsbHHjx9P SEhwdnZOSkpSqW/o0KFMc2DKYCn+5bPP3tf9YXdz67mGY0ST+lhIfUwFLKS+Epf6/P39P/jgA+3u hg0bJAeq25L3OnXq5OLiMn78+Pv378ua+Pj4R19F2vrF3+zatUulvqlTpzLNgSmDhWs4RjQLqY/W YSqgb5D6WGwu9XXo0KFz587a3WXLlkmWM9xgx44d7u7uCxYskNtnzpx59JOLm40KIfWBKYOFUyAY 0aQ+Wgd0S1Ifi42mvpkzZ7q6uh48eFBuJyUltW/ffuLEiepPO3fuzMrKys3NDQwMjIyMVCs7duwo 26i3fd69ezctLY3UB6YMFk6BYEST+mgd0C1JfSy2m/ru3bsXFhZWqlQpX19fFxeXoKCg1NRU9acG DRpUrVrVx8enW7dusplaKcmwS5cuzs7Ofn5+Hh4eO3bsIPWBKYOFUyAY0aQ+Wgd0S1Ifi+2mPiUl JSUhISExMdFofdojptunp6dfu3aNeQ2cGFg4BYIRTeqjdUC3JPWx2EfqAzgxsLBwDceIJvWxMGMw FdCBaWVS378dmRrFdIZCPDGwsNjawsBkRNtRn6RymDGYClieSAem6p54c5QqhpHMdAbY4CmWSgAY MjQEQF9FCWk4Uh/ApAaAIUNDAPRVkPqoO4BJDWDIgIYA6Ks0HKmPTg8wqQEMGdAQAH2VhitxqY9v cwFsEAMTYMjQEAB9FSWn4fjlBgAAAABwZKQ+AAAAACD1AQAAAABIfQAAAACAEpf6+DArYIMYmABD hoYA6KsoOQ3HLzcAJREDE2DI0BAAfRUlp+FIfQCTGgCGDA0B0FdB6qPuACY1gCEDGgKgr9JwpD46 PcCkBjBkQEMA9FUarsSlPj7MCtggBibAkKEhAPoqSk7D8csNAAAAAODISH0AAAAAQOp70rKysnJy chyguh3mQKguAAAAgNRnyZdffhml5+7du7rbt2vXburUqcW5h3FxcQkJCYVebPEfyBM/5KSkJGnZ a9euFX91FcoRFVG1WGPt2rVqXGzdujUzM9MwDH/77bejRo2aPXv2tm3bmMUAAADwhFOf7mcix40b N/iRhg0buru7D/5NamrqkwpLly9fvnDhgna3X79+c+bMKfRi83UgRo8taoV1yEYmTZpUqlSpKVOm FHV1FdYRFU9PsEbLli0bN24cFhbm7e3t6uq6e/dutb5r166BgYEfffTRH/7whz59+hTiwATAkKEh APoqDUfqKwjL3386duzYVq1a5VlIMaS+7t27y84UdbH5OpAi2qXilJWVVatWLX9/fy8vL2veq/k4 1WVfPcHK1DdhwgR1u3nz5pI/5cbp06ednJwSExOLdGACYMjQEAB9lYYj9RVh6ouMjGzbtm316tWD goL2799vdPV/+/Ztub1ixQq1/vr167169apatWpAQEB8fLxp+bqlpaSkDB48uE6dOhUrVmzWrJms mTFjRoUKFaQcySfr16+XNQMHDpw/f762vdz18PCoWbPmoEGDtBckZaWUP336dG9v7zZt2mjla0yL VQdi+hDT/TR9rCF56rlz5w4bNkw2uHPnjm493Lhxo2fPnm5ubnKM77//fosWLdT6bt26xcTEqNvR 0dGyjVamdsjWlL9nz55OnTrJSjmW5ORk3faNjY2tUaPGgQMHSpUqtWnTJm297j5YX10WWsRwt7Uj kvDp/9+kQqys9iLqCeaKMpf6JDT26NHj4aPXDEuXLv3ZZ58xqQFcB9AQAH0VNJy9pr7Vq1cfPnw4 IyOjf//+ffv2NUx9mZmZHTp0GD58uLaxXKwPGTJEru8XLlzYqFEj0/J1S5NH+fn5bdy4UQo8duyY rElPTw8ODpaSJd7Ixg//+1Um+VPHjh2PPyI70LlzZ22vatWqNXLkyKNHj0ooCg0NNXp23WJ1H2K6 n6aPNSTluLu7z549+9SpUzk5Obr18Oqrr4aEhFy4cOHKlSuSsiRyqPUNGzbUYsycOXOaNm1qFK2t LF/ijUSs3Nzc8+fPG37qzFCXLl1UbpHM2bt3b2297j5YX10WWsRwtw2P6PpvFi9eXKZMGfVxOGuq vYh6grmiTFOfPEQSsuzzmjVr1PqJEydK8HvjjTck2DOpAVwH0BAAfRU0nP2lPs2iRYt8fHy0q+op U6YMGDCga9eu2dnZauXZs2dLlSoVGxsr180JCQnOzs5JSUnmnkgrTT3K9JNa5t5beO7cOdlee7Vt 7dq1cvfixYtqm/DwcLV+6dKlXl5eps9rWqzlhxgetYX3BEo5Q4cOtVAPly5dkpWSbNU2q1atym/q s1y+rH/55ZdVqjRX51JLsvHp06fldlRU1FNPPaW9JGhuH6ypLsstou32Q703iB48eLB8+fLLly+3 vtqLoidYKMoo9ZUtW1YCnvx1y5Ythn+Sh9SsWbNOnTrah/2Y1ACuA2gIgL4KGu6JpT7Ln4k0TX3r 1q0LDAxs/ki9evW0K2/ZTK599+zZo20ZHx8va1q3bv3ib3bt2mVUvmlp6lE//vijlalPba99jOrK lStyd8eOHUahIiYmxtPT05rUp/sQ3aO2nPq0cnTrYfv27Ya7XYDUZ7l8WS95r1OnTi4uLuPHj79/ /77pTkoJVapUGfnIm2++KYV8+OGH+U19ptVlZYuY3pVYJUlp8uTJljtbMfQEC0UZpb6IiAiJypJI 33nnHaO/pqamdu3a9emnn05PTy/0gQmAIUNDAPRVGo7UV2iMUt+pU6ckRaiXNZYvX26Y+uSqevTo 0XLVfubMGbVSbsi18ubNm80VrluaetSiRYusjGcnTpyQ7b///nu1/rvvvpO76vWrwkp95o7aytSn Ww9JSUmlS5feu3evbuqbO3euui0RKM/UZ7meJau4u7svWLDAaH12drYc3ahRoxb+JiQkJCAgwPI+ WFNdVraI0d07d+7Ik/bt2zc3N9dyZyuGnmChKKPUp94fKxneyckpLi7OaAPJsUYfmAQAAABsPfXt 2bNHLsTPnTsnoWXAgAFaUFFX1XK9PnDgQF9fX+2dnB07dmzfvr16k+Hdu3fT0tIMCzdXmjykUaNG hw4dktsnT55U3y0ZEREh602v9eWvzz//fP/+/aXwW7duhYWFtWjRQiUHa671zRVr+BBz+2n0WHOp z1w9yG5LdaWmph48eLBJkyZasb179w4PD8/IyIiOjq5cuXKeqc9c+Tt37szKypKqCAwMjIyMNNpD iSjVq1c3/Lyf+k4X9TqhuX2wprqsbBHDu7Kfkjlbt25t+JqkldVeFD3BQlG6qU+MHj1a0rXs6vHj xyUEPnjwQFYuW7ZMDuHs2bNMZAAAALCb1CdCQ0PLlStXu3btJUuWVKtWTX3HhuHle7du3Ro3bizX yg8fvaLVpUsXZ2dnPz8/Dw8P0/fI6ZZ29epVKVASiJubm5eXl/p2jSNHjjRo0MDb21u9+GN4HX/q 1Cm5KJdw4urqKnurvSZjzbW+hWINH6K7n0aPtZD6dOth48aNlSpVkpUScefPn6+lmm3bttWpU6ds 2bLypDNnzrQm9emWL/smZfr4+EiL3Lt3z2gPe/ToMW7cOKOVEj4HDRpkYR+srC5rWsTw7r59+6S5 y5cvX+U3ajesqfYi6gnmijKX+qSG/f39g4ODY2Nj5UAqVqwopckGX375JbMYAAAAbDr16UpJSVGv v919JM/t09PTr127lt/Sbt68qaKjIQmE5n5WTsox3d5KForNcz+teay5epCQrNYYvsPz4aO3Xxbg WEzLT3ukYHViYR+sPOTHaZHHqfZC7AkFK0pKOHPmzOP/ZB8AAABIfYWDD7PaAqPUh5Ig48YtBibA uYyGAOiroOEePvFfbkDxOHbs2KxZs6iHEkWG3pYXBiV+u5eBCXAuoyEA+ipKeMOR+gCHnbZkWeHU alWldgmjPzF66Y+BCXAuoyEA+ipIfdQd4AipT1tWOAUavvTHwAQ4l9EQAH0VpD7qDnCo1Gf00h8D E+BcRkMA9FWQ+or20pOFheWJL5dW/sDkDliJL2agIQD6Kg1H6gNgi/9ZZbhsahi+u9eEb5/tG1e/ 1/FZ0Za/4RMAAACkPgD2kfpWub6ys/OYnV0jVlfpuKfPu9e27s/NyqZyAAAASH0AHCH18eIeAAAA SH2AI6c+XtwDAABAcaQ+PswKPBGWX9xjYAKcy2gIgL6KktNw/HIDUBIxMAGGDA0B0FdRchqO1Acw qQFgyNAQAH0VpD7qDmBSAxgyoCEA+ioNR+qj0wNMagBDBjQEQF+l4Upc6uPDrIANYmACDBkaAqCv ouQ0HL/cAAAAAACOjNQHAAAAAKQ+AAAAAACpDwAAAABg06lvzpw5rxS2F+r6v1JcBg0aNBWAFYa/ 0p1KABgyNARAXy0UchEul+Lz5s2z92hUUr7NRVqrFAAAAADkU7t27ew9GpWUX2544403VJu9ZG+0 rvY+ACv0KVWHSgAYMjQEQF8tFHIRLpfiEiVIffaR+qZOnSoNNmHChFR7I/ssey77z3t2gRI+qQEM GRoCoK8WMxUiJP7RcKQ+Uh/ApAYwZEBDgL5K6qPhSH2kPqBYOPCHlQGGDA0B0FdJfTRcMaW+ESNG 9OjRIzEx0WZT3wcffDBx4sRvv/02zy23bt36yy+/mK6Xh69bt65w2yO/ZcqOyUNOnDiR50orH1tE x1Uojh49Wlj1VmBW1q2h3bt3y0MuXrxYROVbqAFzXVccP348NzdX3d6+ffvER3JycjhPAwCAEpv6 HFhRpb5nn31Wirp06VLxpL7hw4fnN/VVqlTpD3/4w759+1566aXnn39erXzjjTfKlSv34MEDuT1v 3rxXX31VroylZAmx2gN//fVX+dd0/eMrQJlxcXHykA0bNuS50srHFsVxFYr33nvv448/Lqx6KzAr 69bQP/7xD3nI2bNnDftPYZVvoTdarpbo6GgZNer24cOHZTPZOCsrizkRAACQ+kh9BUl9vXv3Llu2 7KFDh4oo8sk1q/oOz/ymvs8++0zFCWdn5zt37sjtBg0aSDkHDhyQ2z179vzwww/lRnJyclpamnpU 7dq1+/btS+orZvPnz/fx8bl37549pr6tW7eWLl06MzPTsP8USvl59kbDrmskOzu7SZMm2pBZt24d qQ8AAJD6SH36xowZ8/zzz1esWPGFF16YMWOGaeqbOXPm008/Lbfr1as3atSoQo98R48erVu3rpTf tGnTy5cvFyD1yUW5PHzjxo1yiSy7Khfo8+bNk2viypUr//jjj3I97evrO2XKFJUPnZycKlSoIIes rrOHDh36xz/+sXr16m+99ZbpU6xcudLf318q57XXXrt9+7Yqavr06X369HFzcxs2bNjBgwcbNWpU v379+Ph47dpdCgwLC/Pw8PjLX/6isqhRObJm+fLlnp6eUud/+tOftJCgu9LKxxolKKN9UHsuHUP2 PDg4WDZbv3697Hn58uUbNmwYGxsraz799FNpdJVt2rdvr9LIlStXnnvuuQcPHvzjH/+QZ5TtJVer NxbqVo7hUxhq3rz5J598onZPbWa0e4aZx6hk2aXu3bt7eXnJUUt7qWfPc3+MdkC30kwrQe3exIkT DXvFL7/8EhgYaNR/Cla+oTx7o2HX1T3kzz//3Nvbm9QHAABIfaS+PIwcOXLRokU//PDDSy+9JNeg P/30k1Hq279/v1z3y225at++fXvRRb4bN27k68i11Pfrr78+9dRTkh/WrFnToUOH3/3ud/369ZPd rlatWk5OjmGiuHnzpkTBbt26SbxU6+UaetasWYMGDZLbR44cMSxfipUr8vHjx586dUrC5LRp09RD 5HkXLlz46quvqh8Y/OKLL1xdXcPDw7XEVaVKlcWLF0tClttLliwxLefevXtyQ6LRsWPHBg4cqEKC 7korH2ua+oz2Qa2UB06aNGnTpk0nTpyQGuvZs+f58+d79+7t4uLy888//+tf/5JtpCecPn1abpQt W1aeXfpG165d5YYc9e9//3u5IRVroXK0pzDcJal26Vrfffed5d1TbWRasmTOr7/+OiUlZdWqVbLZ 999/b83+GO6AbqXpVoLlXmHYfwpWvlG1WO6NRtVidMhHpkYdOnRINjhz5gypD8gTXyJCQwD01ZKQ +vg2lzxcvHgxIiJCHhsZGWn6Ds9XXnlFbhf6OzwPHz6sIl+9evXyG/kMU59o06ZNy5Ytx44dKzUw ZMgQKXbmzJlyqf3Q5L1zVatWNXxPnVxhP3z0mozcjouLMyz/n//8p6yU0v7617/WqFGjS5cu6iHy LPJXCS1y+/jx43K7RYsW7du318ocNmyY3L5//75c9Ms+mJazceNGWbNy5cqHBm8I1F1p5WNNU5/R PqiVb775ptrm448/lrvqi3DUK6WzZ8/Ozs6Wyhk3bpzEe0l6slLCmzyjBD/ZrHHjxpLcpNgrV65Y qBztKQxt2bJF/qS+lcTC7qk2Mi1ZVko/lPVvvfWW/MnK/THcAd1K062EPHuF1n8KVr7RAy33RqOu a3TIX5dqKaNGNvjyyy9JfUCe+MEAGgKgr5aE1McvN+i7efOmbNywYcOyZcvKBag8dt68ecWT+iTy +fn5qch3/vz5Ahy5YeqbOHGii4vLc8899/333y9btkyKlYNauHBhnqlPrVdX6kbX93/7299k5Z// /Odlj2hX4ZMnT5a/RkVFyW2154GBgYapT5UpkaZMmTKSgkzLkdwia9RrX1pI0F1p5WNNU5/RPhhV gsQP9bLew0dfUCm3p0+fLrfDwsKk3uRYJEJIZf7pT38qV66cel3r119/lYlAau/pp58+duyYucrR /WxeUlKS9nR57p5pyVevXpUnlUQknVNLfXnuj+EO6FaabiXk2St0U5/15VtOfUbPa1SlRocsk9r/ /u//ygbqm1FJfQAXcDQEQF8l9ZH69MXExMj2/fv3l+vyjz76yHLq279/f1FEvtOnTxfsyA1Tn1xw S2kS/O7evXvixAn13TAnT540TX2NGzdu2rRpZmZmntf3P/30k5OTU48ePa5cuZKWliZX2FamvrZt 2yYmJsq+ye1Vq1aZlnPmzBn5U2ho6IEDB9q1a6dCgu5KKx9rmvqM9sGoEuSxpUuXHjJkSEZGxujR o+VPe/bskfVqe1dXVwkYY8aMeeqpp6SuZL08texJTk6OqqjVq1ebqxxz38giGfLTTz+1ZvdMS1Yv mklVf/HFF3Ljvffes2Z/DJ9dt9J0KyHPXqH1n4KVb1Qtlnuj4UrTQ5ZJbcWKFTVr1lRFkfoALuBo CIC+Suoj9elTL4tJ6pNLxlatWqm3L6akpBilPlmpXkj55ZdfCvGzfAEBAQX4WTPd1Jeeni6Rr0WL FipXuLm5eXp6GqYgLY1ER0dXq1atbNmy9+7ds3x9//DRV3TIxnLtXqZMmddee83K1NetWzdVmcHB wep7+Y3KkTWTJk2S/ZeVUpqW3HRXWvlYo9RntA+mkUwyWMWKFZ9++mn5V6K+WimRSTZTb49UdSIR S26fPXu2Ro0alStXlort27ev+lE43coxl/qmTZvWsGHDBw8eqM2kpaTSzO2eUcmSqerVq6fefSrH JVk0ISEhz/0x2gHdSjOthDxTn9Z/7t+/X4DyjVjujYY7Y9oEX5Vq+eKLL44aNYrUB3ABR0MA9FVS H6nPkqSkpLZt28qFsru7+4wZM1xdXeXhO3bsMEp9hw4dat68uWwmQeIJfn2LaeobNmzY4cOH8/vA 7OzsW7duWb/9tWvX1A8A5ovpUxiVI2nH9De1dVda+Vhr9sGQlCDFWv+73rdv387IyChY5UiAGTp0 6Pz58w2TjOXdMyxZHqX96oP0ooLtj26l5bcSLPSfgpWfr95oeMh/6/3W66+/rmLeiRMnJBKT+gAL +BIRGgKgr5aE1Me3uVhy+vRp9fqehEALr+bJZrJBYX19ixT1mEceERExfPjw1atXMzHZBUluBw4c sNkfkbc7CQkJWsbbvHnz8EfyFV8BAAAcLPU5sP9Kfeo731XwszVySar27XE+ywcHcOHChZs3b1IP AAAApD4UJPWpr12xZZ6engX7xk4AAAAApD5S339e62vXrt1UW0XkAwAAAEh9KHjqK4oG44PXgA1i YAIMGRoCoK+S+kpOwxV56uNLlgEbxMAEGDI0BEBfJfWVnIYj9QGcjQAwZGgIgL5K6isxqU99ru+N N96g7gDORgAYMjQEQF+1RlGECBquCFOf+g7Pdu3aUXcAZyMADBkaAqCvWqMoQgQNZ2epjw9eAzaI gQkwZGgIgL5K6is5DVfKIRsMAAAAAKkPpD4AAAAApD5SHwAAAACQ+kh9AAAAAEh9KKGpjw9eAzaI gQkwZGgIgL5K6is5Dfdfqe+NN97g9/qAkoCBCTBkaAiAvlpYiiJE0HBFmPqmTp0qDfb+++9TdwBn IwAMGRoCoK9aoyhCBA1H6gPAwPyPrKysnJwcGhQMGRoCoK+S+mg4Uh8Aawdmbm7umjVrJk6cOG7c uC+//PLBgwdFvTNJSUlRUVHXrl0rwGPbtWsnE5fRyvv370eZSExMNK6Er78+fPiwdvfSpUtfffWV ur127Vr1qK1bt2ZmZmrbyPp9+/bRfxgyoCEA+iqpj9T3X/jgNWCDzA3M1NTUoKAgf3//adOmzZo1 q1mzZi+88MLly5eLdGcmTZokM8+UKVOs2Vh25sKFC5ZTX1pa2mADzZs3l/ITEhKMNvP19ZVj1O5u 3Lixbt266nbLli0bN24cFhbm7e3t6uq6e/dubb2EYfoPQwY0BEBfdcjUV1K+zcVhGgxAwbz99tv1 6tW7ffu2unv//n1Jfa+99lrRPWNWVlatWrUkZ3p5eVnzXs3u3buPHTvWcuozyrF16tQZMGCA6Z8s p74JEyao2xIa+/XrR+oDAMDhU58DI/UB+I9bt265uLiMHDnScOXs2bNlWvjll1/k9sCBA+fNmzdm zBgPD4/69euvXbtWbXP9+vVevXpVrVo1ICAgPj5erZSNIyMjp0+f7u3t3aZNm/379+s+aWxsbI0a NQ4cOCDPsmnTJm19t27dYmJi1O3o6OiePXvKjRkzZlSoUEGeSFLi+vXrtdRn4VnCw8MlT8qhFTj1 Sc7s0aMHqQ8AAFIfqQ+A3du3b5/MABs2bDBc+dNPP8nK1atXq4jl6en5ySef/Pzzz4MHD65WrVp2 drasDwoKGjJkyJ07dxYuXNioUSP1QNm4Vq1akiGPHj0qmTA0NFT3Sbt06aLyVYsWLXr37q2tb9iw 4fz589XtOXPmNG3aVG6kp6cHBwcPHz5ccmZGRkaez7JixYrSpUtv3bpV96nzTH3yLJI8y5Qps2bN GlIfAACkPlIfALsneU97WU+TlZUlwWnx4sUqYr377rtqfUpKimy8d+/es2fPyo3Y2Njjx48nJCQ4 OzsnJSWpjcPDw9XGS5cu9fLyMn3GixcvyvanT5+W21FRUU899VRycrKF1PdQ7x2e5p4lMTHRzc3N 6KVL61Nf2bJl5cDl0LZs2aJtQ+oDAIDUR+rTwQevARukOzCPHTsmM4CkL8OVly9f1pKP0YfoatSo MW/evPj4eNmgdevWL/5m165dRhvHxMR4enrqniSqVKky8pE333xTyvnwww/zm/rMPUvnzp2feeaZ e/fumasEf3//Dz74wDD0Sg7U0l1ERIREUB8fn3feeYfUB85lNARAXy0JqY9vcyk4vmQZsEG6A/PB gwe1a9d+/fXXDVcuWLDA1dU1JSXFKGLduHFDpotVq1adOXNGbmzevNmotDxTX3Z2tqwcNWrUwt+E hIQEBARoqW/u3Lnq9uTJk/Ob+hYvXuzi4nLgwAELldChQwdJhtrdZcuWSWTV0p163+n27dudnJzi 4uJIfQwZKoGGAOirDp/6+OUG6g4oEWejzz//vHz58t999526u2/fPnd395kzZ2oRKygo6NatWxLY Zs2aVa1atbS0NFnfsWPH9u3bqx9UuHv3rlqZZ+qTKFW9enXDX8NT3+miXirs3bt3eHh4RkZGdHR0 5cqVtdQXEREhz2U59UkQrVChgmx524D6CKIhOS4JtAcPHnz46DcDpdiJEycapT4xevRoqQT1tlVS H0MGNARAXyX1kfro9IDdT2qSndzc3Hx8fOrXr1+pUqV58+bl5uZqEatr167PPPOMhCsJQt9//71a L4moS5cuzs7Ofn5+Hh4eO3bssCb19ejRwzRBNWnSZNCgQXJj27ZtderUKVu2bGhoqMQzLfUdOXKk QYMG3t7epm861Z4lKiqqlInt27cbPde9e/fCwsLkT76+vi4uLhJoU1NTTVOfbObv7x8cHCz1IOtl +9K/0V4bBBdwoCEAUh+pj9QHwJ4mNYk3Z86cOX36tNEP6KmIJX+9evWqFgU16enp165dK8SdzM7O 1v3FBSE7YM2P+1kjJSUlISEhMTGRXgHOZbYg48YtGgJMGqQ+Gs7+Uh8fvAZsUMEGZp4/iQ4wZPD4 l1xbXhiU+O1eGgJMGqQ+Gs6eUh8Ah7Fs2TLtR9gBoIhSnywrnFqtqtQuYfQnll/6A0DqA6kPAADY ZerTlhVOgRZe+gNA6gOpDwAA2Hfq46U/gNQHUh+AwryuYmFhYbH95dLKH5jDAVIfbC718cFrwAYx MAGGjF38n9SmhuG7e0349tm+cfV7HZ8V/dNfIqkiMGmQ+mg4W0x9fMkyYJvXVVQCwJCx2dS3yvWV nZ3H7OwasbpKxz193r22dX9uVjYNASYNUh8NR+oDwMAEGDKOUNWGL+4ZfZCPhgCTBqmPhiP1AWBg AgwZu69qwxf3aAgwaZD6aDhSHwAGJsCQcSiWv6WThgCTBqmPhrPR1Mcn4AEbxMAEGDI0BEBfJfWV nIbjlxsAAAAAkPocGakPAAAAAKmP1AcAAAAApD5SHwAAAABSH0pc6uOD14ANYmACDBkaAqCvkvpK TsPxyw1AScTABBgyNARAXyX1lZyGI/UBnI0AMGRoCIC+Suoj9VF3AGcjgCEDGgKgr5L6SH10eoBJ DWDIgIYASH00XIlLfXzwGrBBDEyAIUNDAPRVUl/JaTh+uQEAAAAAqc+RkfoAAAAAkPpIfQAAAABA 6iP1AQAAPBG5ublr1qyZOHHiuHHjvvzyywcPHhTdc3399deHDx/W7l66dOmrr75St9euXRv1yNat WzMzM7VtZP2+fftoJpD64LCpjw9eAzaIgQkwZBypIVJTU4OCgvz9/adNmzZr1qxmzZq98MILly9f LqLd8PX1lWfR7m7cuLFu3brqdsuWLRs3bhwWFubt7e3q6rp7925tvcRRWpC+Suqj4Rw29fEly4AN YmACDBlHaoi33367Xr16t2/fVnfv378vqe+11157IqlvwoQJ6nbz5s379etH6qOvkvpoOFIfACY1 gCGDx2qIW7duubi4jBw50nDl7Nmz5ZLml19+kdsDBw6cN2/emDFjPDw86tevv3btWrXN9evXe/Xq VbVq1YCAgPj4eLVSNo6MjJw+fbq3t3ebNm32799f4NTXvXv3Hj16kProq6Q+Go7UB4BJDWDI4LEa Yt++fXL1smHDBsOVP/30k6xcvXq13G7Xrp2np+cnn3zy888/Dx48uFq1atnZ2bI+KChoyJAhd+7c WbhwYaNGjdQDZeNatWpJhjx69KhkwtDQ0AKkPsmTMTExZcqUWbNmDamPvkrqo+FIfQCY1ACGDB6r ISTvaS/rabKyskqXLr148WIV5N599121PiUlRTbeu3fv2bNn5UZsbOzx48cTEhKcnZ2TkpLUxuHh 4WrjpUuXenl55Tf1lS1bVp5aCt+yZYu2DamPvkrqo+EcPPXxCXjABjEwAYaMwzTEsWPH5OolKuq/ /nT58mUtd0mQkysc7U81atSYN29efHy8bNC6desXf7Nr1y6jjWNiYjw9PU2f0d/f/4MPPjCMnZID tXQXERGRnJzs4+PzzjvvkProq6Q+Gq6kpD4AAICi8+DBg9q1a7/++uuGKxcsWODq6pqSkmIU5G7c uCGXOqtWrTpz5ozc2Lx5s1Fp1qS+Dh06dO7cWbu7bNkyCY1aulOf69u+fbuTk1NcXBypD6Q+kPoA AAAe1+eff16+fPnvvvtO3d23b5+7u/vMmTO1IBcUFHTr1q3s7OxZs2ZVq1YtLS1N1nfs2LF9+/YX LlyQ23fv3lUrrUl9UrJEyoMHD8rtpKQkKWTixIlGqU+MHj1adkO9cZTUB1IfSH0AAACPRRKam5ub j49P/fr1K1WqNG/evNzcXC31de3a9ZlnnpEIJzHs+++/V+slj3Xp0sXZ2dnPz8/Dw2PHjh1Wpr57 9+6FhYXJJZOvr6+Li4tEytTUVNPUJ5v5+/sHBwfLnsh62b70b7TXBgFSH0h9AAAA1pJwdebMmdOn T+fk5BiuV0FO/nr16lUtCmrS09OvXbtWgKdLSUlJSEhITEyk5gFCBKmPT8ADtoiBCTBkSk5DGH2b C1AoMm7cYtJwvNTHt7kUHN92DdggBibAkCk5DbFs2TLtR9iBQuyNW14YlPjtXiaNh/xyA6mPMyXA pAYwZEBDwCF7oywrnFqtqtQuYfQnRi/9kfqYZEh9AJjUAIYMaAg4QurTlhVOgYYv/ZH6mGRIfQCY 1ACGDGgIOFTqM3rpj9THJFPiUh+fgAdsEAMTYMg4zHU2C4ttLpdW/kDqY7YvQakPAAAAcOz/g9jU MHx3rwnfPts3rn6v47OiLX/DJ6kPpD4AAADAPlLfKtdXdnYes7NrxOoqHff0effa1v25WdklsDYI EaQ+AAAAwAFTX0l+cY/UR+oDAAAAHD/1leQX90h9pD5jfAIesEEMTIAhQ0MAj8Pyi3slra/ybS6k Pr5kGbBFDEyAIUNDAPRVUl/JaThSH8DZCABDhoYA6KukPlIfdQdwNgIYMqAhAPoqqY/UR6cHmNQA hgxoCIDUR8OVuNTHB68BG8TABBgyNARAXyX1lZyG45cbAAAAAJD6HBmpDwAAAACpj9QHAAAAAKQ+ Uh8AAAAAUh9KXOrjg9eADWJgAgwZGgKgr5L6Sk7D8csNQEnEwAQYMjQEQF8l9ZWchiP1AZyNADBk aAiAvkrqI/VRdwBnI4AhAxoCoK+S+kh9dHqASQ1gyICGKCxZWVk5OTk2uGPJycmpqal0SPoqqY/U 93/44DVggxiYAEPGkRpi7dq1UVFRS5YsWb169blz52xqn5OSkmTfrl27VoDHtmvXTq7NjFbev38/ ykRiYqLRZnFxcQkJCYV+OJmZmcHBwX5+fp6enidOnKBPMmk4WOrj21wAAABsVMuWLRs3bhwWFubr 6+vk5BQbG1tsT3358uULFy5Y2GDSpElycTVlypQClKab+tLS0gYbaN68uZRvGvD69es3Z86cx9x5 U1u2bKlbty5dDo6a+hwYqQ8AANh96pswYYK63aFDh5CQkGJ76u7du48dO9bcX7OysmrVquXv7+/l 5WXNezWNStNNfYZSU1Pr1KkzYMCAoth5cxf37du3p8uB1EfqAwAAeGKpb8SIEd7e3nJj4MCBc+fO HTZsWNWqVe/cuXP9+vVevXrJ7YCAgPj4eLXxnj17OnXqJCvlIcnJyWql7pZSWmRk5PTp02XLNm3a 7N+/X1bOmDGjQoUKsqXkuvXr15vuWGxsbI0aNQ4cOCDXV5s2bdLWd+vWLSYmRt2Ojo7u2bOnbmkq 9Rk9qaHw8HDJk7du3TJ9atnh+fPn52vnzR24Vo0ff/yxm5tb+fLl5SFLliyRv0qxbdu2rV69elBQ kLZ7KSkpgwcPljhasWLFZs2aWahVkPpA6gMAAMhf6jt9+nSlSpXeeustFZnc3d1nz5596tSpnJwc iSVDhgyR+Ldw4cJGjRqpB0oEkkiTm5t7/vz5zMxMtVJ3SymtVq1aI0eOPHr0qKSX0NBQWZmenh4c HDx8+HCJNBkZGaY71qVLF7VjLVq06N27t7a+YcOGWiSbM2dO06ZNdUvTfVLNihUrSpcuvXXrVt06 MXyd0MqdN3fgWjXKQyIiIl566SV5yL179+Svq1evPnz4sDy8f//+ffv21SrQz89v48aNUqXHjh2z UKsg9cFxUh+fgAdsEAMTYMg4UkNI6vP19X322WclBUm4SktLU3Fl6NChaoOzZ8/KFU5sbOzx48cT EhKcnZ2TkpJk/csvvxwSEmL42TZzW0pp4eHhapulS5d6eXmp2xbeJHnx4kV5uARRuR0VFfXUU09p Lyfqpr6Heu/w1H1SkZiY6ObmJkHOXF0Zpb48d97CgWvVKN57770OHTqYPt2iRYt8fHy0cow+Umiu cCYNUh8N5zipj2+7BmwQAxNgyDhSQ0jq69Onz86dOw2/ytIw9sTHx8sVTuvWrV/8za5du2S95L1O nTq5uLiMHz/+/v37FrY0LC0mJsbT0zPP1CfbV6lSZeQjb775phT74Ycf5jf16T6p6Ny58zPPPKNe cLMm9eW589YcuGnqW7duXWBgYPNH6tWrp5Xz448/Gu6MucKZNEh9NBypDwCTGsCQgbWpT/tcn27s OXPmjFzhbN68WffhO3bscHd3X7BggYUt85v6srOzZZtRo0Yt/E1ISEhAQICW+ubOnatuT548Ob+p b/HixZJUDxw4YKGu8pv6rDlwo9R36tQp2Y0tW7bI7eXLl6vUp8pZtGiRYSGW659Jg9RHw5H6ADCp AQwZPG7qEx07dmzfvr16M+fdu3fVu0B37tyZlZWVm5sbGBgYGRlpYUtzwSkiIkL3Oy3j4uKqV6+u fVZQqO90Ua9x9e7dOzw8PCMjIzo6unLlylrqMypN90klQVWoUEG2vG1AQmYBUp/R0+V54Eapb8+e PZL6zp07l5SUNGDAgKpVq6r1UkijRo0OHTokt0+ePKm+vFS3cCYNUh8NR+oDwKQGMGRQaKlPkkmX Ll2cnZ39/Pw8PDx27NghKxs0aCBZxcfHp1u3btq7JXW3NBecjhw5IoV4e3url7w0PXr0GDdunNEu NWnSZNCgQXJj27ZtderUKVu2bGho6MyZM7XUZ1Sa7pNGRUWVMrF9+/YCpD6jp8vzwB+avMNT9r9c uXK1a9desmRJtWrV1Be6XL16VR4le+Xm5ubl5aW+Kka3cCYNUh8N5zipj0/AAzaIgQkwZByvITJu 3MqzhPT09GvXrhmuSXvEmi0tkJxjzc/xGcrOztb9xYWClfY4jJ4uXwf+8NHvNKiH331EW3/z5k3T A8xv4UwapD4azm5SHwAAQNHJSr/386SFse4hvCQLkPpA6gMAAA4leduhH9oOXeHcWvKeWqgTgNQH Uh8AALB7hi/uGS1UDkDqA6kPAADYMdMX90h9AKkPNpH6+AQ8YIMYmABDxu4kbtprLuyxsNjgQupj ti9ZqY//eANsEAMTYMjYaUOcnPPVRv/XY2uErPPszmt9YNIg9dFwpD4ADEyAIeOYDZG8LWH/G9NW lm8bV7/XyqfbkvrApEHqo+FIfQAYmABDxgEbIuPGLaOX/qgiMGmQ+mg4Uh8ABibAkHHAhlAv/dFM YNIg9dFwTyz18Ql4wAYxMAGGjOM1RMaNW1QRmDRIfTTck0l9AAAAAEh9IPUBAAAAIPWB1AcAAACA 1AdSHwAAAABSH4ov9fEJeMAGMTABhgwNAdBXSX0lp+H45QagJGJgAgwZGgKgr5L6Sk7DkfoAzkYA GDI0BEBfJfWR+qg7gLMRwJABDQHQV0l9pD46PcCkBjBkQEMApD4arsSlPj54DdggBibAkKEhAPoq qa/kNBy/3AAAAACA1OfISH0AAAAASH2kPgAAAAAg9ZH6ILKysnJycmxwx5KTk1NTU2kgAAAAkPpI fcX0bS5r166NiopasmTJ6tWrz507Z1OVkpSUJPt27dq1Ajy2Xbt2Uo1GK+/fvx9lIjEx0WizuLi4 hISEQj+czMzM4OBgPz8/T0/PEydO0OnxkG9EABgyNARAXyX1laSGe2K/3NCyZcvGjRuHhYX5+vo6 OTnFxsYW2zFfvnz5woULFjaYNGmS1MOUKVMKUJpu6ktLSxtsoHnz5lK+acDr16/fnDlzHnPnTW3Z sqVu3brMv7BmYAJgyNAQAH21xKY+frmhSFLfhAkT1O0OHTqEhIQU2zF379597Nix5v6alZVVq1Yt f39/Ly8va96raVSabuozlJqaWqdOnQEDBhTFzpsbh+3bt2f+BVdOAEOGhgDoq6Q+Ut8TS30jRozw 9vaWGwMHDpw7d+6wYcOqVq16586d69ev9+rVS24HBATEx8erjffs2dOpUydZKQ9JTk5WK3W3lNIi IyOnT58uW7Zp02b//v2ycsaMGRUqVJAtJdetX7/edMdiY2Nr1Khx4MABqYpNmzZp67t16xYTE6Nu R0dH9+zZU7c0lfqMntRQeHi45Mlbt26ZPrXs8Pz58/O18+YOXKvGjz/+2M3NrXz58vKQJUuWyF+l 2LZt21avXj0oKEjbvZSUlMGDB0scrVixYrNmzSzUKjgbAQwZ0BAAfZXUR+rLX+o7ffp0pUqV3nrr LRWZ3N3dZ8+eferUqZycHIklQ4YMkfi3cOHCRo0aqQdKBJJIk5ube/78+czMTLVSd0sprVatWiNH jjx69Kikl9DQUFmZnp4eHBw8fPhwiTQZGRmmO9alSxe1Yy1atOjdu7e2vmHDhlokmzNnTtOmTXVL 031SzYoVK0qXLr1161bdOjF8ndDKnTd34Fo1ykMiIiJeeukleci9e/fkr6tXrz58+LA8vH///n37 9tUq0M/Pb+PGjVKlx44ds1Cr4GwEMGRAQwD0VVIfqe+/mPtMpKQ+X1/fZ599VlKQhKu0tDQVV4YO Hao2OHv2rOxMbGzs8ePHExISnJ2dk5KSZP3LL78cEhJi+Nk2c1tKaeHh4WqbpUuXenl5qdsW3iR5 8eJFebgEUbkdFRX11FNPaS8n6qa+h3rv8NR9UpGYmOjm5iZBzlxdGaW+PHfewoFr1Sjee++9Dh06 mD7dokWLfHx8tHKMPlJornA4Br4RAWDI0BAAfZXUV3Ia7on9coOkvj59+uzcudPwqywNY098fLzs TOvWrV/8za5du2S95L1OnTq5uLiMHz/+/v37FrY0LC0mJsbT0zPP1CfbV6lSZeQjb775phT74Ycf 5jf16T6p6Ny58zPPPKNecLMm9eW589YcuGnqW7duXWBgYPNH6tWrp5Xz448/Gu6MucIBAAAAh0x9 DuxJpj7tc326sefMmTOyM5s3b9Z9+I4dO9zd3RcsWGBhy/ymvuzsbNlm1KhRC38TEhISEBCgpb65 c+eq25MnT85v6lu8eLEk1QMHDliok/ymPmsO3Cj1nTp1SnZjy5Ytcnv58uUq9alyFi1aZFiI5foH AAAASH2kvsdNfaJjx47t27dXb+a8e/euehfozp07s7KycnNzAwMDIyMjLWxpLjhFRETofqdlXFxc 9erVtc8KCvWdLuo1rt69e4eHh2dkZERHR1euXFlLfUal6T6pJKgKFSrIlrcNSMgsQOozero8D9wo 9e3Zs0dS37lz55KSkgYMGFC1alW1Xgpp1KjRoUOH5PbJkyfVl5fqFg4AAACQ+kh9hZb6JJl06dLF 2dnZz8/Pw8Njx44dsrJBgwaSVXx8fLp166a9W1J3S3PB6ciRI1KIt7e3eslL06NHj3HjxhntUpMm TQYNGiQ3tm3bVqdOnbJly4aGhs6cOVNLfUal6T5pVFRUKRPbt28vQOozero8D/yhyTs8Zf/LlStX u3btJUuWVKtWTX2hy9WrV+VRsldubm5eXl7qq2J0CwcAAABIfaS+/2L5M5EZN27lWUJ6evq1a9cM 16Q9Ys2WFkjOsebn+AxlZ2fr/uJCwUp7HEZPl68Df/jodxrUw+8+oq2/efOm6QHmt3DYBb4RAWDI 0BAAfZXUV3Ia7sn8ckNW+r2fJy2MdQ/hK5iBJ4KhBzBkaAiAvkrqKzkNV9ypL3nboR/aDl3h3FrW q4V5AWBSAxgyoCFAXyX10XB2n/oMX9wzWpgXACY1gCEDGgL0VVIfDWffqc/oxT1SH8CkBjBkQEOA vkrqo+EcJPUlbtprLuyxsLCwsLCwsOR3IU7ALvBtLjRcyUp9Dx99S+fJOV9t9H89tkbIOs/uTN8A AAAAqQ8Olfo0ydsS9r8xbWX5tnH1e618ui2pDwAAACD1waFSn2L60h9tAAAAAJD64DipT6Ne+iP1 AQAAAKQ+2Hfqs/yZyIwbt2gDoPiVtE+ZAwwZGgKgr5L6SnLDFfevtAOwBQxMgCFDQwD0VVJfyWk4 Uh/A2QgAQ4aGAOirpD5SH3UHcDYCGDKgIQD6KqmP1EenB5jUAIYMaAiA1EfDlbjUxwevARvEwAQY MjQEQF8l9ZWchivlkA0GAAAAgNQHUh8AAAAAUh+pDwAAAABIfaQ+AAAAAKQ+lNDUxwevARvEwAQY MjQEQF8l9ZWchuOXG4CSiIEJMGRoCIC+SuorOQ1H6gM4GwFgyNAQAH2V1Efqo+4AzkYAQwY0BEBf JfWR+uj0Sm5u7oMHD4rhibKysnJycuzxcIpnz8HABBgyNARAXyX10XAPn+C3uaxduzYqKmrJkiWr V68+d+6cI9XpqlWrqlat+vjlxMXFJSQkWNigXbt20mT2cjiFuOd51gwKPDABMGRoCIC+WmJTH9/m UvhatmzZuHHjsLAwX19fJyen2NjYYjvmy5cvX7hwwQZjktGO9evXb86cOY6R+owO7TH3PM+aAQAA AKkPNpH6JkyYoG536NAhJCSk2I65e/fuY8eOtcGYlN8ds6PUZ3RoxbPnAAAAIPXBVlLfiBEjvL29 5cbAgQPnzp07bNgwiRl37ty5fv16r1695HZAQEB8fLzaeM+ePZ06dZKV8pDk5GS1UndLKS0yMnL6 9OmyZZs2bfbv3y8rZ8yYUaFCBdnS399//fr1RnuVkpIyePDgOnXqVKxYsVmzZlo5ee7VjRs3evbs 6ebmJo8aN26cFpMeZ8dks/nz56uHyPZt27atXr16UFCQ2t4oO+lWiyHdEnT3xMLh5Flgt27dYmJi 1O3o6GgpRPfQ1J6bPq/Uv+ySh4dHzZo1Bw0alJqaqtsEWs1kZWX5/zfVe3WrHQAAAKQ+Ut+TSX2n T5+uVKnSW2+9pcKAu7v77NmzT506lZOTI3FiyJAhcpW/cOHCRo0aqQdKSJAAkJube/78+czMTLVS d0sprVatWiNHjjx69KhkgNDQUFmZnp4eHBw8fPhwCQYZGRlGeyXl+Pn5bdy4UUo+duyYVk6ee/Xq q6+GhIRcuHDhypUrkny0mPQ4O2YY6lavXn348GFZ379//759+5qmPt1qMWSuBNM9sXA4eRbYsGFD LanOmTOnadOm5g5N93lls44dOx5/pEOHDp07d9ZtAsMDv/6bxYsXlylTZtu2beaqHQAAAKQ+Ul+x fpuLpD5fX99nn322dOnSvXv3TktLUxf3Q4cOVRucPXtWdiY2NlYCQEJCgrOzc1JSkqx/+eWXVSDR ijK3pZQWHh6utlm6dKmXl5e6be6NlKoc0w+M5blXly5dkpWSFdU22lsiH3PHdN8GuWjRIh8fH9MN TKvFHKMSTPfE3OFYU6Bu6tM9NNPnPXfunDyv9gLs2rVr5e7FixeNmkC3Zg4ePFi+fPnly5dbqHZY MzABMGRoCIC+WmJTH9/mUnDmvv9UUl+fPn127tyZmJioezUfHx8vO9O6desXf7Nr1y5ZL8GmU6dO Li4u48ePv3//voUtDUuLiYnx9PS0nPpUOT/++KNp6rO8V9u3b5eV2oFoMekxd8xws3Xr1gUGBjZ/ pF69eqYbmFaLkTxL0PbE3OFYU6D1qc/0eVV1ac975coVubtjxw7TmGd0V5JhzZo1J0+ebLnnwJqB CYAhQ0MA9NUSm/r45YYiSX3a5/p0r+bPnDkjO7N582bdh0sYcHd3X7BggYUt85v6VDmLFi3K714l JSWVLl167969RjHpMXdM2+zUqVMS57Zs2SK3ly9frpvZTKvFkDUlaHti7nCsKVBS39y5c9VtiWH5 Sn0nTpyQ6vr+++/V+u+++07unj592nLqu3Pnjjxp3759c3Nzrek54MoJYMjQEAB9ldRH6rOV1Cc6 duzYvn179a7Fu3fvqneB7ty5MysrSy7xAwMDIyMjLWxpLlxFRETIxrp7JesbNWp06NAhuX3y5En1 S+LW7NXzzz8/cODA1NTUgwcPNmnSRItJj7Nj2mZ79uyRiHXu3DnJYwMGDNAKNyxHt1o01pRguCfm DifPAnv37h0eHp6RkREdHV25cmUt9Zk7NMPnldqW5+3fv7/U0q1bt8LCwlq0aKGynLnUJ4ccEhLS unVro5c3dasdXDkBDBkaAqCvkvpIfTaX+iRRdOnSxdnZ2c/Pz8PDQ73Zr0GDBpIxfHx8unXrdu/e PQtbmos0R44ckUK8vb3VS1WGrl69Ko+SSnBzc/Py8jL9VhVzz7Vx48ZKlSrJSgmN8+fP11LQ4+yY 4WahoaHlypWrXbv2kiVLqlWrpr49xXAD3WoxlGcJhnti7nDyLHDbtm116tQpW7as/HXmzJla6rNw aIbPe+rUKUl6EhddXV1btWqlXuizkPr27dsnjVW+fPkqvxk0aJC5agdXTgBDhoYA6KukPlJfsX6b i/XS09OvXbtmuCbtEWu2tEACnnopz9TNmzdv3bqV373Kysoy9+yFsmMpKSlq/d1HTDcwVy3Wl2Dl 4VguMDs721ztWahzo2LzrP+C9RwU4sAEGDKgIQD6qoOlPr7NBQAAoMhl3LhFJQCkPpD6AACAw/q6 VMstLwxK/HYvVQGQ+kDqAwAAjpn6ZFnh1GpVpXYJoz/hpT+A1AdSHwAAcMDUpy0rnAJ56Q8g9cEO Uh8fvAZsEAMTYMjYReozeunvp79EUkVg0iD10XC2mPp0p28WFhYWFhYWlgIsl1b+QKKAXfz/BamP hitxqY+RDzCpAQwZFOA/izc1DN/da8K3z/aNq9/r+KxoGgJMGqQ+Go7UB4CBCTBkHCH1rXJ9ZWfn MTu7Rqyu0nFPn3evbd2fm5VNQ4BJg9RHw5H6ADAwAYaMI1S14Yt7Rt/hSUOASYPUR8PZaOrjE/CA DWJgAgwZm73kMnxxj4YAkwapj4azj9QHAABgJX6gDyD1gdQHAAAAgNQHUh8AAAAAUh9IfQAAAABI faS+QsAHrwEbxMAEGDI0BEBfJfWVnIbjlxuAkoiBCTBkaAiAvkrqKzkNR+oDOBsBYMjQEAB9ldRH 6qPuAM5GAEMGNARAXyX1kfro9ACTGsCQAQ0BkPpouBKX+vjgNWCDGJgAQ4aGAOirpL6S03D8cgMA AAAAUp8jI/UBAAAAIPWR+gAAAACA1EfqAwAAgC3LysrKycl54ruRm5v74MEDc39NTk5OTU21hT0B qY/UZy0+eA3YIAYmwJBxpIZYu3ZtVFTUkiVLVq9efe7cOSrKgnbt2sn1XsEeGxcXl5CQUCi7sWrV qqpVq5quz8zMDA4O9vPz8/T0PHHiRDFUiLk9YdIomamPb3MpOL5kGbBBDEyAIeNIDdGyZcvGjRuH hYX5+vo6OTnFxsYW2y5dvnz5woULJST19evXb86cOboHnt96MJe1tmzZUrdu3eKskDxTX8GamF9u YLYn9QFgUgMYMijk1DdhwgR1u0OHDiEhIcW2S927dx87dmwJSX0WDjy/9WAua8m+tW/f3qZSX8Ga mNTHbE/qA8CkBjBkUFSpb8SIEd7e3nJj4MCBc+fOHTZsmFzT37lz5/r167169ZLbAQEB8fHxauM9 e/Z06tRJVspDkpOT1UrdLaW0yMjI6dOny5Zt2rTZv3+/rJwxY0aFChVkS39///Xr1xvtVbdu3WJi YtTt6Ojonj17FuBJDQ/BXLXoFmju2SX1TZkyZcyYMR4eHvXr11+7dq3hAU6ePLl27drPP//8qVOn 5OENGjT43e9+FxcXp20zf/580wM3rQfdw7lx44bshpubW7NmzcaNG2eatT799FP5a/ny5aWcJUuW yJqUlBR5UtnVmjVrDho0SPuwn1HNWLPzhsztiRTStm3b6tWrBwUFmWti022YNEh9pD7OlACTGsCQ QfGlvtOnT1eqVOmtt95S8cbd3X327NmSAXJycuQafciQIZIQFi5c2KhRI/VAyW8SHnJzc8+fP5+Z malW6m4ppdWqVWvkyJFHjx6VPBMaGior09PTg4ODhw8fLiEnIyPDaK8aNmyoMpKYM2dO06ZNC/Ck hodgrlp0CzT37FKmp6fnJ5988vPPPw8ePLhatWrZ2dlqvSSradOmSSEv/n/27gQsimvP//8FjLgv IOICREBRJ+Ia18RcFYSIqEESlFHHxFFHc2MMjhOjZpyfcVzuzZOoaNQ/GmUuMzfxUQQV4hrcguNG rolbRCUqCigEZLkKNuD/O9RY0+mubhow2na/X08/PtWH06dO1alT3R+rl1dekUD493//9z/99NMf /vAH2b3qY5XrhAYbbrwfNDfn9ddfDw4Ovn79+q1btySUGqe+v/3tb1FRUa+++qq0c//+fSmRZgMC Ai5WGTZs2IgRIzT3jCWd12eqJ/Hx8WfPnpVNmDBhwrhx4zSH2LgOJw1SH6nvf/AJeMAKMTEBpowt DYS8svfx8enatauDg0N4eHhRUZESDKZPn65UuHbtmrzCSUhIkPCQlpbm5OSUnZ0t5a+99pry6l9t ylRNaS0yMlKps2nTJk9PT2XZzNv/TOWuGq1U3QTJZmd+7ebNm6YaNJ/6PvroI2U5Ly9P1nv8+HGl /N1331XKpUKvXr2UnLl79+6GDRsapL5HZt/hqbk50lspTE5OVuqYel/lxx9/LOlOWc7IyJCHqBdR ExMT5e6NGzcM9oyFnVdZ0pP169d7e3ubH2L9Opw0+DYXUh8AAMBvS1Lfm2++efTo0aysLP0koEaU lJQUeYUzcODAVx47duyYlEtSGj58eL169T788MMHDx6YqanfWlxcnIeHR61TX+1WWlJSEvhra9eu NdWg+dSn/7m+1q1br1692qB8wYIFAQEBynJSUlJNU5/m5hw+fFgK1QGyJPUp7agPuXXrltw9cuSI 8VZY0nmVmZ7s3Lmzf//+vat06NBBc0s164AQQeoDAAD4zVOf+rk+zSRw9epVeYWzb98+zYdLkHBz c1NClKmatUt9q1atUpYXLlyo5q7arbRa+g2aWbt+m7m5ubJeiT1PNvVpbk52draDg4NyXdHC1Hfp 0iVp5+DBg8rdvXv3yt0rV67UMfWZ6kl6erok5/3798vyli1bNFOfqTogRJD6AAAAnnHqE5IEhg4d qrwNsqSkRHkX6NGjR3U6XWVlZf/+/aOjo83UNJX6oqKiTH3nZHh4eGRkZGlpaWxsbPPmzdXcVbuV mqHZoKm1S5uBgYEFBQXl5eXLly93dXU1Xpclqc9gww3uam5Onz59Jk2alJ+ff/r06R49elSb+ioq KuQhEyZMkIdLhyMiIvr27SubWcfUZ6onqampkugyMjIkFk6cOFHtnv6mmaoDQgSpDwAA4NmnPnmZ HhIS4uTk5Ovr6+7urrxRsFOnTvLC3dvbOzQ0VPn6EFM1TaW+c+fOSSNeXl7K9R99hw4dat++vbOz c1hY2LJly9TcVbuVmqHZoKm1S5vjx4/v3LmzbIKbm5t6Ja2mqc9gww3uam5OcnJys2bNpNDf33/N mjXVpr5HVdfWJOlJam3SpMmAAQOUC311T32meiL7qkGDBu3atdu4caPkYeXLWgw2TbMOCBGkPj4B D1gjJibAlLHPgSguLs7JydEvKapiSU0zbt++rfkdm+Xl5QUFBcblT2Sl1TaoufbCwsKysrLKykrp s3LdrC4MNtzgrvHm6HS6WmxgXl6e5m6sC1M9kXUpm1BSRXPTTNWx55MG3+ZC6uPbrgFrxMQEmDIM BFAXpbkFHKu2l/r45Qb2HcArJ4ApAwYC+L+jcf/Lk7O+Oc6xSuoj9XGCBjipAUwZMBCwzaNRblsd B2xvNiRt9ucGl/5IfZxkSH0AOKkBTBkwELCF1Kfetjr217/0R+rjJGN3qY9PwANWiIkJMGUYCOAJ pj6DS39//ZdoUh8nGftKfQAAAL/d62xu3KzzdnPbt6Q+kPoAAAAAG/k/iD3dIr8bO++bruOSOo69 uDzW/Dd8kvpA6gMAAACej9S3vcnvj4744OjIqPgWAalvfpRz4GSlrtwO9wYhgtQHAAAA2GDqs+eL e6Q+Up8hPngNWCEmJsCUYSCAOqY+Mxf37O1Y5dtcSH18yTJgpc9V7ASAKcNAALVm/uIev9zASYbU B4CTGsCUAQMBjlVSHwNH6gPASQ1gyoCBAMcqqY+BI/UBYGICTBkGAuBYJfUxcM849fHBa8AKMTEB pgwDAXCskvrsZ+D45QYAAAAApD5bRuoDAAAAQOoj9QEAAAAAqY/UBwAAAIDUB7tLfXzwGrBCTEyA KcNAAByrpD77GTh+uQGwR0xMgCnDQAAcq6Q++xk4Uh/AsxEApgwDAXCskvpIfew7gGcjgCkDBgLg WCX1kfo46AFOagBTBgwEQOpj4Owu9fHBa8AKMTEBpgwDISorKx8+fGgz+0en01VUVJhfrnvL4KRh w6mPb3MBAACwUomJiTFVDhw4UFZWZvkDt2/f3rJlS2U5KSkpLS3N2jZNcunu3bsXL148c+bMP/7x j/Hx8ffu3TNVeciQIfJazvxy7VjSwtdff3327Fn17s2bN7/66ivzAyTlJ06c4AAm9YHUBwAAUI1+ /fp17949IiLCy8urSZMm3333XS1S3/jx41euXFnHnmRmZl6/fr2mfzIlLy8vICDAw8Nj/vz5X3zx RVRU1EsvvZSSkmKdqc/Hx2f58uXq3eTk5BdffNH8AEn53LlzOYBJfSD1AQAAVJ/65s2bpyz37t1b 8lstUt8TMWrUqDlz5tT0T6ZMnz7d29v77t27+oWVlZXPY+rTHCBSH6kPpD4AAIAapz4JV6NHj1aW JS+NHTtWcl2XLl3US2S5ubljxoxxcXHp1auXRA419U2aNGnNmjXq8qpVq2bMmCF/LSws1GwnLy9v ypQp7du3b9q0qTQlJUuXLm3cuLFU8/Pz27Vrl34Pjf8kD5e1uLu7t2nTZvLkyfn5+QYbJSWOjo4x MdqfMoqOjh48eHCrVq0CAwNPnjxZbepbtGjRBx98IKvr2LFjYmKimUaMt0u/tXv37sny1q1ba536 9AeI1Efqg+2kPj4BD1ghJibAlLGlgVBChWSzuLi4+vXr79ixQymXMDN16lSJbevWrfP391cKX3/9 9eDg4OvXr9+6dSs0NFRNfQYxyc3NbcWKFenp6RUVFZrtSKGvr69km7KysgsXLkhJcXFxUFDQzJkz pSelpaX6PTT+k9wNCAi4WGXYsGEjRoww2KgTJ07Iq7IffvhBc5Pj4+PPnj0rTU2YMGHcuHHVpj4P D4/PP//8xx9/lETn6upaXl5uqhHj7VJbkxLpqmyFZpeqTX3GA2TDqY9vc2Hg7C718SXLgBViYgJM GVsaCAkPzs7ODg4O8jJm//79SuG1a9fkbkJCgsSqtLQ0Jyen7OzsmzdvSqEEEqWO/js8DWLS9OnT zbSjFBp/DtDCd3hmZGTIw9XrgYmJiXL3xo0b+vV3794thZmZmeb3yfr16729vatNfR999JGynJeX J80eP35csxFT26VcLZw4ceLIkSOVxFjT1Gc8QLad+vjlBgaO1AeAkxrAlMETTn1RUVF37tyR6PLe e+8phSkpKfKqZuDAga88duzYscOHD0thVlZWtalPXdZsRyn8/vvva5f6lIer3bh165bcPXLkiH79 c+fOSaGsS7O1nTt39u/fv3eVDh06VJv69D+V17p169WrV2s2Ymq7pIUBAwbIn1JTU02Njp+f3+LF i/VTq+RAMwNE6iP1MXCkPgCc1ACmDGqQ+pSPjUmoc3R0TEpKkuWrV6/Kq5p9+/bp18zOznZwcFCv dFmS+jTbUQrXr19fu9R36dIlefjBgweVu3v37pW7V65c0a9fWlrq6uo6bdo046bS09Pr1aunXDTb smVLjVJfbm6urEs2XLMRU9ultDB79uw2bdpIHc0NNHif6ubNmyUhmxkgUh+pj4Ej9QHgpAYwZVDj 1Cckmbi5uUm6k+WAgIChQ4cqv5dQUlJSVFQkC3369Jk0aVJ+fv7p06d79OhRbeoz1Y6U+Pv7nzlz RpYvX76s/Ih5VFSUlGt2Uv9PUlm6MWHCBGmqoKAgIiKib9++xl/OKenLycnps88+U95UKY/avXu3 rCs1NVUCW0ZGhmzmxIkTq90EWQ4MDJQVSTvLly+XMCnrNdWI5nYprUkPZdf5+Pgou9fAsmXLmjRp IntVSdfSzvz5880PEKmP1MfA2U7q4xPwgBViYgJMGVsaCP1Qcf/+fT8/v6CgIIkoEi1CQkIkOPn6 +rq7uytvoUxOTm7WrJkUSrZZs2aNJalPs53bt29LNXnh5OLi4unpqXxHy7lz5zp16uTl5aX/6bX/ 7fyv/5Seni5Jr3nz5pKUBgwYYHChT/Xll19KSGvYsGHnzp09PDxCQ0MliUl5WFhYgwYN2rVrt3Hj RqmgfBeLmdQ3fvx4pQVJXOo1Rs1GNLdLbU2n00kfunfvLhnSoKuy5yW+ygMlFkqelJypfjGpqQGS cqnv8Jh6bZCTBqmPgXv+Uh8AAMBTUJpboFleXFyck5OjXyLRxaDEEsbtiF9++cU4/0hwUi6RGTP4 U15envHDjWVmZl68eNHgYqA8VmmqpIqZhxcWFpaVlcnDZe0WNqK5XZaQBtPS0tSPLILUB1IfAABA XemK7/+4YF2CWzBvxAVIfSD1AQAAm3Ln0JlvB0/f6jRQ8p5yY58ApD6Q+gAAwHNP/+KewY2dA5D6 8GxSH5+AB6wQExNgyjyPTkz+fwYX90h94KRB6mPgrCL1cQoGrBATE2DKPHey9hw3Ffa4cbPCG6mP sz2pDwAnNYApg9oMxOWVXyX7vZXQOninxyiu9YGTBqmPgSP1AWBiAkwZ2xyIO4fSTr79ybZGg5M6 jt3WcDCpD5w0SH0MHKkPABMTYMrY4ECU5hYYXPpjF4GTBqmPgXs2qY9PwANWiIkJMGVsaSCUS3+k PnDSIPUxcM8s9QEAADwFpbkF7ASA1AdSHwAAAABSH6mPAQMAAABA6iP1AQAAAAAhgtT3P/gEPGCF mJgAU4aBADhWSX32M3D8cgNgj5iYAFOGgQA4Vkl99jNwpD6AZyMATBkGAuBYJfWR+th3AM9GAFMG DATAsUrqI/Vx0AOc1ACmDBgIgNTHwNld6uOD14AVYmICTBkGAuBYJfXZz8Dxyw0AAAAASH22jNQH AAAAgNRH6gMAAAAAUh+pDwAAAACpD3aX+vjgNWCFbH5i6nS6iooK88t1b/m5UFlZ+fDhQ5scWaYM 5y6AY5XUx8BZS+rjS5YBK2RmYkpI2L179+LFi2fOnPnHP/4xPj7+3r17z90GDhkyRE5o5pfr3rLJ 3fv112fPnlXv3rx586uvvlKWExMTY6ocOHCgrKxMrSPlJ06c+C12xfbt21u2bGkzh27dR5DnMls9 dwEcq6Q+Bo7UB8CiiZmXlxcQEODh4TF//vwvvvgiKirqpZdeSklJqWn7mZmZ169ft9vU5+Pjs3z5 cvVucnLyiy++qCz369eve/fuERERXl5eTZo0+e6779TyuXPnWm3qe1IDaqYdC1dB6uPcxU4Axyqp j4Ej9QGo08ScPn26t7f33bt39QsrKytr2v6oUaPmzJlD6tNMffPmzVOWe/fuPX78+Oci9T2pATXT joWrIPVx7mIngGOV1MfAkfoA1H5i5ufnOzo6xsRov6M9Ojp68ODBrVq1CgwMPHnypFI4adKk1atX f/DBB+7u7h07dkxMTJTCpUuXNm7cWJKGn5/frl27pCQ0NDQuLk55SGxs7JgxY9SHr1q1asaMGVK5 sLBQ0ubYsWNluUuXLpoXGPPy8qZMmdK+ffumTZv26tXLTMfMpL5FixYZdNhUI5qrU1u7d++eLG/d urXWqU9yzujRoy1Mfab2v5QvWbLEy8tr0KBBanlubq7sZBcXF+m2NKuZ+oz39p07d15++eUtW7Yo Fb755pugoKCHDx8aD6jBwFm494zbURn/SR4ua5FhatOmzeTJk+XgNL//NQ8eU/uH5zJekAEcq6Q+ Uh/f5gLYPs2JeeLECTkD/PDDD5oPiY+PP3v2bGlp6YQJE8aNG6e+BPfw8Pj8889//PFHeYnv6upa Xl5eXFwsaWHmzJnyQlzqS7Vu3bqtWbNGecjKlSt79uypPtzNzW3FihXp6ekVFRWSGaZOnSopYt26 df7+/sZ9kAq+vr4SosrKyi5cuGC+Y6ZSn3GHTTWiuTqlNSkZNmyYbKPmvqo29cmekRhcv379HTt2 WJj6TG1m27ZtZ82adf78eck8YWFhSvnrr78eHBx8/fr1W7duSeTWTH2ae3vbtm0NGzaUFUnoateu 3aFDh6TQeEANBs7CvWfcjsr4T3I3ICDgYhXZ1SNGjDC//zU3x9T+4bnMxs5dAMcqqY+Be/apD8Dz Yvfu3XIGyMzMNF9t/fr13t7e6qvqjz76SFmWnCAPP378+COjd+uZSX3Tp09Xlq9duyYPT0hIkFf5 aWlpTk5O2dnZ+utVKsjDLeyYqdSn2WHjRkytTrlaOHHixJEjRyqJsaapz9nZ2cHBQRrfv3+/Wsfy d3gabGZkZKSyvGnTJk9Pz0dVXx4jjctKlXLNd3ia2dsffPBBx44dR48eLQtqfYMB1R+4Gu09C9/h mZGRIQ9XrwcmJibK3Rs3bpja/6Y2R3P/AABIfXaI1Afgf507d07OAMeOHdP8686dO/v379+7SocO HYwDlWjduvXq1atrlPrUh6ekpMjaBw4c+MpjBj1RKnz//fc17ZiZz/WpHTZuxNTqpIUBAwbIn1JT U03tST8/v8WLF+vHacmBarqLioq6c+eOpKP33nvP8tRX7WbGxcV5eHjIwuHDh6V7WVlZZlKfmb1d VFTUqFGjFi1a3L9/30zq09+Nlu89C1Of8nB1E27duiV3jxw5Ymr/m9oczf0DACD1kfoYMMB+lZaW urq6Tps2zfhP6enp9erVU65NbdmyRTN15ObmyglEMoZm6lu1apWyvHDhQs3Ud/XqVXn4vn37THVP qbB+/fqadszUstphzUY0V6e2MHv27DZt2kgdza7qvyNRbN68WXKImu6Uz/VJNnN0dExKSrIk9Vmy mWqqyc7OdnBwUK9haqY+M3t7xowZI0eOlDz8pz/9yZLUV6O9Z2Hqu3Tpkjz84MGDyt29e/fK3StX rpja/6Y2h9QHAKQ+kPoAGJKX6U5OTp999pny3rmKiordu3dfvnw5NTVVXtlnZGRIopg4caKaIuRV dWBgYEFBgdRfvny5hMaioiIpj4qKGjp0qNpseHh4ZGSkpMrY2NjmzZtrpj4REBAgj1K+vr+kpERp Sp/81d/f/8yZM7IsvZLumemYqdRn3GFTjRivTm2tsrJy0qRJPj4+Bm9DVSxbtqxJkyanT59WMpi0 M3/+fIPUJyS6uLm5KS2YT32WbKZ+qunTp490Lz8/X/rQo0cPzc/1ae7tbdu2yUYVFhZK4qpfv75y ec14QPXXW6O9Z9COPv0/SWXZhAkTJkivZLAiIiL69u2rfJesqf2vuTmm9o8c5/pvwQUAkPpIfXXF B68BK2RmYn755ZeShRo2bNi5c2d5lRwaGiov2aU8LCysQYMG7dq127hxo1RQvrRDXlWPHDlSqSkB Rr04c+7cuU6dOnl5eSmXgA4dOtS+fXtnZ2dpRBKRqdQnr+BDQkIkdvr6+rq7u6uRQ3X79m15iJym XFxcPD09la/9MNUxU6lv/Pjxxh3WbERzdWprOp1Odk737t0llhj08/79+xJU5IESSyQRSc5Uv4JS P/VJNT8/v6CgIMkwUi71HR5Trw2qqt1M/VSTnJzcrFkz2ZOSu9asWaOZ+oz3tiQ32SenTp1SKixZ sqRNmzZKrDIYUIOBs3zvGbTzq2Py139KT0+XpNe8eXPJzwMGDFAu9JnZ/5oHj6n9M3z48K5du/Jc ZmPnLoBjldTHwD3L1MeXLANWqNqJmZmZefHiRYNf6svLy1Ou2JRUeaR34UVe4hv/rJ8UKvVFeXm5 cTrSVFxcnJOTY6bCL7/8YtCUccdMKSwsLCsr0+ywqUaMV2chaTAtLU39cFrdWb6ZSigyvxst3Num BtTCvmnuPTPtGPxJmq3Rzq/R5vBcZpPnLoBjldTHwJH6AFg0MUtzLX2d/ax+MhvgdQADAXCskvoY OFIfgBpPTF3x/R8XrEtwC7Z82m7evFnz59QBXsCBgQDHKqmPgSP1AbCik9qdQ2e+HTx9q9NAKVdu 7CKA5zIGAuBYJfWR+izFB68BK6RMTP2LewY3dhHAcxkDAXCs2lvq49tcANgU44t7pD4AAGDnqc+G kfoAu5O157ipsMeNGzduVn7jHA6Q+kDqA2CR0tyCyyu/SvZ7K6F18E6PUbyuAgAApD5SHwDbdOdQ 2sm3P9nWaHBSx7HbGg4m9QEAAFIfqa/G+OA1YIUMJqbxpT92EcBzGQMBcKzaW+rj21xqj5ePgBUy NTGVS39MW4DnMgYC4Fi1w9THLzew7wA7ejYqzS1gFwE8lzEQAMcqqY/Ux74DOKkBTBkwEADHKqmP 1McJGuCkBjBlwECAY5XUx8DZdurjg9eAFWJiAkwZBgLgWCX12c/A8csNAAAAAEh9tozUBwAAAIDU R+oDAAAAAFIfqQ8AAAAAqQ92l/r44DVghZiYAFOGgQA4Vkl99jNw/HIDYI+YmABThoEAOFZJffYz cKQ+gGcjAEwZBgLgWCX1kfrYdwDPRgBTBgwEwLFK6iP1cdADnNQApgwYCIDUx8DZXerjg9eAFbK3 ianT6SoqKhh3UVlZ+fDhQ/YDU4aBADhWSX12NXD8cgOA/5OYmBgTE7Nx48b4+PiMjAyr6lt2drb0 LScnpxaPHTJkiJzfar3qpKSktLS0Ovb/iTSiJrfdu3cvXrx45syZf/zjH2Ww7t27Z+Fjt2/f3rJl Sw51AACpz66Q+gD8n379+nXv3j0iIsLHx8fR0TEhIeGprTozM/P69etmKixYsEBOUIsWLapFa3VM fePHj1+5cmUdt6h2jRjLy8sLCAjw8PCYP3/+F198ERUV9dJLL6WkpJD6AACkPpD6AFiU+ubNm6cs Dxs2LDg4+KmtetSoUXPmzDH1V51O17ZtWz8/P09PT0veq2nQWh1T32+xRbU2ffp0b2/vu3fv6hdW VlaS+gAApD6Q+gDULPW9++67Xl5esjBp0qRVq1bNmDFD0kJhYaHkjbFjx8pyly5d1EtMqampw4cP l0J5yJ07d5RCzZrSWnR09JIlS6TmoEGDTp48KYVLly5t3Lix1JRct2vXLuOOJSQktG7d+tSpU3KO 2rNnj1oeGhoaFxenLMfGxo4ZM0azNSX1Gaz0UdV1M+mPu7t7mzZtJk+enJ+fr3ZSf5Pl7po1a5Tw 6fdryglTtmjw4MGtWrUKDAw0tUVqI+bXa7xz9ElNR0fHmBjtTx2YajY3N1f2jIuLS69evebOnaum Ps0BAgCA1EfqqzE+eA1YIVMTU019V65cadas2bRp05TI5ObmtmLFivT09IqKCgk2U6dOlSy0bt06 f39/5YESUSQmVVZW/vzzz2VlZUqhZk1prW3btrNmzTp//rxEjrCwMCksLi4OCgqaOXOm5JDS0lLj joWEhCgd69u3b3h4uFrerVs3NUqtXLmyZ8+emq1prlRItYCAgItVhg0bNmLECLWT+pusf6nw7mMb NmyoX7/+oUOHpDA+Pv7s2bOyrgkTJowbN85UH9RGzKxXs5+qEydOyFn6hx9+0Bw+U82+/vrrwcHB 169fv3XrluRkNfVpDhB4LmMgAI5Vu019fJtL7fEly4AVMjUxJfX5+Ph07drVwcFBwlVRUZESRaZP n65UuHbtmpwlEhISJFekpaU5OTllZ2dL+WuvvabkCrUpUzWltcjISKXOpk2bPD09lWUz74e8ceOG PFyCqCzHxMS88MIL6uVEzdT3SOsdnsYrzcjIkB6qlxYTExPlrqzLYJMfab1B9PTp040aNdqyZYtB V9evX+/t7W2qD0oj5teruXNUu3fvlsqZmZnGe8lUszdv3pSF5ORkpVx9h6epAQLPZQwEwLFqt6mP X25g3wH2kvrefPPNo0ePZmVlaWaelJQUOUsMHDjwlceOHTsm5ZL3hg8fXq9evQ8//PDBgwdmauq3 FhcX5+HhUW3qk/otWrSYVeWdd96RZj/99NOapj7jlSo9VLf01q1bcvfIkSPGMc/grkSpNm3aLFy4 UC3ZuXNn//79e1fp0KGD+T5YuF79naM6d+6cVFb2pAFTzR4+fFi/XE19pgYIPJcxEADHKqmP1Me+ A2w89amf69PMPFevXpWzxL59+zQfLhnDzc1t7dq1ZmrWNPWVl5dLnffff3/dY8HBwV26dFFT36pV q5RliWE1Sn2XLl2SHh48eFAp37t3r9xVriiaSX2FhYWy0nHjxqlfoJKeni5xd//+/bK8ZcuWalOf hevVTH2lpaWurq7KO28NmGo2OzvbwcHh+PHjBqnP/FCC5zIGAuBYJfWR+th3gJ2mPhEQEDB06FDl zZwlJSXKu0CPHj2q0+kkCPXv3z86OtpMTVPBJioqSiobdykpKalVq1bqZwWF8p0uyoWp8PDwyMhI yUKxsbHNmzdXU59Ba5orraio6NOnz4QJE6RjBQUFERERffv2VbKcqdQn2yiZc+DAgcr1TEVqaqqk voyMDMlXEydOVD81Z6oPFq5XM/U9qnoTqZOT02effSZ5WGlt9+7dly9fNtOslE+aNCk/P//06dM9 evRQe6g5QOC5jIEAOFZJfaS+GuOD14AVqvbbXMykPsk2ISEhEjx8fX3d3d2VtyZ26tRJsoS3t3do aOj9+/fN1DQVbM6dOyeNeHl5KRfNVKNHj547d65BlyS6TJ48WRYOHTrUvn17Z2fnsLCwZcuWqanP oDVTK01PT5doJHGxSZMmAwYMUC64mUl9ypepNGrUqMVjSjdk7Q0aNGjXrt3GjRtdXV2VL3Qx0wdL 1msq9Ykvv/xS1tKwYcPOnTtLHdnnkvrMNJucnNysWTMZCH9//zVr1qipT3OAwHMZAwFwrNpt6uPb XADgV4qLi3NycvRLiqpYUtOM27dvW/JzfPrKy8sLCgrq0lpeXp6pFiwnjSjrKqliSR/quN7MzMyL Fy8a/1KfZrM6nc7UKNRogAAAsOHUZ8NIfQAAAEDNlOYWsBMIEaQ+AAAAwGZ9/bt++1+enPXNcXYF IYLUBwAAANhm6pPbVscB25sNSZv9uZ1f+iNEkPr44DVgjZiYAFOGgQDqnvrU21bH/vqX/vg2F04y dpf6+JJlwDqfq9gJAFOGgQCeVOozuPTHLzdwkiH1AbDS5ypu3Lhx48aN25O63dz2LamP1EfqA8BJ DWDKgIGAjfz/6Z5ukd+NnfdN13FJHcdeXB7LtT5OMqQ+AJzUAKYMGAjYQurb3uT3R0d8cHRkVHyL gNQ3P8o5cLJSV26Hxyqpj9THB68Ba8TEBJgyDARQx3igf3HP4Ds8+TYXTjJ2l/oAAAAA20t9+hf3 7BwhgtQHAAAA2Bo7/4E+Uh+pDwAAAACpD6Q+AAAAAKQ+2Ebq44PXgBViYgJMGQYC4Fgl9dnPwPHL DYA9YmICTBkGAuBYJfXZz8CR+gCejQAwZRgIgGOV1EfqY98BPBsBTBkwEADHKqmP1MdBD3BSA5gy YCAAUh8DZ3epjw9eA1aIiQkwZRgIgGOV1Gc/A8cvNwAAAAAg9dkyUh8AAAAAUh+pDwAAAABIfaQ+ AAAAAKQ+2F3q44PXgBViYgJMGQYC4Fgl9dnPwPHLDYA9YmL+pnQ6XUVFBfuBKQMGAhyrpD4GjtQH wOpOaomJiTFVDhw4UFZW9mw7mZ2dLT3Jycl5tt34y1/+EqOlpKTE1EOGDBkip1MOM17AgYEAxyqp j4Ej9QGwupNav379unfvHhER4eXl1aRJk++++85MI5mZmdevX//tOrlgwQI5Iy1atOjZ7qu5c+dO qdKtWzc3N7cpj+Xn55P6mDJgIACOVVIfqY8TNPD8pb558+Ypy7179x4/fryZRkaNGjVnzpzfqIc6 na5t27Z+fn6enp5W8m5J2dgBAwZYUpPUxws4MBDgWCX1MXD2lfr44DVghUxNTP3UJ6Fu9OjRyvLd u3fHjh3bsmXLLl26pKSkSMnSpUsbN24sJRLMdu3aJSWhoaFxcXFK/djY2DFjxijLkyZNWrVq1YwZ M6RyYWGh3I2Ojl6yZImXl9egQYNOnjyp2ZOEhITWrVufOnVKTkp79uxRy/Py8qZMmdK+ffumTZv2 6tXLTKFxn0Vqaurw4cOlUNZ+584dM4WWpD5Zr2yOu7t7mzZtJk+erF79U1PfvXv3ZHnr1q1mumTh DoF1ThkwEADH6iO+zYXUB+D5oqQ+CSeS3+rXr79jxw6lPDAwcOrUqZLZ1q1b5+/vLyXFxcVBQUEz Z86UyqWlpVLSrVu3NWvWKPVXrlzZs2dPNQK5ubmtWLEiPT29oqJC7rZt23bWrFnnz5+XCBQWFqbZ k5CQECV/9u3bNzw8XC2Xnvj6+iYnJ5eVlV24cMF8oUGfhcQqiaCVlZU///yz+sFFzUJLUp/sgYCA gItVhg0bNmLECP3UJ01Joewi/c4bd8nCHQIAAKkPpD4ATyb1OTs7Ozg4yKlg//79SuG1a9fkbkJC gmSbtLQ0Jyen7OzsR0bv8DST+qZPn65Wk7uRkZHK8qZNmzw9PY27cePGDVnLlStXZDkmJuaFF15Q LsEpPZHG9SubKTTu82uvvRYcHGzwcUTNwmpTX0ZGhqxCuc75qOqLcOSu9FzZxkWLFk2cOHHkyJHl 5eXmu2TJDgEAgNQHUh+AJ5b6oqKiJGJ5e3u/9957SmFKSoqcGQYOHPjKY8eOHatR6tP/kJv+3bi4 OA8PD80njxYtWsyq8s4778jaP/30U7Un33//vX5lM4XGfZZoN3z48Hr16n344YcPHjxQKmsWVpv6 lFVkZWUpd2/duiV3jxw5omyj1JS7qamp1XbJkh0CAACpD6Q+AE8s9Snvqzx8+LCjo2NSUpIsX716 Vc4M+/btM6hsnPpWrVqlLC9cuLDWqa+8vFwK33///XWPBQcHd+nSRe3J+vXr9eubKTTus0KymZub 29q1a6stNJP6Ll26JKs4ePCgcnfv3r1yV7k+qWzj7Nmz27RpIz0x3yVSHwCA1IfnPvXxwWvAClny bS4SWiQFKe9CDAgIGDp0qPIeyJKSkqKiIlmIioqSQvWx4eHhkZGRpaWlsbGxzZs3r3Xqk6jZqlUr /c/XKd/polwZkzX6+/ufOXNGli9fvqx8vadmoWafjx49qtPpKisr+/fvHx0drbSvWVht6pO19OnT Z8KECdJyQUFBRERE3759pRF1G2V50qRJPj4+yj401SVS33M9ZcBAAByrj/g2F1LfI75kGbBKlvxy w/379/38/IKCgiS9SG4JCQlxcnLy9fV1d3dX3sd47ty5Tp06eXl5KZ8APHToUPv27Z2dncPCwpYt W1br1Dd69Oi5c+caFPbo0WPy5MmycPv2bWlBzlQuLi6enp7KF8loFmr2WTrcsmVLb2/v0NBQ2UCl cc3CalOfSE9Pl6QnEbdJkybyJ+VCn/42SpiUNrt37y6x0FSXSH3P9ZQBAwFwrD7ilxtIfZyggefx pFaaW6BZXlxcnJOTY1AoiUv9Pb3y8nIl3vzWfvnlF+MVaRYa97moikE1zUIL5eXl1WirNXcjeB0A BgIcq6Q+Bo7UB+A3P6npiu//uGBdglsw0xbguYyBADhWSX2kPvYdYFMntTuHznw7ePpWp4FSrtzY RQDPZQwEwLFK6iP1WYoPXgNWSJmY+hf3DG7sIoDnMgYC4Fi1t9THt7kAsCnGF/dIfQAAwM5Tnw0j 9QF2J2vPcVNhjxs3bty4ceP2RG6kPpD6ADxjpbkFl1d+lez3VkLr4J0eo7jWBwAASH2kPgC26c6h tJNvf7Kt0eCkjmO3NRxM6gMAAKQ+Ul+N8cFrwAoZTEzjS3/sIoDnMgYC4Fi1t9THt7nUHi8fAStk amIql/6YtgDPZQwEwLFqh6mPX25g3wF29GxUmlvALgJ4LmMgAI5VUh+pj30HcFIDmDJgIACOVVIf qY8TNMBJDWDKgIEAxyqpj4Gz7dTHB68BK8TEBJi2UwDuAACAAElEQVQyDATAsUrqs5+B45cbAAAA AJD6bNmvUt/kyZNlwN5++232CwAAAABLECKes9T3+9//XgZsyJAh7BcAAAAAliBEPGepTwL676r8 27/926PH12pZZplllllmmWWWWWaZZZZNLffs2ZNrfc9T6uPbXAA7wcQEmDIMBMCx+qTwbS62kPoW L148f/78b775ptq2Dhw48NNPPxkUfv27fvLwnTt3WuHGm+qYNXT48OHD86tUVFRw6sQTx7efA0wZ BgLgWCX12c/AVZ/6mjVr9g//8A8nTpx49dVX+/TpoxS+/fbbDRo0ePjwoSyvXr369ddfr6yslMe+ ++676gP/9re/yb9f/a6fQXmtKQ0+KcYdNl/+lJ09e1b6ID3R6XScOsFJDWDKgIEAxyqpj4H7bVPf l19+KQsff/yxk5NTYWGhLHfq1Elqnjp1SpbHjBnz6aefysKdO3eKioqUR7Vr127cuHFPMPWpDdpJ 6hM7d+4k9YGTGsCUAQMBjlVSHwP39FLfgQMH5K/JycmS7ho2bOjg4LB69ery8vLmzZt///33EpZ8 fHwWLVqk5ENHR8fGjRv36dNHSX3Tp0//x3/8x1atWk2bNs24E9u2bfPz82vatOkbb7xx79691NRU aerf//3f5U8rVqyIjIzUb9C4vrLqefPmvfnmm0FBQcrd+fPn66+xrKxs1KhRnp6eHh4e0pnKKmZS nzw2IiLC3d39X/7lXyToGqxCqu3atcvf379Ro0bdunVLSEiQki+++KJr166yIlkeOnSoklFv3br1 0ksvPXz48D/+4z9efvllqS+BWVqrditIfeCkBjBlwECAY5XUx8A97dT3t7/97YUXXpAUtGPHjmHD hv3d3/3d+PHjT5486erqWlFRoR+ifvnlF4mCoaGhmZmZP/7b/yflknaWL1+u/JTHuXPn9NuXZiXO ffjhh+np6RImP/nkEymcMGFCvXr1ZL3ypx9//FG/QeP6yqplecGCBXv27FHuGqxRctfXX3+dl5e3 fft2KTl48KD51NeiRYsNGza8//77srxx40aDVVy6dEl2xZgxY37++efw8HDpqnTyv//7v6XOt99+ e+XKFVlwdnaWrq5fv37kyJGyILvx7//+72VB9pjmVhusgtSH3xTfiAAwZRgIgGOV1Gc/A1eD1CcG DRrUr1+/OXPmSM2pU6e++OKLy5Ytk9jzyOiNkS1btlQudinlkr4eVV0fk+WkpCT99v/rv/5LCqW1 f/3Xf23dunVISIiSG9u0aSPlH3/8sUGDxvWVVbzzzjv6sc14jTdv3pTHTps2TUokjJlPfTNmzJDl Bw8eSLqTDTRYxWeffSZ3lW+4US6Brlixory8XDo5d+7czz//XJKeFEp4k+7JuqRa9+7dHR0dpdlb t25ZshWkPgAAAJD68AxS3/z58+vVq/fSSy8dPHhw8+bNUrlbt27r1q2rNvUp5ZK+jFPfn/70Jyn8 53/+581VlL8WFxd7e3tLuYQigwaN6xusWnONt2/fbtiwoUTB1atXW5L6lHJJffXr15ckZlBZMp5y WU+Wv/vuO1lesmSJLEdERMgOGTp0qAQ22Uv/9E//1KBBg8zMzEdVF/dkx8pWSDcuXLhQ7VaQ+gAA AEDqwzNIfXv37pUKEvxKSkouXbqk/KT75cuXjVNf9+7de/bsWVZWVm3q++tf/+ro6Dh69Ohbt24V FRX98MMPUjht2rTg4OC33npL1iUV9Bs0rm9J6lOuzv3888//+Z//qVxCNJ/6Bg8enJWVJRsuy9u3 bzeofOrUKQcHh6lTp5aWls6ePVv+lJqaKuVK/SZNmkjG++CDD1544QXps5RLP6XbFRUVSn/i4+Or 3QpSHwAAAEh9eAapr7i4WGJY3759lXTk4uLi4eFhnLVEbGysq6urs7Pz/fv3zac+sWXLFqksOap+ /fpvvPGGVJC7t2/fzsvLc3d379Gjx8OHD9UGHzx4YFDfktR39erVDh06KO/ADA0NlTyWm5trJvVJ nQEDBshCUFCQRDjjSPbFF180bdq0YcOG8u/q1auVQolwUk15k6qyauUdqteuXWvdunXz5s1lj40b N075CT7zW0HqAwAAAKkPTy/1zZgx4+zZszVtury8vKCgwPLPRObk5Cg/AGi+QcvrG8c5iaDKcn5+ viUP0V+dMQlv0gfLf0X93r17paWlFm71pUuXJKCS+vAb4RsRAKYMAwFwrJL67Gfgqk99UVFRM2fO jI+Pr90K+JLl2tm3b9/MKpanSoCJCTBlGAiAY5XUx8DVJvWx7wCejQCmDDuBgQA4Vkl9pD4OeoCT GsCUAQMBkPoYOFIfAE5qAFMGDAQ4Vkl9DJyNpT4+eA1YISYmwJRhIACOVVKf/Qzc72xywAAAAACQ +kDqAwAAAEDqI/UBAAAAAKmP1AcAAACA1Ac7TX188BqwQkxMgCnDQAAcq6Q++xk4frkBsEc2MzF1 Ol1FRQUDCqYMAwFwrJL6GDhSHwBLJ2ZlZeWOHTvmz58/d+7cv/zlLw8fPvytO5OdnR0TE5OTk1OL xw4ZMkROXAaFDx48iDGSlZVluBO+/vrs2bPq3Zs3b3711VfKcmJiovKoAwcOlJWVqXWk/MSJExw/ TBkwEADHKqmP1McJGnheT2r5+fmBgYF+fn6ffPLJ8uXLe/Xq9fLLL2dmZv6mnVmwYIGceRYtWmRJ ZenM9evXzae+oqKiKXp69+4t7aelpRlU8/HxkW1U7yYnJ7/44ovKcr9+/bp37x4REeHl5dWkSZPv vvtOLZcwzPHDlAEDAXCskvpIfZyggef1pPaHP/yhQ4cO9+7dU+4+ePBAUt8bb7zx2/VEp9O1bdtW cqanp6cl79UcNWrUnDlzzKc+gxzbvn37iRMnGv/JfOqbN2+esiyhcfz48aQ+pgw7gYEAOFZJfaQ+ k/jgNWCFNCdmQUFBvXr1Zs2apV+4YsUKOS389NNPsjxp0qTVq1d/8MEH7u7uHTt2TExMVOrcvXt3 7NixLVu27NKlS0pKilIolaOjo5csWeLl5TVo0KCTJ09q9iQhIaF169anTp2StezZs0ctDw0NjYuL U5ZjY2PHjBkjC0uXLm3cuLGsSFLirl271NRnZi2RkZGSJ2XTap36JGeOHj2a1MeUYScwEADHqs2n Pr7NBYDtO3HihJwBdu/erV/417/+VQrj4+OViOXh4fH555//+OOPU6ZMcXV1LS8vl/LAwMCpU6cW FhauW7fO399feaBUbtu2rWTI8+fPSyYMCwvTXGlISIiSr/r27RseHq6Wd+vWbc2aNcryypUre/bs KQvFxcVBQUEzZ86UnFlaWlrtWrZu3erg4HDgwAHNVVeb+mQtkjzr16+/Y8cOUh8AADaf+mwYqQ/A /5K8p17WU+l0OglOGzZsUCLWRx99pJTn5eVJ5ePHj1+7dk0WEhISLl68mJaW5uTklJ2drVSOjIxU Km/atMnT09N4jTdu3JD6V65ckeWYmJgXXnjhzp07ZlLfI613eJpaS1ZWlouLi8GlS8tTn7Ozs2y4 bNr+/fvVOqQ+AABIfaQ+AM+xCxcuyBlA0pd+YWZmppp8DD5E17p169WrV6ekpEiFgQMHvvLYsWPH DCrHxcV5eHhoPkm0aNFiVpV33nlH2vn0009rmvpMrWXEiBGdO3e+f/++qe318/NbvHixfuiVHKim u6ioKImg3t7e7733HqkPAABSH6kPgC14+PBhu3bt3nrrLf3CtWvXNmnSJC8vzyBi5ebmyuli+/bt V69elYV9+/YZtFZt6isvL5fC999/f91jwcHBXbp0UVPfqlWrlOWFCxfWNPVt2LChXr16p06dMrO9 w4YNk2So3t28ebNEVjXdKe87PXz4sKOjY1JSEqkPAABSH6nPJD54DVghUxPzz3/+c6NGjfbu3avc PXHihJub27Jly9SIFRgYWFBQIIFt+fLlrq6uRUVFUh4QEDB06FDlBxVKSkqUwmpTn0SpVq1a6f8a nvKdLsqlwvDw8MjIyNLS0tjY2ObNm6upLyoqStZlPvVJEG3cuLHUvKdH+QiiPtkuCbSnT59+VPWb gdLs/PnzDVKfmD17tuwE5W2rpD6mDBgIgGPVhlMf3+ZSe3zJMmCFzExMyU4uLi7e3t4dO3Zs1qzZ 6tWrKysr1Yg1cuTIzp07S7iSIHTw4EGlXBJRSEiIk5OTr6+vu7v7kSNHLEl9o0ePNk5QPXr0mDx5 siwcOnSoffv2zs7OYWFhEs/U1Hfu3LlOnTp5eXkZv+lUXUtMTMzvjBw+fNhgXffv34+IiJA/+fj4 1KtXTwJtfn6+ceqTan5+fkFBQbIfpFzqOzymXhuEPU8ZMBAAxyq/3EDq4wQNPH8nNYk3V69evXLl isEP6CkRS/56+/ZtNQqqiouLc3JynmAny8vLNX9xQUgHLPlxP0vk5eWlpaVlZWVxVIDnMgYC4Fgl 9ZH62HeAvT8bVfuT6MDzqzS3gOcyXpABHKukPlIf+w6w92ejzZs3qz/CDtjepNj/8uSsb47zXMYL MoBjldRH6qsxPngNWCEmJmD8TC+3rY4Dtjcbkjb7c4NLf0wZzl0Ax6o9pD6+zQUAANtPfeptq2N/ M5f+AACECFIfAADPd+ozf+kPAECIIPUBeC5f4HLjxs3M7ea2bzl1AACpj9QHAICN/FfInm6R342d 903XcUkdx15cHsu1PgAg9ZH6zOGD14AVYmICmqlve5PfHx3xwdGRUfEtAlLf/CjnwMlKXTlThnMX wLFqJ6mPb3Op0/MoMx+wwhe47ATAYFKYubjHlOHcBXCs2kPq45cb2HcAz0aAjU8K/Yt7TBnOXQDH KqmP1Me+AzipATbF/Cf3mDKcuwCOVVIfqY+DHuCkBjBlwEAApD4Gzl5THx+8BqwQExNgyjAQAMcq qc9+Bo5fbgAAAABA6rNlpD4AAAAApD5SHwAAAACQ+kh9AAAAAEh9sLvUxwevASvExASYMgwEwLFK 6rOfgeOXGwB7xMQEmDIMBMCxSuqzn4Ej9QE8GwFgyjAQAMcqqY/Ux74DeDYCmDJgIACOVVIfqY+D HuCkBjBlwEAApD4Gzu5SHx+8BqwQExNgyjAQAMcqqc9+Bo5fbgAAAABA6rNlpD4AAGqvsrJyx44d 8+fPnzt37l/+8peHDx/+duv6+uuvz549q969efPmV199pSwnJibGVDlw4EBZWZlaR8pPnDjBMAEg 9ZH6GDAAAGojPz8/MDDQz8/vk08+Wb58ea9evV5++eXMzMzfaHU+Pj6yFvVucnLyiy++qCz369ev e/fuERERXl5eTZo0+e6779RyiaOMFABSH6mPAQMAoDb+8Ic/dOjQ4d69e8rdBw8eSOp74403nknq mzdvnrLcu3fv8ePHk/oAkPrw9FIfH7wGrBATE6j7lCkoKKhXr96sWbP0C1esWCHPpD/99JMsT5o0 afXq1R988IG7u3vHjh0TExOVOnfv3h07dmzLli27dOmSkpKiFErl6OjoJUuWeHl5DRo06OTJk7VO faNGjRo9erRNpj7OXeBYJfUxcFaa+viSZcAKMTGBuk+ZEydOyJPm7t279Qv/+te/SmF8fLwsDxky xMPD4/PPP//xxx+nTJni6upaXl4u5YGBgVOnTi0sLFy3bp2/v7/yQKnctm1byZDnz5+XTBgWFlaL 1Cd5Mi4urn79+jt27LDJ1Me5CxyrpD4GjtQHgIkJPL0pI3lPvayn0ul0Dg4OGzZsUILcRx99pJTn 5eVJ5ePHj1+7dk0WEhISLl68mJaW5uTklJ2drVSOjIxUKm/atMnT07Omqc/Z2VlWLY3v379frUPq AzhWSX0MHKkP4NkIQC2nzIULF+RJMybmV28HyszMVHOXBDl5YlX/1Lp169WrV6ekpEiFgQMHvvLY sWPHDCrHxcV5eHgYr9HPz2/x4sX6sVNyoJruoqKi7ty54+3t/d5775H6AI5VUh8DR+oDeDZiYgJ1 nTIPHz5s167dW2+9pV+4du3aJk2a5OXlGQS53NxceYbdvn371atXZWHfvn0GrVmS+oYNGzZixAj1 7ubNmyU0qulO+Vzf4cOHHR0dk5KSSH0Axyqpj4F7eqmPD14DVoiJCTyRKfPnP/+5UaNGe/fuVe6e OHHCzc1t2bJlapALDAwsKCgoLy9fvny5q6trUVGRlAcEBAwdOvT69euyXFJSohRakvqkZYmUp0+f luXs7GxpZP78+QapT8yePVu6obxxlG9zAThWSX0M3CN+uQEAgLqQhObi4uLt7d2xY8dmzZqtXr26 srJSTX0jR47s3LmzRDiJYQcPHlTKJY+FhIQ4OTn5+vq6u7sfOXLEwtR3//79iIgIeab28fGpV6+e RMr8/Hzj1CfV/Pz8goKCpCdSLvUdHlOvDQIAqc+ukPoAAKgTCVdXr169cuVKRUWFfrkS5OSvt2/f VqOgqri4OCcnpxary8vLS0tLy8rKYs8DIPWB1AcAwLNk8G0uAGxJaW4BO4EQQeoDAMDebd68Wf0R dgA25uvf9dv/8uSsb46zKwgRpL7/wQevASvExASYMgwEUMfUJ7etjgO2NxuSNvtzg0t/fJsLJxm7 S318yTJgnc9V7ASAKcNAAHVMfeptq2N//Ut//HIDJxlSHwBOagBTBgwEbCr1GVz6I/VxkiH1AeCk BtjCyztu3LhxM3O7ue1bUh8vkEh9ADipAUwZMBCwkf8M2tMt8rux877pOi6p49iLy2O51sdJxu5S Hx+8BqwQExNgyjAQQN1T3/Ymvz864oOjI6PiWwSkvvlRzoGTlbryR3ybCycZO0x9AAAAgO2lPv2L e3b+832ECFIfAAAAYIOpT//inp0jRJD6AAAAAFtj5xf3SH2kPgAAAACkPthT6uOD14AVYmICTBkG AuBYJfXZz8Dxyw2APWJiAkwZBgLgWCX12c/AkfoAno0AMGUYCIBjldRH6mPfATwbAUwZMBAAxyqp j9THQQ9wUgOYMmAgAFIfA2d3qY8PXgNWiIkJMGUYCIBjldRnPwPHLzcAAAAAIPXZMlIfAAAAAFIf qQ8AAAAASH2kPgAAAACkPthd6uOD14AVYmICTBkGAuBYJfXZz8Dxyw2APWJiAkwZBgLgWCX12c/A kfoAno0AMGV+RafTVVRUWGHHYn7XKz8/nwMSnDRIfQwcqQ8AExN4SlMmMTExJiZm48aN8fHxGRkZ VtXn7Oxs6VtOTk4tHjtkyBB5SWBQ+ODBgxgjWVlZBtWSkpLS0tKe+OaUlZUFBQW5/87Zw8Pj0qVL HJPgeZbUx8CR+gAwMYGnMWX69evXvXv3iIgIHx8fR0fHhISEp9alzMzM69evm6mwYMECeU5ftGhR LVrTTH1FRUVT9PTu3VvaNw5448ePX7lyZR07b2z//v0vvvgi5y7wPEvqY+CsNPXxwWvACjExgScy ZST1zZs3T1keNmxYcHDwU+vSqFGj5syZY+qvOp2ubdu2fn5+np6elrxX06A1zdSnLz8/v3379hMn TvwtOm/qNeXQoUM5d4HnWVIfA2elqQ8AAFuln/reffddLy8vWZg0adKqVatmzJjRsmXLwsLCu3fv jh07Vpa7dOmSkpKiVE5NTR0+fLgUykPu3LmjFGrWlNaio6OXLFkiNQcNGnTy5EkpXLp0aePGjaWm 5Lpdu3YZdywhIaF169anTp2Sp/U9e/ao5aGhoXFxccpybGzsmDFjNFtTUp/BSvVFRkZKniwoKDBe tXR4zZo1Neq8qQ1Xd+Nnn33m4uLSqFEjecjGjRvlr9Ls4MGDW7VqFRgYqHYvLy9vypQpEkebNm3a q1cvM3sVAKnP3pD6AACoa+q7cuVKs2bNpk2bpkQmNze3FStWpKenV1RUSCyZOnWqxL9169b5+/sr D5QIJJGmsrLy559/LisrUwo1a0prbdu2nTVr1vnz5yW9hIWFSWFxcXFQUNDMmTMl0pSWlhp3LCQk ROlY3759w8PD1fJu3bqpkWzlypU9e/bUbE1zpaqtW7c6ODgcOHBAc5/oXye0sPOmNlzdjfKQqKio V199VR5y//59+Wt8fPzZs2fl4RMmTBg3bpy6A319fZOTk2WXXrhwwcxeBUDqI/UxYAAAWJr6fHx8 unbtKilIwlVRUZESV6ZPn65UuHbtmjyxJiQkXLx4MS0tzcnJKTs7W8pfe+214OBg/c+2maoprUVG Rip1Nm3a5OnpqSybeZPkjRs35OESRGU5JibmhRdeUC8naqa+R1rv8NRcqcjKynJxcZEgZ2qfGKS+ ajtvZsPV3Sg+/vjjYcOGGa9u/fr13t7eajsGHyk01TgAUh+pjwEDAMDS1Pfmm28ePXpU/6ss9WNP SkqKPLEOHDjwlceOHTsm5ZL3hg8fXq9evQ8//PDBgwdmauq3FhcX5+HhUW3qk/otWrSYVeWdd96R Zj/99NOapj7NlYoRI0Z07txZueBmSeqrtvOWbLhx6tu5c2f//v17V+nQoYPazvfff6/fGVONAyD1 kfr4NhfA9jExgScyZfQ/16cZe65evSpPrPv27dN8+JEjR9zc3NauXWumZk1TX3l5udR5//331z0W HBzcpUsXNfWtWrVKWV64cGFNU9+GDRskqZ46dcrMvqpp6rNkw9XUpwxEenq6dGP//v2yvGXLFiX1 Ke2sX79evxHz+x/geZbUZz8Dxy83APaIiQk8kSlTbeoTAQEBQ4cOVd7MWVJSorwL9OjRozqdrrKy sn///tHR0WZqmgpOUVFRUtm4S0lJSa1atVI/KyiU73RRrnGFh4dHRkaWlpbGxsY2b95cTX0GrWmu VBJU48aNpeY9PRIya5H6DFZX7YarqU8ZiNTUVEl9GRkZ2dnZEydObNmypVJHGvH39z9z5owsX758 WfnyUs3GAZ5nSX32NnCkPoBnIwC/YeqTZBISEuLk5OTr6+vu7n7kyBEp7NSpk2QVb2/v0NBQ9d2S mjVNBadz585JI15eXsolL9Xo0aPnzp1r0KUePXpMnjxZFg4dOtS+fXtnZ+ewsLBly5apqc+gNc2V xsTE/M7I4cOHa5H6DFZX7YYbpD4h/W/QoEG7du02btzo6uqqfKHL7du35VHSKxcXF09PT+WrYjQb B3ieJfWR+kh9AM9GAGowZUpzC6ptobi4OCcnR7+kqIolNc2QnGPJz/HpKy8v1/zFhdq1VhcGq7Nk w/UHIi8vT3l4SRW1/JdffjHewBrtVYDnWVIfqY99B/BsBDBl/oeu+P6PC9YluAUzoTh3AaQ+Up+9 pz6+NAKwQkxMoC5T5s6hM98Onr7VaaC8PlBu7CLOXYA9H6t8mwupDwAAG6F/cc/gxs4BYM8IEaQ+ AACee8YX90h9AECIIPUBAGAjsvYcNxX2uHHjxo3/DCJEkPoAALAFpbkFl1d+lez3VkLr4J0eo7jW BwCECFLfr/DBa8AKMTGB2k2ZO4fSTr79ybZGg5M6jt3WcDCpj3MXwLH6iG9zIfU94kuWAavExATq MmWML/2xizh3AfZ8rPLLDaQ+TtAAJzXAZqeMcumPCcW5CyD1kfpIfZygAU5qgC1PmdLcAnYR5y6A 1EfqI/UB4KQGMGXAQIBjldTHwNlo6uOD14AVYmICTBkGAuBYJfXZz8Dxyw0AAAAASH22jNQHAAAA gNRH6gMAAAAAUh+pDwAAAACpD3aX+vjgNWCFmJgAU4aBADhWSX32M3D8cgNgj5iYAFOGgQA4Vkl9 9jNwpD6AZyMATBkGAuBYJfWR+th3AM9GAFMGDATAsUrqI/Vx0AOc1ACmDBgIgNTHwNld6uOD14AV YmICTBkGAuBYJfXZz8Dxyw0AAAAASH22jNT3hOl0uoqKCivs2J07d/Lz8xkgAAAAkPpIfU9pwBIT E2NiYjZu3BgfH5+RkWFVOyU7O1v6lpOTU4vHDhkyRHajQeGDBw9ijGRlZRlUS0pKSktLe+KbU1ZW FhQU5Ovr6+HhcenSJQ56AAAAkPpIfU9jwPr169e9e/eIiAgfHx9HR8eEhISnts2ZmZnXr183U2HB ggWyHxYtWlSL1jRTX1FR0RQ9vXv3lvaNA9748eNXrlxZx84b279//4svvsixDgAAAFIfqe+pfpuL pL558+Ypy8OGDQsODn5q2zxq1Kg5c+aY+qtOp2vbtq2fn5+np6cl79U0aE0z9enLz89v3779xIkT f4vOm5qHQ4cO5ViHJRMTAFOGgQA4Vu029fFtLrVn6vtP9VPfu+++6+XlJQuTJk1atWrVjBkzWrZs WVhYePfu3bFjx8pyly5dUlJSlMqpqanDhw+XQnnInTt3lELNmtJadHT0kiVLpOagQYNOnjwphUuX Lm3cuLHUlFy3a9cu444lJCS0bt361KlTsiv27NmjloeGhsbFxSnLsbGxY8aM0WxNSX0GK9UXGRkp ebKgoMB41dLhNWvW1KjzpjZc3Y2fffaZi4tLo0aN5CEbN26Uv0qzgwcPbtWqVWBgoNq9vLy8KVOm SBxt2rRpr169zOxV2Aa+/RxgyjAQAMcqqc9+Bu7Zp74rV640a9Zs2rRpSmRyc3NbsWJFenp6RUWF xJKpU6dK/Fu3bp2/v7/yQIlAEmkqKyt//vnnsrIypVCzprTWtm3bWbNmnT9/XtJLWFiYFBYXFwcF Bc2cOVMiTWlpqXHHQkJClI717ds3PDxcLe/WrZsayVauXNmzZ0/N1jRXqtq6dauDg8OBAwc094n+ dUILO29qw9XdKA+Jiop69dVX5SH379+Xv8bHx589e1YePmHChHHjxqk70NfXNzk5WXbphQsXzOxV 8GwEMGXAQAAcq6Q+Up+lqc/Hx6dr166SgiRcFRUVKXFl+vTpSoVr165JZxISEi5evJiWlubk5JSd nS3lr732WnBwsP5n20zVlNYiIyOVOps2bfL09FSWzbxJ8saNG/JwCaKyHBMT88ILL6iXEzVT3yOt d3hqrlRkZWW5uLhIkDO1rwxSX7WdN7Ph6m4UH3/88bBhw4xXt379em9vb7Udg48UmmocPBsBTBkw EADHKqmP1Gdp6nvzzTePHj2q/1WW+rEnJSVFOjNw4MBXHjt27JiUS94bPnx4vXr1PvzwwwcPHpip qd9aXFych4dHtalP6rdo0WJWlXfeeUea/fTTT2ua+jRXKkaMGNG5c2flgpslqa/azluy4capb+fO nf379+9dpUOHDmo733//vX5nTDUOno0ApgwYCIBjldRH6vsVS77NRTP2XL16VTqzb98+zYcfOXLE zc1t7dq1ZmrWNPWVl5dLnffff3/dY8HBwV26dFFT36pVq5TlhQsX1jT1bdiwQZLqqVOnzOyrmqY+ SzbcIPWlp6dLN/bv3y/LW7ZsUVKf0s769ev1GzG///G84xsRAKYMAwFwrJL67GfgnuUvN5hPfSIg IGDo0KHKmzlLSkqUd4EePXpUp9NVVlb2798/OjraTE1TwSkqKkrzOy2TkpJatWqlflZQKN/polzj Cg8Pj4yMLC0tjY2Nbd68uZr6DFrTXKkkqMaNG0vNe3okZNYi9RmsrtoNN0h9qampkvoyMjKys7Mn TpzYsmVLpVwa8ff3P3PmjCxfvnxZ+fJSzcYBAAAAm0x9NsyqU58kk5CQECcnJ19fX3d39yNHjkhh p06dJKt4e3uHhoaq75bUrGkqOJ07d04a8fLyUi55qUaPHj137lyDLvXo0WPy5MmycOjQofbt2zs7 O4eFhS1btkxNfQataa40Jibmd0YOHz5ci9RnsLpqN/yR0Ts8pf8NGjRo167dxo0bXV1dlS90uX37 tjxKeuXi4uLp6al8VYxm4wAAAACpj9RXA6W5BdXWKS4uzsnJ0S8pqmJJTTMk51jyc3z6ysvLNX9x oXat1YXB6mq04Y+qfqdBeXhJFbX8l19+Md7AmjYOAAAAUh9IfY90xfd/XLAuwS2Yj2UDAAAApD48 36nP4DORdw6d+Xbw9K1OAyXvKTfGAHj6+EYEgCnDQAAcq6Q++xm4p/TLDfoX9wxunBeAp4+pBzBl GAiAY5XUZz8D9zRSn8HFPVIfwEkNYMqAgQDHKqmPgbOR1Je157ipsMeNGzdu3Lg9RzdexfKCDOBY JfWR+sztu8srv0r2eyuhdfBOj1E8jwKc1ACmDBgIcKyS+hg4m0p96mci7xxKO/n2J9saDU7qOHZb w8GkPuAZ4hsRAKYMAwFwrJL67GfgnvYvN5TmFhhc+uO8AAAAAJD6YDupT6Vc+iP1AQAAAKQ+2Gbq U5TmFjAGAAAAAKkPNpv6AAAAAJD68HynPj54DVghJibAlGEgAI5VUp/9DNzT+OUGZj5gbZiYAFOG gQA4Vkl99jNwpD6AZyMATBkGAuBYJfWR+th3AM9GAFMGDATAsUrqI/Vx0AOc1ACmDBgIgNTHwNld 6uOD14AVYmICTBkGAuBYJfXZz8Dxyw0AAAAASH22jNQHAAAAgNRH6gMAAAAAUh+pDwAAAACpD3aX +vjgNWCFmJgAU4aBADhWSX32M3D8cgNgj5iYAFOGgQA4Vkl99jNwpL4nr7Ky8uHDh09hRTqdrqKi 4nncnKfTczAxAaYMAwFwrJL6GLhnmfoSExNjYmI2btwYHx+fkZFhS/t0+/btLVu2rHs7SUlJaWlp ZioMGTJEhux52Zwn2PNq9wx4NgKYMgwEwLFK6mPgnn3q69evX/fu3SMiInx8fBwdHRMSEp7aNmdm Zl6/ft0KY5JBx8aPH79y5UrbSH0Gm1bHnle7Z8CzEcCUYSAAjlVSHwP39FKfqc9ESuqbN2+esjxs 2LDg4OCnts2jRo2aM2eOFcakmnbsOUp9Bpv2dHqOWkxMAEwZBgLgWLXb1Me3uTx5+qnv3Xff9fLy koVJkyatWrVqxowZEjMKCwvv3r07duxYWe7SpUtKSopSOTU1dfjw4VIoD7lz545SqFlTWouOjl6y ZInUHDRo0MmTJ6Vw6dKljRs3lpp+fn67du0y6FVeXt6UKVPat2/ftGnTXr16qe1U26vc3NwxY8a4 uLjIo+bOnavGpLp0TKqtWbNGeYjUHzx4cKtWrQIDA5X6BtlJc7fo02xBsydmNqfaBkNDQ+Pi4pTl 2NhYaURz05SeG69X9r90yd3dvU2bNpMnT87Pz9ccAnXP6HQ6v19Tjl7N3Q4AAABSn3169qnvypUr zZo1mzZtmhIG3NzcVqxYkZ6eXlFRIXFi6tSp8ip/3bp1/v7+ygMlJEgAqKys/Pnnn8vKypRCzZrS Wtu2bWfNmnX+/HnJAGFhYVJYXFwcFBQ0c+ZMCQalpaUGvZJ2fH19k5OTpeULFy6o7VTbq9dffz04 OPj69eu3bt2S5KPGpLp0TD/UxcfHnz17VsonTJgwbtw449SnuVv0mWrBuCdmNqfaBrt166Ym1ZUr V/bs2dPUpmmuV6oFBARcrDJs2LARI0ZoDoH+ht99bMOGDfXr1z906JCp3Q4AAABSH6nvaac+Hx+f rl27Ojg4hIeHFxUVKS/up0+frlS4du2adCYhIUECQFpampOTU3Z2tpS/9tprSiBRmzJVU1qLjIxU 6mzatMnT01NZNvVGSqUd4w+MVdurmzdvSqFkRaWO+pbIOnZM822Q69ev9/b2Nq5gvFtMMWjBuCem NseSBjVTn+amGa83IyND1qtegE1MTJS7N27cMBgCzT1z+vTpRo0abdmyxcxuBwAAAKmP1Pe0U9+b b7559OjRrKwszVfzKSkp0pmBAwe+8tixY8ekXILN8OHD69Wr9+GHHz548MBMTf3W4uLiPDw8zKc+ pZ3vv//eOPWZ79Xhw4elUN0QNSbVsWP61Xbu3Nm/f//eVTp06GBcwXi3GKi2BbUnpjbHkgYtT33G 61V2l7reW7duyd0jR44YxzyDu5IM27Rps3DhQvNHDgAAAEh9pL5n9m0umq/mr169Kp3Zt2+f5sMl DLi5ua1du9ZMzZqmPqWd9evX17RX2dnZDg4Ox48fN4hJdeyYWi09PV3i3P79+2V5y5YtmpnNeLfo s6QFtSemNseSBiX1rVq1SlmWGFaj1Hfp0iXZXQcPHlTK9+7dK3evXLliPvUVFhbKSseNG1dZWWnJ kQPzExMAU4aBADhW7Tb18W0utWfmlxvMpz4REBAwdOhQ5V2LJSUlyrtAjx49qtPp5CV+//79o6Oj zdQ0Fa6ioqKksmavpNzf3//MmTOyfPnyZeWXxC3pVZ8+fSZNmpSfn3/69OkePXqoMakuHVOrpaam SsTKyMiQPDZx4kS1cf12NHeLypIW9HtianOqbTA8PDwyMrK0tDQ2NrZ58+Zq6jO1afrrlb0t650w YYLspYKCgoiIiL59+ypZzlTqk00ODg4eOHCgweVNzd0OSyYmAKYMAwFwrNpt6uOXG55N6pNEERIS 4uTk5Ovr6+7urrzZr1OnTpIxvL29Q0ND79+/b6amqUhz7tw5acTLy0u5VKXv9u3b8ijZCS4uLp6e nsbfqmJqXcnJyc2aNZNCCY1r1qxRU1BdOqZfLSwsrEGDBu3atdu4caOrq6vy7Sn6FTR3i75qW9Dv ianNqbbBQ4cOtW/f3tnZWf66bNkyNfWZ2TT99aanp0vSk7jYpEmTAQMGKBf6zKS+EydOyGA1atSo xWOTJ082tdvBKyeAKcNAAByrpD5S31NNfZYrLi7OycnRLymqYklNMyTgKZfyjP3yyy8FBQU17ZVO pzO19ifSsby8PKW8pIpxBVO7xfIWLNwc8w2Wl5eb2ntm9rlBs9Xu/9odOeCVE8CUYSAAjlVSH6nP GlMfAE5qwG+tNLeAKcO5C+BYJfWR+mqJD14DVoiJCRg/0+9/eXLWN8eZMpy7AI5Vu019fJsLAAA2 nvrkttVxwPZmQ9Jmf27+0h8AgBBB6gMA4LlMfeptq2N/M5f+AACECFIfAOD/Z+9c4Gu60v4vohRB XSLRXNoIqZa41LgPDRFxCSaYkNFM1KtGtKrxKsW8tPW6zPQiQmlRzX/07UynNClJXapBNN4q6bSl jLgLCRJJiSHk0v8z1ts9Z87Z++TkgpNzvt/P+vjsvey91trreZ611i/7cqBmqz5u/QEAoPpQfVWd R0kkEolEqlnp3MdfsGgAAED1ofr04cVrADuEwASw/jfKrR0ivxw1+7PHxya3GXVkScLfXoqnixi7 APBVh1d9fM2lSvMokQ9ghwtcOgHAUvVtdHsqbciLacNiNz0UnD7m5Yuf7y8rLiFkGLsA8FUnUX38 cgN9B8BsBODgQWF6c8/sRT5ChrELAF9F9aH6cHoABjWAGh8Upjf3CBnGLgB8FdWH6qPvABjUABwK 61/pJGQYuwDwVVQfqs8avHgNYIcQmACEDIYAwFdRfc5jOH6vDwAAAAAAUH2ODKoPAAAAAABQfag+ AAAAAAAAVB+qDwAAAAAAUH3gdKqPF68B7BACE4CQwRAA+Cqqz3kMxy83ADgjBCYAIYMhAPBVVJ/z GA7VB8BsBACEDIYAwFdRfag++g6A2QiAkAEMAYCvovpQfTg9AIMaACEDGAIA1YfhnE718eI1gB1C YAIQMhgCAF9F9TmP4fjlBgAAAAAAQPU5Mqg+AAAAAABA9aH6AAAAAKpAcXFxaWnpfW9GWVnZ7du3 jf730qVL+fn59tASAFQfoPoAAADsgqSkpDVr1qxdu3bTpk2nTp2iQ6wQFBQky4zKnZucnJyRkVEt zdi4cWPTpk0t82/dujVo0CB/f39vb++jR4/egw4xagkAqg9qpOrjxWsAO4TABKiWkOnevXvHjh0j IiJat25du3btxMTEe9akrKysM2fOOInqGzdu3LJly5QhzC68ov1gpLV27NjxyCOP3MsOKVf11TgT gzPPs3zNBdXHR5YB7BECE6BaQkZU3+zZs9X2gAEDQkND71mThg8fPmPGDCdRfaaGMLvwivaDkdaS tvXv39+uVF+NMzE48zzLLzeg+lhcAjCoATiF6ps6daqvr69sREVFxcXFTZkyRdb0V69evXz58qhR o2S7Xbt2qamp6uD09PSQkBDJlFMuXbqkMnWPlNLi4+MXLlwoR/bu3Xv//v2SuWjRooYNG8qRAQEB mzdvNmtVWFjYhg0b1HZCQsLIkSMrUanpJRh1i26BRrWL6ps/f/6LL77o4eHRpk2bpKQk0wucN2/e ww8/3LVr18zMTDm9bdu2TzzxRHJysnbMihUrZGNcLW/TC7fsB93Lyc3NlWY0a9asS5cuM2fOtNRa b7/9tvxvgwYNpJy1a9dKTl5enlQqTfX09IyOjtZe9jPrGVsab4pRS6SQvn37tmjRYuDAgUYmtjwG mGdRfRgO1QcABCbAvVN9x48fb9y48bPPPqvkjbu7+9KlS0UDlJaWyhp90qRJohBWrVoVGBioThT9 JuKhrKzs9OnTt27dUpm6R0pprVq1mjZt2uHDh0XPhIeHS2ZhYeGgQYNiYmJE5BQVFZm1qkOHDkoj CcuWLevcuXMlKjW9BKNu0S3QqHYp09vb+6233vr+++8nTpzYvHnzkpISlS/K6rXXXpNC+vTpI4Lw N7/5zd///vfnnntOulc7V90nTKjV1fTCLftB93IGDx4cGhp65syZ8+fPiyi1VH3/+Mc/YmNjf/nL X0o5N27ckBwpNjg4+MgdBgwYMGTIEN2esaXxphi1ZNOmTd9++61cwvjx48eOHatrYstjgHkW1Yfh UH0AQGAC3AvV17p168cff9zFxWX06NHXrl1TwmDy5MnqgJMnT8rEmpiYKOIhIyPD1dU1JydH8vv1 66dW/1pRRkdKaZGRkeqYdevW+fj4qG0rj/8Z6a4KVapdgmizg//OuXPnjAq0rvpefvlltZ2Xlyf1 7tu3T+VPnTpV5csBXbp0UTpzy5Yt9evXN1N91p/w1L0caa1kpqSkqGOMnqv8/e9/L+pObZ86dUpO 0W6iJiUlye7Zs2fNesbGxmvY0pLVq1f7+flZN7HpMcA8i+rDcPai+vhoBIAdQmACVEvIiOobM2ZM Wlpadna2qRLQXmBLTU2VibVXr159fmbv3r2SL0opJCSkTp06s2bNunnzppUjTUvbsGGDt7d3pVVf 5Sq9fv36wH9n5cqVRgVaV32m7/W1bNly+fLlZvlz584NDg5W28nJyZaqTwxhRfXpXs7u3bslUzOQ LapPlaOdcv78ednds2eP5VXY0ngNKy359NNPe/To8eQdHn30UV0T6x4DzLOoPgxnL6oPAADAUTF9 r09XCZw4cUIm1u3bt+ueLkLC3d1diSijIyun+uLi4tT2vHnzNN1VuUrLxbRAK7Wblpmbmyv1iuyp qOqzvHDTXd3LycnJcXFxUfcVbVR9R48elXJ27typdrdt2ya7x48fr6LqM2pJZmamKOcdO3bI9vvv v6+r+oyOAUD1AaoPAADgPqs+QZRA//791WOQ169fV0+BpqWlFRcXl5WV9ejRIz4+3sqRRqovNjbW 6JuTo0ePjoyMLCoqSkhIaNKkiaa7KlepFXQLNKpdyhw4cGBBQUFJScmSJUuaN29uWZctqs/sws12 dS+na9euUVFR+fn5Bw4c6NSpU7mqr7S0VE4ZP368nC4NjoiI6Natm1xmFVWfUUvS09NF0Z06dUpk 4dNPP601z/TSjI4BQPUBqg8AAOD+qz5Zpg8dOtTV1dXf39/Dw0M9KNi2bVtZuPv5+YWFhanPhxgd aaT6Dh06JIX4+vqq+z+m7Nq1y8vLq169euHh4YsXL9Z0V+UqtYJugUa1S5njxo177LHH5BLc3d21 O2kVVX1mF262q3s5KSkpjRs3lszAwMAVK1aUq/p+unNvTZSeqFY3N7eePXuqG31VV31GLZG+evDB Bx9++OG1a9eKHlYfazG7NN1jAFB9gOoDAACwFwoLCy9evGiac+0OthxphQsXLuh+Y7OkpKSgoMAy v1oqLbdA3dqvXr1669atsrIyabO6b1YVzC7cbNfycoqLiytxgXl5ebrdWBWMWiJ1qUu4fgfdSzM6 Bu4LRbkFdAIiAtX3L/hoBIAdQmACEDIYAqAq/KVW9x2/iM7+bB+++hNfc0H1/cQH4gHsda6iEwAI GQwBUBVvlPRR7Z4bGwdlTH/L7NYfv9zAIIPqAwAGNQBCBjAEOILq09JHtXuY3vpD9THIoPoAgEEN gJABDAEOpfrMbv2h+hhkUH0AwKAG4AjLOxKJRLKSzn38BaqPBZITqT5evAawQwhMAEIGQwBU4x+D tnaI/HLU7M8eH5vcZtSRJQl/eyneqXqDr7mg+gAAAAAAHFP1bXR7Km3Ii2nDYjc9FJw+5uWLn+8v Ky5xwt5ARKD6AAAAAAAcUPWZ3txz8p/vQ0Sg+gAAAAAAHFD1OfPNPVQfqg8AAAAAwMFx8pt7qD5U nzm8eA1ghxCYAIQMhgDAV1F9zmM4frkBwBkhMAEIGQwBgK+i+pzHcKg+AGYjACBkMAQAvorqQ/XR dwDMRgCEDGAIAHwV1Yfqw+kBGNQACBnAEACoPgzndKqPF68B7BACE4CQwRAA+Cqqz3kMxy83AAAA AAAAqs+RQfUBAAAAAACqD9UHAAAAAACA6kP1AQAAAAAAqg+cTvXx4jWAHUJgAhAyGAIAX0X1OY/h +OUGAGeEwAQgZDAEAL6K6nMew6H6AJiNAICQwRAA+CqqD9VH3wEwGwEQMtVHWVnZ7du36dgaNHYV FxeXlpbe+3ovXbqUn5+P6fFVVB+GQ/UBAIEJcH9CJikpac0dPv/881u3btle4MaNG5s2baq2k5OT MzIy7O2SRZdu2bLl1VdfjYmJ+cMf/rBp06Yff/zRTgzxl7/85dtvv9Uyz5079+c//9m6RRITE/fv 36+r5T777LMXXnhh6dKlu3btslJ1UFCQLJPu5cVK+wcNGuTv7+/t7X306NFKlGDFP+3TvsyzqD4M V4NVHy9eA9ghBCZAtYRM9+7dO3bsGBER4evr6+bm9uWXX1ZC9Y0bN27ZsmVVbGFWVtaZM2cq+l9G 5OXlBQcHi9iYM2fO22+/HRsb2759+9TU1GpsVVUM0bp16yVLlmiZKSkpjzzyiHWL/OIXv5g1a5Zl gcOGDevRo8cbb7zx29/+dsyYMXal+nbs2KFdV+Uw6o3qsi8wzzqe6uNrLgAAAKCzqp49e7bafvLJ J0W/VUL1VQvDhw+fMWNGRf/LiMmTJ/v5+V2+fNk0s6ysrBpbVRWsqz5di+iqvuPHj9euXTs7O9uW Su+96pPq+vfvfzf8s7rsC4CIQPUBAAA4l+oThTNixAi1LevpUaNGia5r166ddgslNzd35MiRzZo1 69Kly8yZMzXVFxUVtWLFCm07Li5uypQp8r9Xr17VLScvL2/ixIleXl6NGjWSoiRn0aJFDRs2lMMC AgI2b95s2kLL/5LTpRYPDw9PT8/o6GjLd8YkR7TQmjX6f/AOCwvbsGGD2k5ISJArUtvp6ekhISFS ka+v76VLlypUtWTGx8fPmzfv4Ycf7tq1a2ZmplTRtm3bJ554Ijk5udKqz9QiuqovKyvLxcXlvffe M8u37GFN9S1cuFAusHfv3trzoro2suWKdE/UePvtt8VVGjRoIL23du1a671n6jPl+qd1+wKg+lB9 AAAAoKP6ZPkua/q6det+8sknKn/gwIGTJk2SJfiqVasCAwNV5uDBg0NDQ8+cOXP+/HnRTprqM72J JNvu7u5Lly4VnVBaWqpbjmT6+/uL1Ll169YPP/wgOYWFhYMGDYqJiZGWFBUVmbbQ8r9kNzg4+Mgd BgwYMGTIELOL+uqrr2Qx8N133+lecocOHTSNumzZss6dO6ttEUKiPcrKyk6fPq1eIbO9arlqUTKv vfaanNunT582bdr85je/+fvf//7cc89JD1dC9VlaxOgJzzlz5ojwmzBhgmhyLdOyh1UjW7VqNW3a tMOHD4taCw8Pt2JrW65I90SNf/zjH7Gxsb/85S/lWm7cuGG990x9plz/tG5fAFQfqg8AAADMVV+9 evVENsjsuWPHDpV58uRJ2U1MTJTVeUZGhqura05Ozrlz5yRThIQ6xvQJTzPVN3nyZCvlqEzL9wBt fMLz1KlTcrp2PzApKUl2z549a3r8li1bJDMrK6tCqq9fv35K01aiarnqqVOnqvyXX365S5cuSr1I S+rXr19R1WdpESuqT7VEFJqXl5d67c2oh6WRkZGRanvdunU+Pj5GNrLlioxONOX3v/+9qDtbek/z GVv807p9AVB9qL5KwkcjAOwQAhOgWkJGVtWxsbGXLl3y8/N7/vnnVWZqaqpMpr169erzM3v37t29 e7dkaq+QWVF92rZuOSrzm2++qZzqU6drzTh//rzs7tmz598u9tAhyZS6KqT6RO+FhITUqVNHxNXN mzcrVLXpVc+dOzc4OFhtJycnm6k+ZYiAgIBXX33VVKaKDrRiEeuq76c7Dz0OGzZM6iosLDTqYdNG btiwwdvb28hGtlyR0YlGqs/G3rPFP63bF5hnnVz18TWXysMH4gHsEAIToFpCRntvSkRd7dq11Stb J06ckMl0+/btpkfm5OS4uLjs27fPdtWnW47KXL16deVU39GjR+X0nTt3qt1t27bJ7vHjx02PLyoq at68+bPPPmuk+uLi4tT2vHnzNNWnEB3i7u6+cuXKClVtu+pThjB7MHX9+vWimqxYpFzVJ5w9e1ba s3XrVqMe1lV9ujay5YqMTjRSfTb2ni3+ad2+wDzr5KqPX26g7wCYjQAIGcNVtTB9+nQRPOo5PVnl 9+/fXz3ueP369WvXrslG165do6Ki8vPzDxw40KlTp3JVn1E5khMYGHjw4EHZPnbsmHp0MDY21uh7 j6b/JQdLM8aPHy9FFRQUREREdOvWzfLjjaJ5XF1d33zzzZKSEnXWli1bpC7ZHj16dGRkpCiHhISE Jk2aaKovLS2tuLhYiurRo0d8fHyFqq6o6lu8eLGbm5t0o5LTUsWcOXOsW0RX9R05ckTk0O3bt5V0 rFOnzsmTJ416WFf1GdnIlivSPdFI9dnYezb6pxX7AvMsqg/VR98BMBsBEDKGq+obN24EBAQMGjRI 1uKyth46dKgsrP39/T08PNSTeCkpKY0bN5ZMURQrVqywRfXplnPhwgU5TObrZs2a+fj4qA+lHDp0 qG3btr6+vqYvsynM/iszM1MEgwg2EU49e/Y0u9Gn8d577zVv3lwkymOPPSYKJywsTKmCXbt2eXl5 1atXLzw8XNSXpvqkCrkiPz8/OVJ9fcT2qiuq+qR8kT3SA61btxapNnDgQO2DlkYW0VV9SUlJDRo0 aNSokTRSTvzwww9Vvm4PG6k+XRvZckW6JxqpPht7z0b/tGJfYJ5F9aH66DsAZiMAQkaHotwC3fzC wsKLFy+a5hQXF5vl2IJlOcKVK1cKCszrFbli9hVHo//Ky8uzPN2SrKysI0eOmN0MLCkp0T332h2q q+pyDSHlZGRk2Phre0ZIw06cOKFbiG4PV8hGd+PEqvSejfYF5llUH6qvMvDRCAA7hMAEqHrIFBfe +H7uqkT3UP6MwtgF4OS+ytdcUH0AAACOxqVdB7/oO/kj116i91SiTwDAmUFEoPoAAAAcBNObe2aJ zgEAVB8iAtUHAABQg7G8uYfqAwBARKD6AAAAHITsrfuMxB6JRCLxxyBEBKrvn/DiNYAdQmACVIi/ vRR/bNmfUwJ+ndgy9FPv4dzrY+wCwFcdUvXxNZfKw1wIYIcQmACVC5lLuzL2T3jt4wZ9k9uM+rh+ X1QfYxcAvvoTv9yA6mOABmBQA3C8kCnKLTC79UcXMXYBoPpQfag+AGBQA3DAkFG3/ggoxi4AVB+q D9XHAA3AoAbgyCFTlFtAFzF2AaD6UH1Orfp48RrADiEwAQgZDAGAr6L6nMdw/HIDAAAAAACg+hwZ VB8AAAAAAKD6UH0AAAAAAACoPlQfAAAAAACg+sDpVB8vXgPYIQQmACGDIQDwVVSf8xiOX24AcEYI TABCBkMA4KuoPucxHKoPgNkIAAgZDAGAr6L6UH30HQCzEQAhAxgCAF9F9aH6cHoABjUAQgYwBACq D8M5nerjxWsAO4TABCBkMAQAvorqcx7D8csNAAAAAACA6nNkUH0AAAAAAIDqQ/UBANRMysrKbt++ beeNLC4uLi0tdYxa8AoAAFQfoPoAwK5JSkpac4fPP//81q1b1VVscnJyRkbGfWnYxo0bmzZtWl3N uEudEBQUJMOvLYXk5ORIJ1y8eLESDbC9lrtkxOo1gSi3LVu2vPrqqzExMX/4wx82bdr0448/VsIr AAAA1YfqqwZ48RrADjEKzO7du3fs2DEiIsLX19fNze3LL7+slurGjRu3bNmyqpRQ6YaZru+r3gwh KyvrzJkzVewEs0Js12Nz586VUXr+/PmVaGoVVV/les+sDdViAiEvLy84ONjb23vOnDlvv/12bGxs +/btU1NT757qYy6z87ELAF9F9WG4+6z6+MgygB1iFJgirmbPnq22n3zySVmj20mDK92war+rM3z4 8BkzZlRvITbqseLi4latWgUEBPj4+NjyrGblaqleqqW7LJk8ebKfn9/ly5dNM8vKyu6eVzCX2fnY BYCvovowHKoPACqj+mS9PmLECLUty+tRo0bJQrldu3baHZW8vLyJEyd6eXk1atSoS5cuVo6Miopa sWKFbMjxb775plbdc889t3r1aqOzKt2w3NzckSNHNmvWTFo1c+ZMbX2vNUNtx8XFTZkyRf736tWr Nl7gokWLGjZsKIeJ9Nq8ebNpC8PDwz/44AO1PXXq1F/96ldqOy0tbcyYMaa1Wxai9NjChQt9fX17 9+69f/9+XeskJia2bNny66+/loF669atWn5YWNiGDRvUdkJCglx7hWqRy5S2eXh4eHp6RkdH5+fn 63aR1n4RnwH/jpo14uPj+/bt26JFi4EDB6rCLdtgagIr9UpRVnpDjqxdu/aaNfp/jjUq1sgryvU9 5jIWZAD4KqoP1YfTAzig6pN1sKiIunXrfvLJJypf1vGTJk2Spf+qVasCAwO1TH9//5SUlFu3bv3w ww9WjtTuMq1fv97Pz0/dk5FVeP369dXjf7pnVbphgwcPDg0NlZLPnz8vikhb35ve7JJtd3f3pUuX ZmZmlpaW2niBhYWFgwYNiomJkZYUFRWZtlCap5SeHNy8eXNXV1elN+RgETCmtVsWIv/VqlWradOm HT58WBSICEhd6wwdOlRJ327duo0ePVrL79Chgyalli1b1rlz5wrVIocFBwcfucOAAQOGDBmi20Wm vXf5Z9555x0xx65duyRz06ZN3377rdQ1fvz4sWPHGrVBK8RKvdZ746uvvpKp6rvvvtPtJaNijbyi XN9jLmNBBoCvovpQfTg9gKOpvnr16rm4uMhQsGPHDpV58uRJ2U1MTJRldEZGhuiZnJwclWn2jpbu kWaCp2HDhrt375btN998UxbiVs6qXMPOnTsnmSLV1DGmz/KZqb7JkydX9AJ/Mn5kUS6qUaNGt2/f 3rZtmyiNTp06SdUiljw9PY8ePWpWu+Wzl5GRkWp73bp1Pj4+luWfPXtWGnb8+HHZXrNmzQMPPHDp 0iUrqs/GWk6dOiWXqd23TEpKkl2py6yLftJ7QPTAgQMNGjR4//33zZq6evVq0fZGbVCFWK/Xem9s 2bJFDs7KyrLsJaNijbzCFt9jLmNBBoCvovpQfeXDi9cAdoiVr7nExsaKnJBV+/PPP68yU1NTZWTo 1atXn5/Zu3evyvzmm29MT9c90kww/Pa3v42OjpaNdu3abdq0ycpZlWuYqC/JzM7OLlf1adu2X6AV 1VdcXNykSRM5KyYm5p133nnppZd+97vfpaWltW/f3rJGK2/cbdiwwdvbW3dCfeihh6bd4ZlnnpG2 vf766xVVfZa1qMvUuuv8+fOyu2fPHkuZZ7YrUkoE7bx587ScTz/9tEePHk/e4dFHH7XeBhvr1e2N Q4cOycGWTmKlWCOvsMX3mMtqxNgFgK+i+jDcfVZ9AFCD0F6fk1Vy7dq1k5OTZfvEiRMyMmzfvt30 SJWp3sozyzQ70lJiNWzYMCUlRTSDKCUrZ1WuYTk5OS4uLvv27bNd9dl+gT9Z/TzJmDFjZs6c6ePj I+pi586drVu3nj59um6NFVV9JSUlkvnCCy+s+pnQ0FCRzZrqi4uLU9siwyqk+o4ePSqXKa1V+du2 bZNddUfRiuq7evWqVDp27FjtAyqZmZl16tRRt2Hff//9clWfjfXq9kZRUVHz5s2fffZZSxMYFWvk Fbb4HgAAOI/qc2BQfQCgI64EUSzu7u7qgbfg4OD+/furd/CuX79+7do12ZCcwMDAgwcPyvaxY8fU VyV1jzRdx4tOeOSRR1q2bDlnzhytXt2zKt2wrl27RkVF5efnHzhwoFOnTuWqvgpdYGxsrOTr9t76 9eubNGnSs2dPpUwaNGggu4cOHbKs0ayQcnWOqNwWLVqY/lCh+qaLujE1evToyMhIqTEhIUFq1FSf LbXIRUl3jR8/Xi65oKAgIiKiW7duSssZqT7R6qI5e/XqdfPmTe1/09PTRfWdOnVK7PL0009rfW7U BhvrNbrzKWrc1dX1zTffFD2sStuyZYuykVGxRl5Rru8BAACqD9UHAA6r+m7cuBEQEDBo0CBZNMtS fujQobLO9vf39/DwUE/iXbhwQRboMmg0a9bMx8dHfa5D90gz/fBf//VfLi4uJ0+e1HJ0z6p0w1JS Uho3biyZotlWrFhhi+qz/QJFxbVt29bX11d7vVAjOztbrmvJkiVqd8iQIY899piu6DIrpFydM2LE iJkzZ5plinRRz8ru2rXLy8urXr164eHhixcv1lSfjbVkZmaKNBK56ObmJpJV3XCzovrUx1RE0z70 M6oZUvuDDz748MMPr127tnnz5uqDLlbaYEu9RqpPeO+996SW+vXrSyfLMWFhYaL6rBRr5BXl+h4A AKD6UH0A4EQUFhZevHjRLPPKlSsFBQW2HFm58it3YnFxcXU1QPcCRRDa8ot51qmWQhQlJSWWjaxQ LXl5eUYl2I4Uouq6fgdb2lDFerOyso4cOWL5S326xVrxikr7HgAAICJQff+EF68B7BDrgVmUW0AX ATCXYQgAfNXZVB9fc6k8fGQZwA7RDcziwhvfz12V6B5K2AIwl2EIAHzVCVUfv9xA3wE48mx0adfB L/pO/si1l+SrRBcBMJdhCAB8FdWH6qPvAGr8oGZ6c88s0UUAzGUYAgBfRfWh+ug7gJo9qJnd3EP1 ATCXYQgAfBXVh+qrJLx4DWBvZG/dZyT2SCQSfwqxZ1hUAL6K6sNwdqr6AMAOKcotOLbszykBv05s Gfqp93AWuAAAAIDqc2BQfQBOzaVdGfsnvPZxg77JbUZ9XL8vqg8AAABQfag+AHBALG/90ScAAACA 6kP1AYADom79ofoAAAAA1YfqqwC8eA1gh1gPzKLcAroIgLkMQwDgq86m+viaS+XhpgGAHUJgAhAy GAIAX0X1OY/hUH0AzEYAQMhgCAB8FdWH6qPvAJiNAAgZwBAA+CqqzwFUX3R0tBgsKChoQfUxppbX AgCwMwhMAEIGQwDgq9XFU089JSJiwoQJqL6aofqUwQAAAAAAACpEUFBQTZdGzvI1l+XLl4u1RKa/ AgAAAAAAYAMiH0REiJTg4d6aofoAAAAAAAAA1QcAAAAAAACoPgAAAAAAAHAG1efA70QC1FwITABC BkMA4KvgPIa766qPn9YBsEMITABCBkMA4KvgPIZD9QEwqAEAIYMhAPBVQPXRdwAMagCEDGAIAHwV w6H6cHoABjUAQgYwBAC+iuGcTvXxMiuAHUJgAhAyGAIAXwXnMRy/3AAAAAAAAODIoPoAAAAAAABQ fQAAAAAAAIDqAwCwT4qLi0tLS+kHoays7Pbt2/QDAAAAqq864WVWADvEKDCTkpLWrFmzdu3aTZs2 nTp1yq7anJOTI227ePFiJc4NCgpasGBBpatOTk7OyMioYvurpRBNuW3ZsuXVV1+NiYn5wx/+IMb6 8ccfbTx348aNTZs2JQSYyzAEAL4KTmU4frkBwBkxCszu3bt37NgxIiKidevWtWvXTkxMvGdNysrK OnPmjJUD5s6dW6tWrfnz51eitCqqvnHjxi1btqyKV1S5QizJy8sLDg729vaeM2fO22+/HRsb2759 +9TUVFQfcxmGAMBXAcOh+gDAJtU3e/ZstT1gwIDQ0NB71qThw4fPmDHD6H+Li4tbtWoVEBDg4+Nj y7OaZqVVUfXdjSuqNJMnT/bz87t8+bJpZllZGaqPuQxDAOCrgOFQfQBQMdU3depUX19f2YiKioqL i5syZYqohatXr4reGDVqlGy3a9dOu8WUnp4eEhIimXLKpUuXVKbukVJafHz8woUL5cjevXvv379f MhctWtSwYUM5UnTd5s2bLRuWmJjYsmXLr7/+ulatWlu3btXyw8LCNmzYoLYTEhJGjhypW5pSfWaV /nTnvpm0x8PDw9PTMzo6Oj8/X2uk6SXL7ooVK5T4DPh3XnnlFcmXK+rbt2+LFi0GDhxodEVaIdbr tewcU+TI2rVrr1mj//yJUbG5ubnSM82aNevSpcvMmTM11adrIGAuwxAA+CqGQ/XRdwBOofqOHz/e uHHjZ599Vkkmd3f3pUuXZmZmlpaWirCZNGmSaKFVq1YFBgaqE0WiiEwqKys7ffr0rVu3VKbukVJa q1atpk2bdvjwYZEc4eHhkllYWDho0KCYmBjRIUVFRZYNGzp0qGpYt27dRo8ereV36NBBk1LLli3r 3Lmzbmm6lQpyWHBw8JE7DBgwYMiQIVojTS/Z9Fbh5Z9555136tatu2vXLsnctGnTt99+K3WNHz9+ 7NixRm3QCrFSr247Nb766ivRvd99952u+YyKHTx4cGho6JkzZ86fPy86WVN9ugYC5jIMAYCvYjhU X4XhZVYAO8QoMEX1tW7d+vHHH3dxcRFxde3aNSVFJk+erA44efKkqI7ExETRFRkZGa6urjk5OZLf r18/pSu0ooyOlNIiIyPVMevWrfPx8VHbVp6HPHv2rJwuQlS216xZ88ADD2i3E3VV3096T3haVnrq 1ClpoXZrMSkpSXalLrNL/knvAdEDBw40aNDg/fffN2vq6tWr/fz8jNqgCrFer27naGzZskUOzsrK suwlo2LPnTsnGykpKSpfe8LTyEDAXIYhAPBVDIfqAwBHRlTfmDFj0tLSsrOzdTVPamqqSIVevXr1 +Zm9e/dKvui9kJCQOnXqzJo16+bNm1aONC1tw4YN3t7e5ao+Of6hhx6adodnnnlGin399dcrqvos K1Ut1K70/Pnzsrtnzx5LmWe2K1LK09Nz3rx5Ws6nn37ao0ePJ+/w6KOPWm+DjfWads6/ZqNDh+Rg 1ZNmGBW7e/du03xN9RkZCAAAAFB9AODgqk97r09X85w4cUKkwvbt23VPF43h7u6+cuVKK0dWVPWV lJTIMS+88MKqnwkNDW3Xrp2m+uLi4tS2yLAKqb6jR49KC3fu3Knyt23bJrvqjqIV1Xf16lWpdOzY sdoHVDIzM0Xu7tixQ7bff//9clWfjfXqqr6ioqLmzZurJ2/NMCo2JyfHxcVl3759ZqrPuikBAAAA 1QcATqr6hODg4P79+6uHOa9fv66eAk1LSysuLhYh1KNHj/j4eCtHGgmb2NhYOdiyScnJyS1atNDe FRTUN13UjanRo0dHRkaKFkpISGjSpImm+sxK0620tLS0a9eu48ePl4YVFBRERER069ZNaTkj1SfX KJqzV69e6n6mIj09XVTfqVOnRF89/fTT2ltzRm2wsV5d1ffTnYdIXV1d33zzTdHDqrQtW7YcO3bM SrGSHxUVlZ+ff+DAgU6dOmkt1DUQAAAAoPoAwNlVn2iboUOHivDw9/f38PBQjya2bdtWtISfn19Y WNiNGzesHGkkbA4dOiSF+Pr6qptmGiNGjJg5c6ZZk0S6REdHy8auXbu8vLzq1asXHh6+ePFiTfWZ lWZUaWZmpkgjkYtubm49e/ZUN9ysqD71MZUGDRo89DOqGVL7gw8++PDDD69du7Z58+bqgy5W2mBL vUaqT3jvvfeklvr16z/22GNyjPS5qD4rxaakpDRu3FgMERgYuGLFCk316RoIAAAAUH0VhpdZAeyQ qgdmYWHhxYsXTXOu3cGWI61w4cIFW36Oz5SSkpKCgoKqlJaXl2dUgu1IIaqu63ewpQ1VrDcrK+vI kSOWv9SnW2xxcbGRFSpkIEIGMASAoii3AF9lkEH1/Qs+XAtghxCYAIQMhgCoojfu+EV09mf78FUG GVQfTg/AoAZAyACGAMf0Rkkf1e65sXFQxvS3zG794asMMqg+AGBQAyBkAEOAI6g+LX1Uu4fprT98 lUEG1QcADGoAhAxgCHAo1Wd26w9fZZBxOtXHy6wANWWuIpFIJBKJVF3p3MdfsN6ocfA1FwAAAAAA 0P/76dYOkV+Omv3Z42OT24w6siTB+hc+AVB9AAAAAAA1Q/VtdHsqbciLacNiNz0UnD7m5Yuf7y8r LqFzANUHAAAAAOAIqo+be4DqAwAAAABwZNXHzT1A9f0LvuYCYIcQmACEDIYAqArWb+7hqwwyTqf6 +HAtgB1CYAIQMhgCAF8F5zEcqg+AQQ0ACBkMAYCvAqqPvgNgUAMgZABDAOCrGA7Vh9MDMKgBEDKA IQDwVQzndKqPl1kB7BACE4CQwRAA+Co4j+H45QYAAAAAAABHBtUHAAAAAACA6gMAAAAAAABUHwAA AAAAADid6uNlVgA7hMAEIGQwBAC+Cs5jOH65AcAZITABCBkMAYCvgvMYDtUHwKAGAIQMhgDAVwHV R98BMKgBEDKAIQDwVQyH6sPpARjUQCguLi4tLaUfCBnAEICvAoZzFtXHy6wAdohRYCYlJa25w+ef f37r1q3728icnBxpycWLF+9vMz788MM1ely/ft3olKCgoAULFuBmzhAygCEA8FUMh+oDgBpG9+7d O3bsGBER4evr6+bm9uWXX1o5OCsr68yZM3evMXPnzq1Vq9b8+fPvb5/MnDlz4h06dOjg7u4+8Wfy 8/NRfQAAAIDqA4Cap/pmz56ttp988slx48ZZOXj48OEzZsy4Sy0pLi5u1apVQECAj4+PnTwtKRfb s2dPW45E9QEAAACqDwBqgOoTUTdixAi1ffny5VGjRjVt2rRdu3apqamSs2jRooYNG0qOCLPNmzdL TlhY2IYNG9TxCQkJI0eOVNtRUVFxcXFTpkyRg69evSq78fHxCxcu9PX17d279/79+3VbkpiY2LJl y6+//rpWrVpbt27V8vPy8iZOnOjl5dWoUaMuXbpYybRss5Cenh4SEiKZUvulS5esZNqi+qReuRwP Dw9PT8/o6Gjt7p+m+n788UfZ/uijj6w0ycYOAQAAAED1AUC1qT4RJ6Lf6tat+8knn6j8gQMHTpo0 STTbqlWrAgMDJaewsHDQoEExMTFycFFRkeR06NBhxYoV6vhly5Z17txZk0Du7u5Lly7NzMwsLS2V 3VatWk2bNu3w4cMigcLDw3VbMnToUKU/u3XrNnr0aC1fWuLv75+SknLr1q0ffvjBeqZZmwWRVSJB y8rKTp8+rb24qJtpi+qTHggODj5yhwEDBgwZMsRU9UlRkildZNp4yybZ2CEAAAAA9qv6eJkVwA4x CkxRffXq1XNxcalVq9aOHTtU5smTJ2U3MTFRtE1GRoarq2tOTs5PFk94WlF9kydP1g6T3cjISLW9 bt06Hx8fy2acPXtWajl+/Lhsr1mz5oEHHlC34FRLpHDTg61kWra5X79+oaGhZq8j6maWq/pOnTol Vaj7nD/d+RCO7ErL1TXOnz//6aefHjZsWElJifUm2dIhYLchAxgCAF/FcKi+f8KHawHsEKPAFNUX GxsrEsvPz+/5559XmampqSJXevXq1edn9u7dWyHVZ/qSm+nuhg0bvL29LZshBzz00EPT7vDMM89I 7a+//rrWkm+++cb0YCuZlm0WaRcSElKnTp1Zs2bdvHlTHaybWa7qU1VkZ2er3fPnz8vunj171DXK kbKbnp5ebpNs6RCw25ABDAGAr2I4VB9OD1DzVJ96rnL37t21a9dOTk6W7RMnTohc2b59u9nBlqov Li5Obc+bN6/Sqq+kpEQyX3jhhVU/Exoa2q5dO60lq1evNj3eSqZlmxWizdzd3VeuXFluphXVd/To Uali586danfbtm2yq+5PqmucPn26p6entMR6k1B9rAMAQwC+ChgO1QcA90H1CSJaRAWppxCDg4P7 9++vnoG8fv36tWvXZCM2NlYytXNHjx4dGRlZVFSUkJDQpEmTSqs+kZotWrQwfb9OfdNF3RmTGgMD Aw8ePCjbx44dU5/31M3UbXNaWlpxcXFZWVmPHj3i4+NV+bqZ5ao+qaVr167jx4+XkgsKCiIiIrp1 6yaFaNco21FRUa1bt1Z9aNQkVB/rAMAQgK8ChkP1AcD9UX03btwICAgYNGiQqBfRLUOHDnV1dfX3 9/fw8FDPMR46dKht27a+vr7qDcBdu3Z5eXnVq1cvPDx88eLFlVZ9I0aMmDlzpllmp06doqOjZePC hQtSgojAZs2a+fj4qA/J6Gbqtlka3LRpUz8/v7CwMLlAVbhuZrmqT8jMzBSlJxLXzc1N/kvd6DO9 RhGTUmbHjh1FFho1CdXHOgAwBOCrgOFqvOrjZVYAO8R6YBblFujmFxYWXrx40SxTFJf2e3olJSVK 3txtrly5YlmRbqZlm6/dweww3UwbycvLq9BV63Yj1OiQAQwBgK9iOGdXfQBQUyguvPH93FWJ7qH8 hRIAAAAA1QcADsWlXQe/6Dv5I9deovdUok8AAAAAUH0AUOMxvblnlugcAAAAAFQfANRgLG/uofoA AAAAUH2VhJdZAeyN7K37jMQeiUQikUikakmsN2oifM2l8uD0AHaIBOaxZX9OCfh1YsvQT72HM1cB MJdhCAB8FfjlBvoOwDEHtUu7MvZPeO3jBn2T24z6uH5fVB8AcxmGAMBXMRyqj74DcMBBrSi3wOzW H10EwFyGIQDwVQyH6qPvABxwUFO3/ghbAOYyDAGAr2I4VF8F4GsuAHaI9cAsyi2giwCYyzAEAL6K 4VB9AAAAAAAAgOoDAAAAAAAAVB8AAAAAAACg+gAAAAAAAMD+VB8vswLYIQQmACGDIQDwVXAew/HL DQDOCIEJQMhgCAB8FZzHcKg+AAY1ACBkMAQAvgqoPvoOgEENgJABDAGAr2I4VB9OD8CgBkDIAIYA wFcxnNOpPl5mBbBDCEwAQgZDAOCr4DyG45cbwI5YtmzZU45OdHT0AgAAAACAu4OsNmXNuXz5clQf 2CmdOnWqBQAAAAAAVaNz586oPrBTxDuVm/7SEVGXFhQU9AoAAAAAwN3h0UcfRfWBXfPUU08pyZfv iMyePVuubsGCBRgaAAAAAO7qijooKOieqj5eZgVUnx2qPgITgJDBEAD4Kjik4e6P6uPDtXBXVd/U qVNHjBiRnZ2N6iMwAQgZDAGArwKGQ/WBA6q+xx9/XE45d+4cqo/ABCBkMAQAvgoYDtUHqL77SUxM DKoPgHUAYAjAVwHDofoA1Vd51ff3v/997Nixnp6ejRs37tOnz/bt29UxRvmDBw9u06bNtm3bunXr Jv81fPjwU6dO3SXJ9+2336pveKL6AFgHAIYAfBUwnKOpPl5mhXuj+i5fvtyhQ4fatWvPmjXr3Xff 9fDwqFev3v79+43ytXPbt2///PPPt27dWrbnzZt3NyTf4cOHH3nkESnf29v79OnT9tDVBCYAIYMh APBVcEjD3R/VB3BvVN+mTZtko1OnTipfNJ7sPvvss0b52rnp6emyvWvXLtnu3r373ZN8jz76qJ1I PgAAAABw7BU1qg8cU/W98cYbshEVFaXyP/jgA9kNCQkxyjd7OjQnJ0e2H3jggStXrlTvg52a5Dt+ /DgmBgAAAABUH+CjlVR9H374oWz06NFD5b/66quyGx0dbZRvpvrUvT5vb+/qlXz+/v5IPgAAAABA 9QFUg+o7f/68j49P3bp1V69enZqa+sQTT7i4uGzbts0oXzt30qRJe/bsGTx4sGxPnz692iWf/bzL BwAAAACovrsCL7PCvVF9sp2ent6lSxf1qcyWLVuuXbtWHWOUr8799a9/7XKHYcOGZWVlOernWwhM AEIGQwDgq+AMhuOXG8ABVZ8lZ86cOXbsmC35mmIURJs51edbCEwAQgZDAOCr4JCGQ/WBU6i++/sL 7zXl8y0EJgAhgyEA8FVA9dF3cB/o1KmTeg5z9j0hJCSkT58+M2fOrK4CY2JiVPvt//MtBCYAIYMh APBVQPXRd3AfUHfJajo14vMtBCYAIYMhAPBVQPVVG7zMCraj7vU9+uijC2oyNeKLnQQmACGDIQDw VXBIw/HLDVAjfRQAAAAAAFB9gOoDAAAAAABUH6D6AAAAAABQfQCoPgAAAAAAVF8F4GVWQPXZIQQm ACGDIQDwVXBIw/HLDYDqAwITgJDBEAD4Kjiy4VB9gOoDAhOAkMEQAPgqoProO0D1MagBACGDIQDw VQyH6sPpAdXHoAZAyACGAMBXMRyq75/wMiug+uwQAhOAkMEQAPgqOKTh+OUGQPUBAAAAADjdihrV B3bEhAkTxEflX7oCAAAAAKC6VtSoPrAjFixYID76yiuv0BWOQXFxcWlpqWNcS1lZ2e3bt7EpTggA AFATV9SoPkD1wb9ISkpaY8J3331XldKCgoLEpo7RMxs3bmzatKmTuMH333//9ddfm+bk5OSIP1y8 ePH+NuzDDz9co8f169edwQkBAADsV/XxMiug+uwQo8Ds3r17hw4dJv7M1q1bjUrIyso6c+bMfVd9 tjSjWk50KtUXERGxadMm05y5c+dKbM6fP//+NmzmzJnKM8VL3d3dNUfNz8+/207IXGbnYxcAvgoY 7j6rPj5cC6g+O8QoMEX1ycLalhKGDx8+Y8aM+676bGlGtZzoPKrv9u3bLVu2LCws1HKKi4tbtWoV EBDg4+NjJ09Liu169uxpy5HV5YTMZXY+dgHgq4DhUH2A6oMqqb7Lly+PGjVKNE+7du1SU1MlZ9Gi RQ0bNpQcUQKbN2+WnLy8vIkTJ3p5eTVq1KhLly6mC+6FCxf6+vr27t17//79ljVGRUUtX778xRdf 9PDwaNOmTVJSkpYfFxc3ZcoUqeXq1atSvuTIMZ6entHR0erejmUzLJuq2zYbT8zNzR05cmSzZs3k LOkWXdVn1k7dctLT00NCQiRT+uHSpUtaqyyvSAgLC9uwYYPaTkhIkAYYdYhlh+vWrhEeHv7BBx+o 7alTp/7qV79S22lpaWPGjNEO++KLLwYNGmR6YmJioujAr7/+WsLT9Pavbhtsb5hut+hm2qL6jPpT U30//vijbH/00UdWmiQlxMfH63oscxkLMgB8FcOh+nB6QPU5juobP378V3fQXuobOHDgpEmTRGms WrUqMDBQcgoLC0UYxMTEyNK5qKhIHePv75+SknLr1q0ffvhBW3C3atVq2rRphw8flhW2qA7LGuUY b2/vt9566/vvvxe10Lx585KSEpXv7u6+dOnSzMzM0tJSqS44OPjIHQYMGDBkyBCjZpg1VbdtNp44 ePDg0NDQM2fOnD9/XsSYruoza6duOaIfRLCVlZWdPn1a2qAyda9I6NChw4oVK9T2smXLOnfubFSR ZYfr1q4xe/ZspfTkFOlnV1dXJY2kH0TnaIeJAtcaoBg6dKicKxvdunUbPXq0lm/UBhsbptstupm2 qD6j/lSqT4qSTLlS08ZbNsmKxzKXsSADwFcxHKoPpwdUn+OoPi8vr753iIqKkpyTJ0+KURITE2Ux nZGRIVIhJyfnp39/QlIdIxLFUhFFRkaq7XXr1vn4+Oiqppdffllt5+XlSTn79u1T+ZMnT1b5p06d knx1U+6nO5+ckd2zZ8/qNsOsqUZtK/fEc+fOSaaoF3WM0ROepu006qt+/fop9aidZeWKrKg+s4rM Lsqodo3du3c3atTo9u3b27ZtE1HUqVMnuSgRkJ6enkePHtUOa9OmjWlTpVVS1PHjx2V7zZo1Dzzw gLoFZ6UNNjbMsluMMstVfVb6U/pt/vz5Tz/99LBhw9QfFKw0yYrHMpexIAPAVzEcqs8avMwKqD47 xMrXXMye8ExNTRWj9OrVq8/P7N2710w1qWO++eYbS0WkvVK1YcMGb29vXdVk+tpVy5Ytly9fbpav ys/Ozla758+fl909e/boNsOsqUZtK/dE0UimlVpRfWbttOwr0TAhISF16tSZNWvWzZs3rV+RFdVn VpHZRRnVrlFcXNykSRM5LCYm5p133nnppZd+97vfpaWltW/fXjtGVJDZTUKp9KGHHpp2h2eeeUaq eP311623wcaGWXaLUWa5qs9Kf0q/yZGym56eXm6TrHgsc5mdj10A+CpguPus+gBQfTUIS9V34sQJ Mcr27dutqCZ1zOrVq6uo+nJzc6Uc0Vdm+UePHpX8nTt3qt1t27bJrrr7ZNkMs6Yata3cE3Nyclxc XNSNRxtVn1FfKUSEuLu7r1y50voVieqLi4tT+fPmzdNVfboXZb12xZgxY8S+Pj4+IpCk9tatW0+f Pt1Udf/xj3+cO3eutltSUiJWe+GFF1b9TGhoaLt27ay3oUINM+0W65lWVJ+V/lT9Jpfp6ekpLbHe JFs8FgAAANUHgOpzNNUnBAcH9+/fXz10d/369WvXrslGbGysZGrHyHZgYODBgwdl+9ixY+pLjzaq voEDBxYUFIjAWLJkSfPmzVX5pudKaV27dh0/frz8lxwZERHRrVu3srIyy2boNlW3bbacKJVGRUXl 5+cfOHCgU6dO5ao+o3LS0tKKi4ulwT169IiPj7d+RaNHj46MjCwqKkpISGjSpImu6jO6KN3aTVm/ fr2UqfSSVNGgQQPZPXTokHZA3759NaErJCcnt2jRwvT9OvVNF3VnTLcNtjfMsluMMstVfVb6U/Wb bIspReVqT73qNsnIY0XHinMyPgAAAKoPANXnsKpPFspDhw51dXX19/f38PBQD86JVGjbtq2vr++O HTtk98KFC7JiFvM1a9bMx8dHfSLFRtU3bNiwxx57TP7X3d1du11jJnIyMzNlHS8Sxc3NTZb76jaO ZTN0m6rbNltOTElJady4sWSKjFmxYoUtqk+3HKlIzvXz8wsLC7tx44b1K9q1a5eXl1e9evXCw8MX L15spPp0L0q3dlOys7NdXFw0ATNkyBDpee1/8/LyWrVqZfrbDCNGjLD0BxHA0dHRRm2wvWG63aKb Wa7qs9KfWr+JmJQyO3bsKLLQqElGHhsSEvL4448zPgAAAKoPANXn4BQWFl68eNEsU5b4piLhypUr akltO9qtGClK3ZyxgsgS3fLNmqHbVN22lXuiSAXLoirRV9fuYOMVlZSU2NiNuhele/m2IDpnwoQJ FT1Ltw02Nky3W4z6yhaMPKRCXg0AAIDqqzC8zAqoPjvEfgLzHvySO9jI9OnTt2zZQj8wl2EIAHzV gSnKLXB4w/HLDYDqA7sLzPXr11v+njgAIQMYAvBVuEum2fGL6OzP9jmw4VB9gOoDAhOAkMEQAPiq U5tG0ke1e25sHJQx/S2zW3+oPpweUH3MRgCEDGAIAHzVEVSflj6q3cP01h+qD6cHVB+zEQAhAxgC AF91KNVndusP1Vd5eJkVUH01ZcgjkUgkEolEcvJ07uMvUH0AqD4AAAAAcJA/fG/tEPnlqNmfPT42 uc2oI0sSrH/hE9UHgOoDAAAAgJqh+ja6PZU25MW0YbGbHgpOH/Pyxc/3lxWXOPaKGtUHqD4AAAAA cBbV53g391B9gOoDAAAAAPiX6nO8m3t2ofr4mgug+uwQAhOAkMEQAPiqE2L95p5jGI5fbgBUHxCY AIQMhgDAV8GRDYfqA1QfEJgAhAyGAMBXAdVH3wGqj0ENAAgZDAGAr2I4VB9OD6g+BjUAQgYwBAC+ iuFQff+El1kB1WeHEJgAhAyGAMBXwSENxy83AKoPAAAAAMDpVtSoPkD1AQAAAACg+gBQfQAAAAAA qD4AVB8AAAAAgNOpPl5mBVSfHUJgAhAyGAIAXwWHNBy/3ACoPiAwAQgZDAGAr4IjGw7VB6g+IDAB CBkMAYCvAqqPvgNUH4MaABAyGAIAX8VwqD6cHlB9DGpQVlZ2+/Zt+oGQAQwBgK9iOGdXfbzMCqg+ O8QoMJOSktbc4fPPP7916xYdZZ2NGzc2bdqUfnDmkAEMAYCvYjhUHwCqr4bRvXv3jh07RkRE+Pr6 urm5ffnll1YOzsrKOnPmjB1eRaUbVtETUX0AAACA6gNA9dU81Td79my1/eSTT44bN87KwcOHD58x Y4YdXkWlG1bRE1F9AAAAgOoDQPXVYNUnEmjEiBFq+/Lly6NGjRKF065du9TUVMlZtGhRw4YNJScg IGDz5s2SExYWtmHDBnV8QkLCyJEj1XZUVFRcXNyUKVPk4KtXr8pufHz8woULfX19e/fuvX//fstm yDHLly9/8cUXPTw82rRpk5SUpFtUXl6e5Mgxnp6e0dHR+fn5ug2zbLwg506cONHLy6tRo0ZdunSx /cTc3Fy5tGbNmslZM2fO1FV9Zu3ULSc9PT0kJEQypR8uXbqktcryimzvW8uLMroKAAAAQPUBoPqc WvWJThCNUbdu3U8++UTlDxw4cNKkSaIrVq1aFRgYKDmFhYWDBg2KiYmRg4uKiiSnQ4cOK1asUMcv W7asc+fOajsoKMjd3X3p0qWZmZmlpaWy26pVq2nTph0+fFjUSHh4uGUz5Bhvb++33nrr+++/FxnT vHnzkpISy6KkAcHBwUfuMGDAgCFDhug2zLLxKtPf3z8lJeXWrVs//PCD7ScOHjw4NDT0zJkz58+f FzGmq/rM2qlbjiheEWxlZWWnT5/WXqHUvSLb+9byooyuAgAAAFB91QkvswKqzw4xCkxRffXq1XNx cRFD7NixQ2WePHlSdhMTE0WKZGRkuLq65uTk/GTxPKQVZTJ58mRTRRQZGam2161b5+Pjo6uaXn75 ZbWdl5cnte/bt8+sqFOnTkm+uin3053v0Mju2bNnzRqm23iVKY00q7fcE8+dOyeZIqvUMUZPeJq2 06j3+vXrp9SjdpaVK7Klb3Uvyqh2YC7DEAD4Kjiq4fjlBkD1QTmBKaovNjb20qVLfn5+zz//vMpM TU0Vu/Tq1avPz+zdu7dCqk8sa6qItN0NGzZ4e3vrqibTU1q2bLl8+XKzfNWq7OxstXv+/HnZ3bNn j1nDdBuvMr/55hsrqk/3xN27d5tWakX1mbXTsvdE74WEhNSpU2fWrFk3b960fkW29K3uRRnVDsxl GAIAXwVHNRyqD1B9UL7qU+/1ibypXbt2cnKybJ84cULssn37disaSSmTuLg4tT1v3rzqUn25ublS u+grs/yjR49K/s6dO9Xutm3bZPf48eNmDdNtvMpcvXq1lSvSPTEnJ8fFxUXdeLRR9Rn1nkJEnbu7 +8qVK61fkS19q3tR1msH5jIMAYCvAqqPvgNUn/OqPmH69OkiSNQDgcHBwf3791ePI16/fv3atWuy ERsbK5nauaNHj46MjCwqKkpISGjSpEkVVd/AgQMLCgpKSkqWLFnSvHlzVaPpuaWlpV27dh0/frz8 lxwZERHRrVu3srIyy4bpNl5yAgMDDx48KNvHjh2T0mw8USqNiorKz88/cOBAp06dylV9RuWkpaUV FxdLg3v06BEfH2/9imzsW92L0q1dxKF0LIHAXIYhAPBVQPXRd4Dqc2rVd+PGjYCAgEGDBonwEO03 dOhQV1dXf39/Dw8P9djhoUOH2rZt6+vrq94A3LVrl5eXV7169cLDwxcvXlxF1Tds2LDHHntM/leU p3b7y6yozMxM0UWigtzc3Hr27Klui1k2TLfxFy5ckNLE35o1a+bj46M+32LLiSkpKY0bN5ZM0Vcr VqywRfXpliMVybl+fn5hYWHS1davyMa+1b0o3dpDQkIef/xxAoG5DEMA4KuA6qseeJkVUH12iPXA LMot0M0vLCy8ePGiWaYoDXVPSSgpKSkoKKh685SYEbUphaubXVbIy8vTrdS0YUaNv3LliuW55Z5Y XFxsWVS5WJZz7Q42XpHtfat7UbqXD8xlGAIAXwXHMxy/3ACoPrBGceGN7+euSnQPve9/6DK7hQUA AAAAqD5A9UGVuLTr4Bd9J3/k2kv0nkr3tz3r16/n98QBAAAAUH2A6oOqYnpzzyzROQAAAACoPgBU Xw3G8uYeqg8AAAAA1VdJeJkVUH32RvbWfUZij0QikUgkEsmZE6qvknDTAFB9dogE5rFlf04J+HVi y9BPvYdzrw+AuQxDAOCrgOrD6QHV55iD2qVdGfsnvPZxg77JbUZ9XL8vqg+AuQxDAOCrGA7Vh9MD qs8BB7Wi3AKzW390EQBzGYYAwFcxHKoPpwdUnwMOaurWH2ELwFyGIQDwVQyH6qsAfM0FUH12iPXA LMotoIsAmMswBAC+iuFQfQCoPgAAAAAAVB8Aqg8AAAAAANUHgOoDAAAAAED1AaoPAAAAAADsT/Xx MivYTnR0tPhoUFDQArjLxDw1nE4AIGQwBAC+Co5nuKeeekpW1BMmTLinqo8P14LtKB8FAAAAAICq EBQUhOoDO2X58uXioBMmTHgF7jJjannRCQCEDIYAwFfB8Qwna2lZUcu6GtUH4OwQmACEDIYAwFfB eQyH6gNgUAMAQgZDAOCrgOqrAnzNBcAOITABCBkMAYCvgvMYjl9uAAAAAAAAcGRQfQAAAAAAAKg+ AAAAAAAAQPUBAAAAAACA06k+XmYFsEMITABCBkMA4KvgPIbjlxsAnBECE4CQwRAA+Co4j+FQfQAM agBAyGAIAHwVUH30HQCDGgAhAxgCAF/FcKg+nB7ugTuRSPaWCEwiugb5JJ3DiMFQQLovDkzX3Xdz 8DUXqGETQ1nZNySS/STWcER0zfJJ+pwRg6GAdF8cGCvfd3Pwyw3AxEAisYYjolF9JEYMhgISqg/V B8DEQCKxhiOiUX0kRgyGAhwYKzuJ6vvLX/7y7bffarvnzp3785//zIAFTAwkxlwgolF9JEYMhgIc GCs7iOpr3br1kiVLtN2UlJRHHnmEAQuYGEiMuUBEo/pIjBgMBTgwVkb1ATAxkJgCgYhG9WEdwC1R faSarPrS09NDQkKaNm3q6+t76dIllXn58uVRo0ZJZrt27VJTU1VmVFRUXFzclClTJP/q1auMd8CQ QWINR0STUH2MGAwFJFQfqQaovt69e4uWKysrO3369K1bt1TmwIEDJ02aJNJu1apVgYGBKjMoKMjd 3X3p0qWZmZmlpaWMd8CQQWINR0STUH2MGAwFJFQfqQaovn79+oWGhp45c0b735MnT9aqVSsxMfHI kSMZGRmurq45OTlK9U2ePJlhDhgySKzhiGgSqg/rMBTgG6g+kt2pvoCAgFdffVXb3bJli+hAtS16 LyQkpE6dOrNmzbp586bkpKamiurr1atXn5/Zu3evUn0LFixgmAOGDBJrOCLaztPt2wdKSg6i+qq9 f0pLM27d+tr2/AoVwojBUFBD4xfVR7Ij1TdgwIAhQ4Zou+vXrxctZ3rAnj173N3dV65cKdsnTpwQ 1bd9+3azQlB9UL1DRmLiW++++3tJO3asLiraX4MiVpYsmzcvf+WVKTExv166dPrGjW8UFKTV0NFH rmX58lnKHF988a7pf23Zsvzo0U9sL0qOP3jww6o3KTv7c/GKnJzPK11CQsJr+fl7WMPdr4hW6dtv P7qPjh0U9IsFC35n2rD33nvlb3/7izi8I6m+Sve5af9UKH388etNmza2Pb/cQhzAOgwF1T6SV9o/ q3Eyqq4ZTRRsSsqKF16IXLLkhdTUNQ6j+mroEq4mmqPCqm/x4sVubm4HDhyQ7ZycnP79+8+ZM0f9 V1paWnFxcVlZWY8ePeLj41VmcHCwHKMe+7x+/fq1a9dQfVDtQ0b37h06dmwbERHi6+vp5tZg7971 NWLIyM3dFRzc3dvbY86ciStXvhwbO759e38zvVSD0ssvP/P//t9CZY769esdP75Z+6+nnuq6Zs1/ WTn33Lmtp0+naLvjxoW+9dbMqjdp7tz/qFWr1vz5kytdwpEjnwwe3FsGd9Zw9ziiO3RoM3HiSJU+ +2yl7c5zV1WfGmqGDOkjSuPhh92vXt3rMKqvQn1un6rPAazDUFD1kdxsQKii6qvcZHSXZrRhw/r2 6NHh9ddjf/vbsDFjBjqM6quhS7iaaI4Kq74bN25ERERI+LVu3bpOnToDBw7Mz89X/9W2bdumTZv6 +fmFhYXJYSpTlOHQoUNdXV39/f09PDz27NmD6oO7MWTMnj1BbT/5ZDsZYWvEkDF58ig/P69Ll74w u2NWEyWfrL1++cvOmjlcXWvLXKtdS7mqb/jwfjNmPF3tf4dr1apFQMAjPj4eVXnC56WXoq20jTXc XYromTN/a6OB7obzWFF9aqg5f377gw/WVTe3HUb12d7ndqv6arp1GAqqPpKbDQhVVH2VS3djUMrM /LR27doXLuxwvCc8a+ISroaao1blLJeXl5eRkZGdnW2Wf+0OlscXFhZevHiRcQ3ugeqT0XbEiKfU tgiqUaMGyJqgXbtHtXtoX375fkhIT8n09fW8eHGndtstKmqYh0dzT8/m0dHDr1zZrfLDwvr+6U// rbbff//VkSOD1LYcvGzZzClTxkg5P/64V06fOHGkl1fLRo0adunSzkrtWpIqZMh4993fG90G1G2P ZMpS5rXXpkrje/fu9NVXf7JyUVYaL4XMm/cfDz/s3rXr48eOJclhbdv6PvFE6y1blltpvNlVmzZY JF9CwmuaOf7zP6Pq1HFdvXqepeqTqvv27dKixUMDB/ZQ7f/v/36uYcP6UqbM659+Gqcqio+fLRvS q2+8MUOr5bnnIlatmltu36r0ySdvtmzZbP/+DbVq1TK9cSGFx8W99OKLv5HubdPGJzHxLev5Mri7 uTW4fn0fa7j7qPrEq3/xiyfWr39F7aakrBg0qNetW19bOo8trmsUR5bOaaT68vP3iFdo7mo2GlgG b3h4/w0b/i8Yp06N+NWv+qvtPXveU38k1g3hioZhtas+W8YK6Z/58ydbBo5u4y9fTpWBqFmzJjJO SnWaYDPKr1AhDmAdhgLbR3LdCc5yQFDxaxnsViZZs7FCTUYiPqVM06SGhQrNaJWY3E3vH7q4uKxb t8Asv1w/fPrpYbZPo3fVgR1pCVdDzVGLsQYcRvVJzEh41637wKZNb6p8GYUnTQqXUHn77TmBgW1U poynEkWlpRmnTiVrT5DLCjI4uPsPP2ySNGBAtyFD+qj8Dh3aaIP1W2/N7Nz5MW2h4+7edMmSF2QZ VFJyUCry9/dOTo6XAg8f3mildi397//+SeYwo5dnjNoj9bZq1WLatHGHDn0sA4QsVqxclJXGy8j4 6qsxcnCfPp1lofab3ww5evQTGX2kJ6003uyqtdZevbpXrkV7KkMK+eCDRXPn/kfjxg1lZDRTfRs3 vvG3v/3l5s2vxo8fOnbsIMm5du1Lud6YmF+LBSXfdJ393nuv+Pl5qXuGstSrX7+eemzGet+qNHTo L9VE0q1b+9Gjg03/9Ovt7fHmm//53Xd/lYG+efMmxcUHreTLZO/qWnvbtrdRffcyoocN6/s//7NY kgg8lfnXv/5RHECcR2ZoESHqPQpL57HFdY3iyNI5LVWf/JfM9LLsEJ2jviNiVrhu8IorKi0h4Smu JR6l1iXSclnnGYVwhcKw6qrPss9tGSuMAke38YMH9w4N7SVRnJW1TRZkmmAzyq9QIQ5gHYYC20dy 3QlOdzbRDXYrk6zZWKGFv5Sp0urV82SloYagCs1olZjcTdOcORNFaUyYMEJmQy2zXD9ct26+7dPo XXVgR1rC1VBzoPrAQdaI9erVlfC78/WgVSrzxIktsvvJJ2/KKHDw4IcykWdn//Nd8H79nlQrBu30 kyf/eaT6m5x6sVh2z5z5zPqQMXnyKNOKzJ7aN6pdS5s3L5cDlCgyS1baI/VGRg5W+WvXzvfx8VDb lhdlvfFTp0ZoL+N16dJOjSbSJBmArDTe9KpNk4yScrz2qr1SfTLbPfFEa1lHGj3huWrVXBn7rD+T I9Nnw4b1d+1aK9tvvDFDVnu29K0k6S7Jz8z8VLbffff3DzxQR/ujoBQuV639gVCKSk9PsJIvqXVr L6O7sqzh7lJEt2/vHx09XNLcuf+h5ctSXoTHiBFPyYbuw1Q2uq5RHOk6p5nq69QpoGfPQJmJ33// VTVzmxZuFLziw40aNRQdsnXr27IikUI+/vh1iTvRVEeOfKIbwhUNw6qrPss+L3esMAoc3cafPbtV MmVpZfZwplF+hQpxDOswFNg+khtNcJaziWWwW59kzcYKswdEv/76gwYNHtSeO6jQjFaJyd3ywyfi ll5eLdWfWW3xwwpNo3fVgR1pCVdDzXG3VF9x4Y3srfuOvv7BoQVr5N9zH38hOYxrcPfWiLGx42Uy kDH3+efHqswvvnj3zg+HdOzTp7NKaWn/DEsZLEJCetap4zprVvSNG19pR2rPZ2dlbZPd3bvXWR8y tJlAnZ6R8W9f6DKqXUvff/9XOcAs0/Rc3faY1vunP/23t/f/TQyWF2Vj42V5FxzcXfvOmFrJGTXe 6AUJWRjJ8dJOU9Wn7mfWrl17w4b/NlV9SUnLevTo8OST7SQ9+ujD5b6J8dvfhskyVDbatXt048Y3 bOlbSXL6Qw81mjZtnKRnnhkhx//xjy/qzuItWzaLi3vJSr4kX19Pywc5WMPd1YjWfcfs6tW9st4S y/7jH/+rq/psdF2jONJ1Tt0nPGVJITrhlVem6I4GlsF7+/aBJk3c5H9jYn69evW8l16K/t3vRu/Z 854ILaMQrmgY3o0nPMsdK4wCR7fxstAx7RxNsBnlV6gQx7AOQ4HtI7ntqs8y2G2cZC13xbVklT9v 3r/+FFWhGa0Sk7tlunJl97BhfSUART/Y6Ie2T6N31YEdaQlXQ81R/aqvKLfg0IJVG936SVNM00a3 p76duVz+l9EN7tLjAWr1IDJDvXBy/PhmiSKjB/NkRHB3b7pixcuaaPn883fUf23d+rbsqj8uypCx bNn//QVIBnrdIUNVpJ7M1pL12iXdvPlV8+ZNnn12lJGI0m2P9YnB9KJsbLzuSs6o8UYD0PXr+6Tb 1SBrqvokyczXosVDsnhSqu/YsSQZrNUf89avf8UW1SejYcOG9ZOT42WuVd/SLLdvi4sPSs+88ELk 22/PUSk0tJcMr5aFX778z98UlYWjlfyiov1ydTt3vssa7r6rvilTxsj8KrriD3+Yrqv6bHRd3Tgy ck5d1SdJVidKFZgeYCV4x4wZKBfl4+MhqxM5oHVrr+nTf2MWUKYhXNEwtAfVpwWObuOzsz93cXHR bqFrgs0ov0KFOIZ1GApsH8mNJjhbVJ+Nk6zZ7o8/7pVKx44dpH2orKIzWqUnd8tboOotRxv90PZp 9H6pvhq3hKuh5qhm1Xdp18HN3kOUzPus3YiM52cdWvDatzPnbes8+qM6PSUzscWg7K37GODgLg0Z kmSqlrFA3RyXNUr//t3UkwCFhenqQ9579rwnYSajdo8eHdRH3kpKDnbt+vj48UPlgPz8PRERId26 tVfD+ujRwZGRg0Whvf/+q02auOkOGZKklsDANgcO/I9s//3vieohKN3azR4IcXWt/cYbM9RrMHLW 5s3L1elG7TGaGCwvysbGG63kdBtvZQAaNKjX2rXzLVXfP/7xv23a+MhwplTfl1++L3PkyZNbxEBP Pz1UW67Fxo6X6nRHOrmoRx5pJQv9OXMmagdY71u5EJGaplKBnn0AAAikSURBVD/7o74EoP3xbODA HtKx0u2LF08T7a1dnW7+Dz9satasidGPCLGGu2eq769//aOsxWXhJbN73boPaH9lMHMeW1xXN46M nNNS9UmsiVc8/rjftGnjzA6wErzvvfeKhGHPnoHqjz4NGjwou99//1crIVzRMLxfqk83cHQbL50T FTXsypXdX3/9QadOAVonG+VXqBAHsA5Dge0judEEZ2U20YLdxknWdFccQDRnr14dtadpKjGjVWJy 15J4tYgi9baquKvUe+LEFhv90PZp9P6qvhq0hKuh5qhO1SeSb6NbX2mBaLz8bz41a9mPRz77vOdY +d+P6vS6sGUvYxzcpSFDZEZAwCMiQiSuZOAYOvSXoqz8/b09PJqrZWLbtr4yNPv5eYWF9dWeEzt2 LEmGCRkU3NwayMSv/kokKTV1jZdXy3r16oaH91+06HmjIeP8+e2SI7ORyAMfHw/1Ardu7WZp3boF skiS9dNjjz0qo7w0SUYcK+0xmhh0L8qWxhut5HQbb2UA2rFjdZcu7dRfrUxVn/qbnIuLi/aEpzTm wQfrPvywu+TItavX32V1JZfg6+up/mhqVtF//dezUoIaUq00T0sjRjxluX6V1aF6pkIKHzasr+pw mV20PxAa5U+aFL5w4XOs4e5xREs0ufxMSEhPWVeJUWTNpw547bWpnp7N1crAzHlscV2jONJ1TjPV V+sObdr4TJ0aoZ5qNivcKHgvXNgh1yK6SO0OGdJHnE07SzeEKxqGVVR9Zn1uu+obNy7UMnB0G5+c HN+4cUPJlDVWfPxsbZVslF+hQhzAOgwFto/kRhOcldnENNhtmWRNd9UH2NQT5iqpZlR0Rqvo5G76 CpnU3qhRQylZXP1//mdxhfzQxmn0vqu+mrKEq6HmqDbVV5RbkOQ5SKr/5sWXS28b/qCK/K+643cz J49hDqpryLCerl37UvvQiPZ2kO4P+Obm7srP32P5kIllpm7Ky9M53bJ23V90/eGHTZa/1KfbHqOk e1G2N97GrrOSZPn15pv/aePP06u/pRUWpksyHXkr9MN6FWqe2SwuvS3Vmfa5bv6+ff9v/PihrOHs KqJ1k5nzVM43rDhnJcqpaOgZjUsVvZbKqb5Kpx9/3FtUtN8yoIwaf/v2Ad3LMcqvUCE13ToMBRVK ViY4G2eTSnhCtcxolatXSjt+fLPub8RVesS7lw7sYEu4mmiOalN93/9+pbrLV3zja+tN3PGLX8uR 385czjAH93GNSLob6a9//aP9N9Loj2e6+Z9+Gqf+7McajoiuKekeqz4Sv9LOUIADY2VH/pV2M4oL b6jPt1g+2Knzd8Ejn31Up9dGt6f+f3v3ExtFGcYB2IgxGk8kHPDoWQ4eiNZoLEmxCZ4sGpSEA71V CwkkpBr/law3ORCjB1LtCQ6WNYA2sqakbGPXGCILxCJNvFhJmqaVFBRtm8KCbzsKBgusyyozm+fJ m80y+83s5vtmPvaXme7Mn//VTIcpQ/3P1du7c8kbu99sue9wjmipT0l9pgIl9Ul9C8b7h+ONC6va qvyUA6s3RPuz+UEzHaYM5TucI1pJfUbHVKCkPpWB1De6a1+8cXlLV5Wf8tSON6N9rGWmw5ShfIdz RCupz+iYCpTUpzKQ+ka6e+KNR7pzVX7KaLnYvsdMhylD+Q7niFZSn9ExFSipTzXkub63nevDlKF8 h3NE24WkPqOD3VLqUw38d30b/V0fpgzlO5wj2i4k9Rkd7JZSn8pM6lv8Dc/mqn/Ds+A3PDFlKP8F 4oiW+owOdkupT2Up9V1duF/fnuR+fbe4RXtSR5o2uV8fNU8ZSqWtHJiO6AztkzrHjGEqUHdlB9Z1 d3046pb65n4+f2jlunj7E9tev0XwO7HtnWhzcEXr7MQ50xwAAMB/7Z46bmuyWE6u8/zysRf+eann hTOF5Cxf331PjvcP63oAAICMpb4k+B1c0ZqccyysWl96sWOwedM3L3UOrN6Yf+Dp5CyfyAcAAJDV 1Hd18VLP797ak5z0+3vFklM73ndhJwAAQLZTX+LSxZnx/uHis1sj7w21bj2bH/SLnQAAAI2T+hIj 3T2R+k7v/EhHAwAASH0AAABIfQAAAEh9AAAASH0AAABS31Imi+VIdLetweaOSH1H13RU03hqqGw8 AAAAUpH6kpN49S2nBAEAANKS+qaGyhHSbltH1yTn+l6pprFzfQAAAGlJfVXyd30AAABSHwAAAFIf AAAAUh8AAABSHwAAgNQn9QEAAEh9Uh8AAIDUJ/UBAABIfQAAAEh9AAAASH0AAABIfQAAAFKf1AcA ACD1SX0AAABSHwAAAFIfAAAA2Uh93776XqS+4527dDQAAECjpb7LM3P5B5+J1BeP8VxfAwAANE7q u1KplNq6IvJ9cm9TPMbzWKK7AQAAGiT1ndy+O8LegeUt41+U4jGexxLdDQAA0Aip74cP9kfM23// U1ND5fhnPMbzWBLL9TgAAEC2U9/451/1LV7VObavcG3h2N7DsaRvWVO8qtMBAACymvqmj49++lBz BLzv3+294aXTuY9jebwabfQ7AABA9lLfb2MTh1aui2h3rD23ZINjm3PxarT5/acJXQ8AAJCl1Dd/ 4WLh0Zcj1BXXbqnMX1qyTSwvtnRGm2gZ7fU+AABANlJf9XHuejhs6bxZOAQAACBdqS+5dPOzh5+r 5tLNaPPnhaCbcwYAAAAg7amvhp9pufajL7GuMQAAAEhv6rt+S4b+4X+14sINHpYt3uBh72HDAAAA kMbUN1n86/brH+ZrWP2Gm7kDAACQotT3y+iPB5a3RGw7uX13zRuJdWMLsZ3YmsEAAABIS+qbnZzu f+T5CGyl9a9dqVRqfvtYt9TWFduJrcU2jQcAAEAqUt/XG96IqHbkifbLM3N3+AliCwOPt8fWYpvG AwAAIBWpb3ZyOkJavc7O1XdrAAAA3GnqAwAAIBP+AEfXPZUF3rW3AAAAAElFTkSuQmCC --00c09fa21bcdfaf6a3048cdd0a05 Content-Type: image/png; name="autonomous.png" Content-Disposition: attachment; filename="autonomous.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gcdrt5qc4 iVBORw0KGgoAAAANSUhEUgAAA34AAAGCCAIAAAAwhIYIAAAANXRFWHRjb3B5bGVmdABHZW5lcmF0 ZWQgYnkgaHR0cDovL3BsYW50dW1sLnNvdXJjZWZvcmdlLm5ldDpnVRsAAAF2elRYdHBsYW50dW1s AAB4nHVRW0vDMBR+z684+LQ9tKbVbVhENsdUxDJp5ib6IFl70GCX1OR0or/etFbcEF9y4bsdvjN2 JC3Vm5JV/la5qqQmOMjQmdrmCFOjXb1BewDSQTbdZ01qejFWfUpSRoNAu+2IDfDwj+MOLRP7nHmj g9VlC7Yf9hic+dgE5muSSsPEObRtWg+fQUzSm37Isil4VpuZQIZvNTqCSZ6jc7Awr6hh/QGVRYea lH7+NWHfgV7cPhJYyS3CldSFg5Uqi/KDta479ktZqkIS7pj4+NPgN55qq/fSWWlM1Q2ZiQQukPIX P48hzAkLsD/NvB/uysLOuJF0rn81IUNdsLE/mhWy29L3eJfegG/YNS0N+HDUE5Lgui4hGkF0nAx4 EkcwnYkFxDzifXYtt7K3SPsgZpDVvqINwkxvlTV64xtrcbgyJCpDLW94HJwr6hYJy5RF4TDkTzEP 1jwO4tFJEPH0iA8HLJU5zAXcfwH2qsfGR2bZAQAAWLVJREFUeNrtnQlYVdX6uEE0U5wVUBmSHKIS xxS1q6mAKKKGsymh5jWtHPAhxxtWXofSVMD0pmaW2r3dVBwwp0LFMMfqOuQVx5xQISdMUZD+38/1 bz/nnrPP5oCIHHjfZz0++yz2sPa39rfWe/bZ5+jwBzxu/uXQnFLIC1cpuUmx3yQlOIVqVCRK4EAI CsP0lp39I6XQFoYPcpNi10lKPxaqUbH4dAdzB+rJ9EZh+AByE/WkoJ7MHagn0xvDIsMHkJsU1BP1 JEqoJzC9URg+yE0K6klBPZk7UE+mNwrDB5CbFNQT9WTuQD2BPGT4AHKTgnoyKqKezB2oJ9MbheED yE3Uk4J6MnegnkxvDIsMH0BuUlBP1JMooZ7A9EZh+CA3H0G5d29fVtZ+kgv1RD0LrBR80jF3oJ52 Ob3Fxc3+5JO/SdmyZUFGxh47Gpju3z+wbl30u+8OGz6814wZo1aunHXtWiLqCUVJPS9e3Cq5mZKy NQ8XVdu2L0ye/Hqer8n166P37//yIS/sfNmJmtE3bIgdObLf9OkjExIW2pF62ukAW/gDnue0kolj 1aqPJkwYHBn56ooV0+7e3VuQSbd06fsnTqxXy3JoOdCpU/FazBcufEf+VY1cu3au7OqNN3p/+OHo 1as/un59J3MH6ll0prfmzes3aFC3d+9AL6/q5cqV3blziV2MjKmp2/z9m3t4uMkIMm/e+IiI/s8/ X/u77z5BPaEoqefEia85ODhERQ215So6e3bj6dMb8ks9+/YNmj07MrdbmbUhbzuxLJ07t/bzqz9z ZsSrr4b07BlgR+pppwNs4Q943tLqt9+2BwT41av31HvvDZ82bUTjxj4vvPCcXLQFlnRt2jSROUst JyUtlQNNnfqWepmYuEQaZjm7jRkzoH79OtZmN+YO1NNe1XPcuIFquUkTH5kq7GJkHDq0u7e3++XL 35m9nUU9ocjk5r17+2rUqCazkaenmy2f4nXp0kZmqfxSz7wVszbkS0lOXluiRIkLF7bY4wfu9jjA 2kXA85ZWb77Zu1atmtrnY7dv7xb1fPnldgWWdPJXuSTU8owZoyTOYvnq5aRJr40Y0Veb3S5d+taW 2Y25A/W0e/WULOra9SW1LFbXvXv7ypUr+PjU0t5vff/9Z4GBLaRS3sFriSFv0cLCOru5Va1evWp4 eBd5W6nqQ0Jaf/HF39XyZ5+9161bW7UsK8+ZEzlsWE/Zz/XrO2XzwYO7ubu7li/vLO9BDY5u+s5V MvaTT/5m7YaobnukMjp67PvvvyGNb9Wq4e7dXxiclEHjZScyRtSs6dK06bPHjq2R1erW9XruuafX r482aLzZWTN8QI65uXr1R66uVfbsWebg4PDNN/O0et2L8+9/f9PZuYxcXTJrrl07V5sFLS94gwQx vUTlZUzMODUZyz5Ni5pcJRFat25crVqlgAA/tXPLNmg7yUNimt5YcnR0XLx4sll9jok2YEDnWbPG mGrH/PkT85ah+aKe9jLA2kXA85BWV6/uKFnSSemdVqZPHyn5dfTo6keadFrZseNTJ6cS6nxlnz17 BlSpUlFppbwziY+PMZ7dUE/Us0ippwwNkldPPFFq1aqPVL1MJ0OGhEqGfPzxBF/fOqpSckkGC8mT U6fiteeWOnRo6e/f/MiRVVLat2/WqdOLqr5+/TrarDN7dmSjRs9o7wtdXCpLwou3ydtKOVDt2h6S crLDw4dXGhxdKz/88IWMCz///JXuGVlrjxxX3s7KuHPo0NcyDoaGtjM4KYPGywTw3nvDZeUXX2xU p47nK690kmFLBlntvaxu483OmuEDcszN4OC/KGtp1uz5Hj38tXrdi/Pmze/lyh8+vJfk8p07uw0u eIMEMb1ETe/fyD5VWbBgkowS6uG/lStn/fTTv+RY/fsH9+nTwVobtJ3kNjFNy4QJg0WGBg7seuVK glaZY6ItXhzl7e2u5nXZsEyZ0uqz0Txk6EOqp30NsHYR8DyklZo41q2LNq388cd/SqVczI806bQi vVC27JPiqRIlkc69e5fL0aVn5Z2GhOvWrV3GsxvqiXoWHfUsXfoJGWXkct+8eb6qPHFivbyU93+S Evv3fynv0i5e3KqeUwkKamn6aMvJk/+3pnrDp56pl5dnznxjPDIOHdrd9EBmT4NZO7pWZOyQFcwe 0MmxPXLcfv06qvpFi6I8Pd20h2/MTsq48W+80Vstjx8/qHFjHzVoSpNk4DBovOlZM3xAjrkpF61c PMnJa2X5k0/+VqpUSe02mLWL0/KzP8sL3jhBTC9Ry48OZZqUWXPJknfNmjp//kQRDuPPH/OQmJbf 15F3fe7urupxSVsSTczA2bnMtm2LZHnWrDEdO7bKc4Y+jHra3QBrFwHPQ1qpiUO7wal9wi69I++p Hl3SmZXAwBajR7/yn//8+7nnnpaXEmFZ8/PPp0i9tdnt9u3d1j79Z+5APe1VPSMi+kuCyeTx1lt9 VOV3330iV3/Llg1efLGRKomJ/zf6yJgo6VGypNPYseGSDNqa2lNB585tkpfbty82Hhm1KU1tfuDA /3wH1trRtXLw4L9lBbNK021122N63C+++LuHx/8fFCxPysbGT5z4mr9/c+2bvEo9rTXe+Bkghg9y 0/KZsEqVyo8Y0VfKoEFd5aL68MPRuZ0FLS94GxPE8qXMyiIikya9ptWsWTPHz69+kyY+UmrVqmnc hjwkpu53RDp3bi2JJopjY6K9+mpIeHgXWfDxqaXubOUtQx9GPe1ugLWLgOchrQ4fXiktMfssWyRP e1fwiJLOrEybNsLXt868eeOHDespL3v1CpRjvfJKp5kzI7TZzfTraNev7zR938LcgXoWnQ/cZUHe qpYoUUI9sHj8+Dq51jdt+lh3Exn4XFwqx8aOl+Vfflkta27d+g/1p40bP5aX6l2j5OqcOZHaA9S6 I6M6kHoeSCvGR5dy587uqlUr/vWvOu+YDdpjPCiYnpSNjddVT2uNRz3B9tzMzNwv1+fIkf0+/niC KkFBLWUuN744bZkFbUwQs5cy+clB+/TpoH3X4dixNWJIajpcsuTdHNUzz4lpeTNYPYRnY6KJ9zg7 l4mPjxFvVj9bk7cMffhnPe1ogLWLgOchre7e3VuzpouonmmlxLlcubKpqdseXdKZld27v3B0dJS5 Y/nyqfJSdlu3rle1apUOHfpam920z9ZQT9SziKunlFGjXpEhT30aIonRrl0z9dFPenrSjRs71SPS MprI9OPnVz86eqzUZGXtb9r02f79g2WFq1d39O4d2KzZ82p+6tHDv1+/jpJIn332XsWK5XRHRily FHkLuG/fCln+73/j1McKukc3+4zPyanErFljZLxQzVi3Llptbq091gYFy5OysfG66mmt8agn2J6b cjnJVGT6M5Dqew/qdpG1izMior9ceMazoI0JYvpSskPm4JYtG2ifCagvxIh6njy5XoaLAQOCK1eu YNyGPCSmVo4cWSXepn5/8dNP35Xjql9GtCXR5BBPPVXD1bWK9os2ecvQfPmakb0MsHYR8LxNeZ9/ PqVs2SfF4LWnP6VH1M8bPbqks3xjWaGCs/apunrc03RNsV6JufyLeqKexUI9f//9h3r1nurQoaUM HzI+Bgf/RfSudm0PN7eq6iMeeXMmc4y3t3tISGtZWbv/IaOhZKO8d2zRwle9I5eSkLDQ3d21dOkn QkPbSW5bGxnPn98sNZJaVapU9PR0Uw9r6x7drCxePFneHYrwPfNMLclbaZIMrAbtsTYo6J6ULY23 pp66jUc9wfbc7Nr1pcjIV80qGzaspz7KtHZxHjz4b7mYvbyqq1nK2gVvS4KYvlTfe5AJu1Kl8qqo ZsjRn3zyiZo1XRYufEcyUX3TyKANuU1M04cO5ejlyzvLnmW8WrFiWq4S7Z13/uro6Kj9jnfeMjRf 1NNeBli7CHiepzy5xiQUEuQ6dTxFAefOfVup/CNNOsufZNI+KJA3GxLtIUNCzWY38WDJtSZNfESO ZWXxYOYO1LPoqKdxuXnze7P/1EHesFreg1S/ACJvyi3f3llW6pa0NJ3NLY+u+4u+8h7d8jfPdNtj reielO2NtzF0fEsR8is3DS5OUQ1bfo8wVwlisBN1rPT0JCm2tCFvx5W9HT++TveXJnOVaA+z4aP4 jzQL7QBb+AP+MGkl84WcnUh8rv7Ty4dPutyWc+c2/fTTv0wzi7kD9SwW6knhJ+WB3KTwf7jzf7gz d6CeQB4yfAC5SUE9GRVRT0A9md4oDB9AbqKeFNSTuQP1ZHqjMHwAuUlBPVFPooR6AtMbgyzDB7lJ QT0pqCdzB+rJ9EZh+AByk4J6op7MHagnkIcMH0BuUlBPRkXUE1BPpjcKwweQm6gnBfVk7kA9i/f0 RinkhauU3KTYb5ISnEI1KhIlQD0h/2drggBAhgJdQ2wB9QQyHIAMJUPpGmILqCeQ4QBAhtI1QGxR TwAyHIAMBbqG2ALqCYWUQ5MXEgQAMhToGmILqCcAAAAAoJ4AAAAAgHoCAAAAAKCeAAAAAIB6QvGG p7kByFCga4gtoJ5QQPAbFgBkKNA1xBZQTyDDAYAMpWuILaCeQIYDABlK19A1xBb1BCDDAchQoGuI LaCeUHjhaW4AMhToGmILqCcAAAAAoJ4AAAAAgHoakJmZef/+fcIHAAAAAPmjntnZ2atXr54wYUJk ZOSXX35579497U9t27adPHly3g4ZHx9/4MCB3G6VkpKycOHCS5cuFVho8tZOa5GMiYl5mD2I63/z zTcjR46cMWPGtm3bcozMmjVrpPLmzZumlbKHRYsWaSvs3r3b9K+ff/75tWvXSAkAAAB4DOp59erV gICAevXqvf/++9OnT2/cuPELL7xw7tw5Y/WUFc6cOWN8yL59+86ZMye3DZ04caKDg0NUVNSji4VZ 4/PWTl3Gjx//xRdfPMweOnfu7OfnN2vWrFdffbVnz545RqZ58+ZSuWTJEq3m999/L1++fIkSJbQV 5B2F6SZHjx7t2LGjOO5DnixPcwMUZshQuobYQiFVzzfffLNWrVrXr19XL+/cuSPq+fLLLxurZ5cu XcaMGZPvrRQfqlGjhniwp6fno/ug/xE1fuXKlX/5y18eZg/Hjx8XZbx48aLtkRGzrFKlir+/v1az fPnyypUrG6in8Pbbbz98BPgNC4DCDBlK1xBbKIzqee3atZIlS44YMcK0csaMGQ4ODv/973+VekZF RY0ePdrNza1OnTpr1qyRyqlTpzo7O4vfiAmtW7dOamJiYlq3bl2tWrWAgIA9e/ao/YSFhcXGxmrL ss6UKVO8vLxatWqlrWNGXFycq6vr3r17pQEbN27U6pOSkgIDA+WIsvnly5cNKq9cudK9e3ep9PHx SUhI0I4+d+7cYcOGSb2cjlnjTduZlpYmL+Vkq1evHh4efvXqVdvbL975+eefGzTj0qVL3bp1E1Ns 3Ljxe++916xZM7M9nDt3ztHR8dNPP7U9MmKWr7/+uojmhQsXVE2HDh2GDx9urJ7iuOXKlfv999/J cADmYKBriC0UnHru3r1bVGb9+vWmlT/99JNUrlq1Sqmnh4fH7NmzDx48OHjw4KpVq2ZlZaWnpyu/ EcHKyMiQ1WTln3/+WZb79+/fp08ftR/TO6ayXKNGDXHcw4cPi5OFhobqtic4OHjcuHGyIFrWo0cP rV5sT9wxOzv79OnTd+/eNagU9x0yZMiNGzfmz5/v6+urHd3FxUWUOjk5Wf5k1njTdsqf/P39f3lA +/btO3XqZGP7b968KUH7/vvvjZvRrl070T4R5ZdfflnE1DICEyZMEPscOHBgamqqLZERs1y2bNlT Tz01a9YseSkCKn0kbmqsnpmZmU5OTps3bybDAZiDga4htlBw6inSqd3gNPUSsZ9//OMfypbGjx+v 6tPS0mTlXbt2/WH9M+sFCxZ4e3vrqme/fv3U8uLFiz09PS23/fXXX8WHxMxkeeHChaVKldLuZbZp 0yYoKMjs6VLLypMnT0oL4+LiRBwPHDgge0tJSVFHHzp0qLaaWeO1dp46dUo2V7dC/3jwBR15Ka2y pf1HjhyRldV3gHSbIedlavkrV67UVU913OrVq7u7u2siaxAZMcsVK1ZMnDixUaNG8vLDDz8cNmzY tm3bjNVTePrpp2VXZDgAczDQNcQWCk49lTCZKci5c+ekcsuWLX9YPOvp6uoaHR1taW9r16718/Nr 8oBatWrpqqe2vGzZMg8PD8vGyAqVKlUa8YBBgwZJG2bOnKn+JH4ZGBhYsmTJsWPH3rlzx1plQkKC bNWyZcsX/2Tnzp2WZ2FNPdXm2qOW58+fl5c7duywpf1Hjx6VlWUTa81ITEw03bmBev7x4LtfnTt3 LlOmTHp6unFklHqK40ql9Obzzz//ww8/2KKeXl5eup/s2w5PcwMUZshQuobYQmFUz3v37tWsWbNX r16mlfPmzStXrlxaWpqZcqWmporfiDOZ2VtycrL4n1LVzz77LG/qmZWVJZUjR46c/ydBQUE+Pj6m 64gFuri4SPOsVZ44cUJaaPk5so3qqfTx22+/VfWbNm2Sl+peY47t//3338X2lKfqNuP27duikipK fzy4PWygnn88uNOpHus0joxST1kQ6e/YsWO9evVkOUf1vHv3rqzw3XffkRgAAABQcOopfPHFF2XL lhXNUi93794tJjdt2jRNywICAq5duyYCNH369KpVq6qfkIyIiGjXrp1aJykpSdTz1KlTKSkpAwYM 0IwqV+oZHx9frVo17ZFNQX2lRt22TExMzMzMzM7O9vPz0344U7fS399fGqY+hb9165ZqrZl6mjbe 9K/3799v2rRp//79ZSs55d69ezdr1kz2/4dtd207dOiwePFig2aI8jZq1Gj58uVRUVH169eX8zXb wy+//LJ9+3b1u6pLliyRqJ48edI4Mpp6zp49Wyr//ve/26KecqAqVaqofYoES8+SIQAAAFAQ6qlc SkTE29u7Tp06FSpUiI6OVr6llKtv377PPPOMyJYoqXZH8NChQ3Xr1vXy8lK38UJDQ5988smaNWsu WrRI9FR90yhX6tm1a1dLQ2rYsGF4eLgsyLHEaKWFISEht2/fVn/VrRT9DQ4OdnJyql27tpubm+XH 5ZaNN/1rcnKy6GbFihXLlSvXokULdcvTRvXcunVr48aN1e9l6jZDKsPCwmS3EyZM+PTTT6UBZntY s2aNvA0oX768NE+U8csvv8wxMpp6/vbbb0uXLr1y5YqleoqSOv7Jiy++KJVDhgxRkioEBgY+++yz ZAgAAAAUkHr+8eC/4Tlx4oSYltmvad64cePu3bvy1wsXLmg+qiGV2vppaWlq+dYD8v0Ebj7Alkoh PT09x/8PybTxZsi55O3/+4mNjZ09e7YtzXjllVeCgoIs66VJ0hG6P+2ZX/zwww/9+/cnJQAAAOCx qSfkF19//bW1P33wwQdjx45dsWLFa6+95uzsrN1CLmDWrVunflXKFjJSrSo4T3MDFGbIULqG2ALq WdzZvn37lClTBg0aNGHChB9//NEu2vwvh+ZbXgi/+M0u3T/RpwCFOXkJAl1DbAH1BPtLYylflWix skLbA6Nmm94EJcMBmIOBriG2gHpC/qunVr4q4afdBCXDAZiDga4htoB6wiNUT9OboLJg8CQoADAH A11DbIu1euo6BIXykOXs1/wuPUBhhO9b0DXEFh6zehICyNs7SNOysX6/77uP++bZPvF1uv8yfSl3 PQEAAAD1hHxWz5XlXkrsNDqxc8SqSv5JPcdf2ronOzOL4AAAAADqCfmsntzmBAAAANQTCkg9uc0J AAAAqCcUBPxvRgB2ChlK1xBbQD2hSMFvWACQoUDXEFtAPYEMBwAylK4htoB6AhkOAGQoXUPXEFvU E4AMByBDga4htoB6QuGFp7kByFCga4gtoJ4AAAAAgHoCAAAAAOoJAAAAAIB6AgAAAADqCcUenuYG IEOBriG2gHpCAcFvWACQoUDXEFtAPYEMBwAylK4htoB6AhkOAGQoXUPXEFvUE4AMty8yMzPv379f mHcIZCjQNcQW9QTITwye5l6zZs3CB2zduvXu3buF9hRSUlKkkZcuXXq8zfjyyy8X6nHr1i1rm7Rt 23by5Mn52IZ83+FjIT4+/sCBA/Z7eeRv+/m+hT0OnkBsUU+AvNC8efMGDRr07t3by8urXLly33// /WNpxrlz586cOWOwwsSJEx0cHKKioh5vuCIjIwc/oH79+i4uLoP/5OrVq6hnrrq4b9++c+bMya+d F8Dl8UjbDwCAekIxUs9x48ap5SZNmsiE+lia0aVLlzFjxlj7a2ZmZo0aNerVq+fp6VlIPmuW1rZo 0eKxmKKdqqdxFz8MBXN5PLr2AwCgnlBM1VMm165du6rlK1eudO/evXLlyj4+PgkJCaoyNTW1W7du VapUady48bvvvtusWTNVHxISsmzZMrW8dOlSWcdgJ0lJSYGBgVLp5eV1+fJlqZk6daqzs7PUiD2s W7fOspFxcXGurq579+51cHDYuHGjVp+WljZ48GB3d/fy5ctLkwwqbWyJtUpb1FOOGxYW5ubmVr16 9fDwcO0+qGaK169fl+WvvvrKoEmyh5iYmClTpsjRW7VqtWfPHl31jIqKGj16tByrTp06a9askcqB AwdOnDhRW+ftt9/+4IMPzDaUnUdHR5ttqOrnzp07bNgwacyNGzdsj5Xtp2DZxbJabGys8VlfunRJ u97ee+897Xqz8fKwvX+tnYgWFgm4Qfutdb0tvQkAgHpCcVRPmXrFHZ944onVq1er+oCAgCFDhoiI zJ8/39fXV1V27NgxKCjozJkz58+fF92UmVjV169fX5uG58yZ06hRI4OdyBwsM3p2dvbp06fV06Xp 6ekdOnQYPny4NCMjI8OykcHBwcqPRT569Oih1cv+a9euvWHDBtnPkSNHjCttaYm1SlvUU07B39// lwe0b9++U6dOpuopu5JKOUfTxls2SVauUaPGiBEjDh8+LDIUGhqqq54eHh6zZ88+ePCgSHbVqlWz srLE+CtVqnTnzh3luOJJhw4dsmVDVe/i4jJjxozk5OT79+/bHivbT8Gyi03v3Vo7a6lv167d8ePH xRFffvll7Xqz8fKwvX+tnYgWFvmTQfsNuj7H3gQAQD2hCGLwNLeoZ+nSpR0dHR0cHLZs2aIqT548 KS/j4uJkKj1w4ICTk1NKSsrZs2elUpROrbNy5Upj9dTdidS3adNG+atpMww+zfz1119lW/EPWV64 cGGpUqXUzSq1f7Pn7QwqbWyJbmWO6nnq1Ck5hHbLds2aNfJSWq7dpBwwYEDnzp2V6hk0SVbu16+f Wmfx4sWenp666jl+/HjtfpvsZ9euXb///nuFChVWrFghldIXIlg2bqjqhw4dmttY5fYUzLrYTD0t N5Eel/2vX7/e8nqz5fKwvX8NTkQLi0H7jbs+x97MMUOh0A6eQGxRTwCrGPyGhahnRESEzNbe3t5v vfWWqkxISJDps2XLli/+yc6dO7dv3y6VFy9etFE9dXci9TLrBwYGlixZcuzYseounbF6ygRfqVKl EQ8YNGiQ7HPmzJna/n/88UfTlQ0qbWyJbmWO6qkOoQXn/Pnz8nLHjh3KP2RNeZmUlJRjk0yFbNmy ZR4eHroGafqsp6ura3R0tCy8/vrr/v7+svDcc899/vnntm9oWm97rHJ7CsbqablJYmKitevNlsvD 9v615UQM2m/c9Tn2Zo4ZCoV28ARii3oC5FE91YeVYpYlSpSIj4+X5RMnTsj0uXnzZtM1U1JSHB0d 1X0yS/WcO3euWp40aZJST92daMjc7OLiMm/ePGP1zMrKkgl75MiR8/8kKCjIx8dH2/+CBQtM1zeo tLElBpUG6nn06FE5xLfffqtebtq0SV6qW3HKP0aNGlW9enVpiXGTcqueqampsh/pC1net2+fdJBI p/SLrjRb29C03vZY5fYUcquet2/fLlOmjHYnXvrUUj0NLg/b+9eWEzFof45dj3qiR0BsUU8gw3XU UxA9kvlYfdro7+/frl079bnkrVu3bt68KQtNmzYNCwu7evWqWE7Dhg01FejRo0e/fv0yMjKWLl1a sWJF7VlP3Z0kJiZmZmZmZ2f7+fnFxMSoNSMiImRNy+aJClerVs30mUv1bRJ1X0o28fX13b9/vywf O3ZMfbtZt9L2luhW5qiechQJTv/+/WXP165d6927d7NmzWQnmn/IsoTu6aefVuG11iQb1TMgIECO IuI1ffr0qlWrqm2FBg0aiK5JP+q22dqGZo5le6xydQpmXZyjeirbk2tp+fLlUVFR8vZGroRcXR62 92+OJ2LQ/hy7HvVEj4DYop5Ahuur5+3bt+vVq9ehQweZOMWQgoODnZycateu7ebmpj5A3LBhQ4UK FaRS3C42NlZTz23btrm7u5cuXTo0NHTatGmaeurupG7durKht7d3SEiIHFGteejQIan38vLS7nIp unbtGhkZadZmsd7w8HBZuHDhgszuohpVqlTx9PRU3//QrbS9JbqVOaqnkJycLM4h5l2uXDn5k7rv ZeofYjyyT7FDERRrTbJRPfv27fvMM8/IX+Wtgna/TRCXkhP/5ZdfrKln586dLTc0cyzbY5WrUzDr YlvUU/Yvvi7BnDBhwqeffirbmp2R8eVhe//meCLG7c+x61FP9AiILeoJxYs8P82dnp5u9j/EiD+p GrNn77KyspRR2bKTmw+wXFOsMQ+/y/jbb79ZHlq30saWWGueLaSlpVmLg43ByZEbN27cvXtX3h5I uNTdNY2ZM2e2bt3a2oba/VfLDR+m13J1CnnrYuGVV14JCgrK7Va56l9bTsSg/cZdn5F67VFkKBTa wROILeoJkM9Y+9oHPC7kXYGnp+fy5cuN1dOOzuiDDz4YO3bsihUrXnvtNWdnZ9P7u3bHvxyab3kh /OI3u7hQAQD1BMgLR44cmT59OnEoPPz6669RUVG6P4yqWLJkifZ76XbB9u3bp0yZMmjQoAkTJpj9 aoE9qqeUr0q0WFmh7YFRs41vggIAoJ4AAPCw6qmVr0r4cRMUAFBPAAAoCPXkJigAoJ5QlDk0eaHu zEehUApJOfv1d4xUhXPwJAjEFvUEyMsdF4IA8Hhz0LRsrN/v++7jvnm2T3yd7r9MX0qGMngSW0A9 gQwHgHxWz5XlXkrsNDqxc8SqSv5JPcdf2ronOzOLDGXwJLaAegIZDgD5nIOmtznNHu4kQxk8iS2g nkCGA0B+5qDpbU4ylMETiC3qCUUZnuYGeLzwvxkxeAKxRT0BAAAAAFBPAAAAAEA9AQAAAAD1BAAA AABAPaEQwNPcAGQo0DXEFlBPKCD4DQsAMhToGmILqCeQ4QBAhtI1xBZQTyDDAYAMpWvoGmKLegKQ 4QBkKNA1xBZQTyi88DQ3ABkKdA2xBdQTAAAAAFBPAAAAAEA9AQAAAABQTwAAAIDiTnZ29r179x7F njMzM+/fv298RGvroJ5QoPA0NwAZCnRN4Y/t559/fvLkSbUsLrVw4cLTp09rRrVo0SL5Nx/bsGbN mt27d5vWLF68+MSJEw+525UrV1auXNmWNW053/j4+AMHDqjKtm3bTp482fiI1tZBPaFA4TcsAMhQ oGsKf2zbtGkzYcIEtbxr1y4HB4dp06aplzt37qxXr17+tqF58+aRkZGmNU5OTv/85z8LTD1tOd++ ffvOmTMH9QRGTwAgQ+kayOfYvvvuu6KDavmDDz4oUaJE586d1ctJkyaNGDGiiKlnbs8X9QRGTwAg Q+kayLfYJiYmivzduHFDlkNCQnr27FmlSpXs7Gx52aRJkw0bNshCTExM69atq1WrFhAQsGfPHqkZ PHjwRx99pO3kzTffXLBggSxcuXKle/fu4mQ+Pj4JCQm5VU/LAwlhYWFSP2XKFC8vr1atWmn1qamp 3bp1k9Y2btxY9qmJYFJSUmBgoLyU9S9fvpyH85UjxsbGWmqltSNq6wwcOHDixInasd5++22xW9QT GD0BgAyla4jt/+fu3btly5Zdt26d6JdI1b59+xwcHH755ReRtjJlyvz++++yzqpVq37++eeMjIz+ /fv36dNHapYsWeLt7a2MTYRM1jxz5owsizIOGTJExG7+/Pm+vr666ile+IkJJUqU0NTT8kBK7GrU qDFixIjDhw+L14aGhqr6jh07BgUFyXHPnz8vEqmJoOjp3LlzpW2nT5+Ws8vD+ZrqpumytSNq6yxd urRSpUp37tyR5evXrzs7Ox86dAj1hAKCJ+UByFCga+wituKCo0ePPnjw4HPPPScv3d3dFy9e/MUX X0i92ZoLFiwQ45SF9PR08art27fL8kcffSROJgsnT54UjYuLixOTO3DggJOTU0pKiqV6NmzYcJgJ jo6Olh+4awdSYtevXz+1LA3z9PSUhbNnz8qx1E3KP/734+82bdooQbQWhxzPV1c9DY6orSPmWqFC hRUrVshybGysSLBBd6CeAAAAUByZPn26r6/vxx9/LCIoL3v16jVo0KBXXnll1qxZaoW1a9f6+fk1 eUCtWrVU5auvvhoeHi4LPj4+q1atkoWEhASRs5YtW774Jzt37rRUT4MP3HUPZCqCy5Yt8/DwkAWx XjnWxYsXLUVQpFMksmTJkmPHjlU3IHN7vrrqaXBE0/Vff/11f39/WRCv/fzzz1FPAAAAgP9hz549 jo6OIkzqdt3cuXPr1q1brVq1w4cPy8vk5GTRuC1btsjyZ599phmhiKazs/OGDRuqV6+ufoDpxIkT ImebN282OJaBelo7kK56pqSkSJt37dplKYKKHTt2uLi4zJs3L7fna009DY5ouv6+fftkNZFO+auu +KKeAAAAUKzJysqqUKGCWOO5c+eUPMmyMrw/HnxrR4zw1KlT4l4DBgzQfCs7O/upp55ydXXVfqtI EJ9r166d+rD71q1bN2/etF09rR1IVz2Fpk2bhoWFXb16VRrcsGFDbf3ExERRYWmen59fTExMbs/3 D+vPelo7otk33Bs0aFCmTJlRo0YZhx31BAAAgGJKly5dtLuM4m1ly5YdMmSI9tfQ0NAnn3yyZs2a ixYtqlq1qvYFoHfeecfR0VH7hfY/HtwaDA4OFpusXbu2m5vbjh07bFdPaweypp4bNmwQg5TNfX19 Y2NjNRGsW7euLHt7e4eEhNy+fTsP52tNPa0d0Uw9xXfVV5dQTyhQeFIegAwFuqbIxDYtLU39X5G3 HmC8cnp6+qVLlwrgQGKNuge6+YBHEUNrRzRl5syZrVu3znFXqCfkM/w+CAAZCnQNsS1uiJt6enou X74c9QQyHADIULqG2MKj5ddff42KisrIyEA9gQwHADKUriG2UFhAPYEMByBDga4htoB6gn3Ck/IA ZCjQNcQWUE8AAAAojvzLoXkhKfQF6gkAAABQQAZMEFBPAAAAANQT9QQAAABAPVFPAGN4mhuADAW6 htiinqgnkFoAQIbSNcSWLkY9gQwHADKUrqFrUE/UE4DUAiBDga4htnQx6glkOACQoXQN5ENsM1Kv 0cWoJ9gxPCkPQIYCXVP4Y5uZfvvgxPlxLkEFZoSoJ+oJAAAAxY7L2/Z/13roV04tC/g/GUI9UU8A AAAoLpje5nws/78l6ol6AgAAQNHH8jYn6ol6AgAAAOQ/FzfusmacBV/oDtQT8h+elAcgQ4GuKVT8 9HbMsTn/3FCvV5xr0FqPLhgh6glFCnIYgAwFuqZwxvbytgN7Br7/ddnW8XW6f12mNeqJegKjJwCQ oXQNPNrYZqReM7sJSohQT2D0BAAylK6BRxtbdROUyKOewOgJAGQoXQMFFNsC+9+MAPWERwJPygOQ oUDXEFtAPQEAAAAA9QQAAAAA1BMAAAAAAPUEAAAAANQTij08zQ1AhgJdQ2wB9YQCgt8HASBDga4h toB6AhkOAGQoXUNsAfUEMhwAyFC6hq4htqgnABkOQIYCXUNsAfWEwgtPcwOQoUDXEFtAPQEAAAAA 9QQAALsiMzPz/v37xutkZ2ffu3ePWAEA6gkAAP/D5s2bt23bZlYZFxeXnJysu37btm0nT56sluPj 4w8cOGC5zsqVKytXrpzvTU1JSVm4cOGlS5cKLDjWThAAUE8AAMgLc+fO9fDwML2RmZaWVrp06TNn zuSonn379p0zZ04e1PPcuXPW9m/AxIkTHRwcoqKiHl00zBpm7QQBAPWEQgFPcwPYXYampqaWKlVq 8+bNWs3HH3/cpk0bazsxVU9r5KieXbp0GTNmTK4an5mZWaNGjXr16nl6eub4iX+eyUPDGDyZmAD1 hMcGv2EBYI8Z2r179759+2ovW7RosWjRIlmIiYlp3bp1tWrVAgIC9uzZY6meYWFhsbGxmsJ269at SpUqjRs3joyM1NTTcidTp051dnaWFcQj161bJzVXrlyRNkiNj49PQkKCbiPj4uJcXV337t3r4OCw ceNGrT4pKSkwMFC29fLyunz5skGl7lHkFObOnTts2DCpj4qKMmuY6QmmpaXJSzc3t+rVq4eHh1+9 elXbg5zjlClT5FitWrXSAsXgycQEqCeQ4QBkqA7r169/8sknr127JsvJycmyfP36dVletWrVzz// nJGR0b9//z59+liqp+lyx44dg4KCzpw5c/78+ZCQEE09LXeSnp7eoUOH4cOHiwtKvdSIlQ4ZMuTG jRvz58/39fXVbWRwcPC4ceNkoVmzZj169NDqxfbEHbOzs0+fPn337l2DSt2jyCm4uLjMmDFDTlz+ ZNYw0xOUP/n7+//ygPbt23fq1EnbQ40aNUaMGHH48GFR29DQUAZPJiZAPYEMBwCrGZqZmenm5rZg wQJZfuedd3r16mW2gvzJ29vbQD3Pnj3r4OCwYcMGVa/7gbvpTkw/1z558qRsGxcXJ0p34MABJyen lJQUs21//fVXqT9+/LgsL1y4sFSpUtq9zDZt2ijlNV3fstLaUeQUhg4dqq1m9oG7doKnTp2SzdWt UGHNmjXyUlql1unXr5+qX7x4saenJ4MnExOgnkCGA4BRhkZGRjZv3jw7O1vsUBOstWvX+vn5NXlA rVq1DNRz+/btomIXL160VE/dnZgaXkJCgmzbsmXLF/9k586dZs2To1SqVGnEAwYNGiTrz5w5U/1J /DIwMLBkyZJjx469c+eOtUprRzF7dNWaeqrNtRM8f/68vNyxY4fZHpYtW+bh4cHgycQEqCcUEDzN DWCnGXr48GFxqU8++aRatWrqJzmTk5NF3bZs2SLLn332mbF6pqSkODo67tq1y0w9re3E1PBOnDgh hzb9npMZWVlZ4nMjR46c/ydBQUE+Pj6m64gFuri4zJs3z1qltaPYqJ5Hjx6Vzb/99ltVv2nTJnmp 7sLmi3oyeDIxoZ4AAFC8aNasWZkyZd566y31MikpSazx1KlTopUDBgzQ7mJae9azadOmYWFhV69e 3bdvX8OGDdX61nYSERHRrl077dD+/v7yUn0+fuvWrZs3b5o2LD4+XoRYe2RTUF82UrctExMTMzMz s7Oz/fz8YmJi1Aq6lbpHMVNPs4Zpf71//76cYP/+/WWra9eu9e7dW8Il+88v9QRAPQEAoHgxf/58 8bndu3drNaGhoU8++WTNmjUXLVpUtWpV9SUha+q5YcOGChUqODk5+fr6xsbGapapu5NDhw7VrVvX y8tL3RAVMQ0ODpZta9eu7ebmpj7I1ujatWtkZKRZa8Vuw8PDZUH2I8fy9vYOCQm5ffu2+qtupe5R zNTTrGGmf01OThbdrFixYrly5Vq0aKFueaKeAKgnAADkG2lpaepHNG89wHjlzMxM3f9qyNpOLly4 YPoLnenp6Xn7n4puPsCWShuPYtYws3NRPwUAAKgnAAAAAKCeUGzgaW4AMhToGmILqCcUEPyGBQAZ CnQNsQXUE8hwACBD6RpiC6gnkOEAQIbSNXQNsUU9AchwgKKXoYWk0BcMnsQW9QTIB3iaG4AMRQUY PIktoJ4AAFBYQD0BUE8AAADUEwBQTwAAQD0BAPUEAABAPQEA9YTHBk9zA5ChqCeDJ7EF1BOYUQCg sGQoAwUxIbaoJwAZDlDcMzQj9RoDBYMnsQXUE8hwAHiEGZqZfvvgxPlxLkEFlr8MFMSE2KKeAGQ4 QLHL0Mvb9n/XeuhXTi0L+D8ZYqAgJsQW9QTIH3iaG6DwZ6jpbc7H8v9bogIMnsQW9QQAgKKP5W1O 1BMAUE8AAMh/Lm7cZc04C77QHQCoJwAAFHEyUq8dm/PPDfV6xbkGrfXoghECAOoJAACPnMvbDuwZ +P7XZVvH1+n+dZnWqCcAoJ5gl/A0N4AdZajlTVBCxOBJbAH1BHuCqQvAHjNU3QQlfxk8iS2gnkCG A0ABZWiB/W9GwOBJbFFPADIcgAwFuobYAuoJZDgAkKF0DRBb1BPAEp7mBiBDga4htoB6AgAAAADq CQAAAACoJwAAAAAA6gkAAAAAqCcUe3iaG4AMBbqG2ALqCQUEv2EBQIYCXUNsAfUEMhwAyFC6htgC 6glkOACQoXQNXUNsUU8AMhyADAW6htgC6gmFF57mBiBDga4htoB6AhQRMjMz79+/TxwAAAD1BDBi zZo1Cx+wdevWu3fvPt7GpKSkSEsuXbr0eJvx5ZdfLtTj1q1b1jZp27bt5MmTuZwAAAD1BDCiefPm DRo06N27t5eXV7ly5b7//nuDlc+dO3fmzJlH15iJEyc6ODhERUU93phERkYOfkD9+vVdXFwG/8nV q1dRTwAAQD0BHko9x40bp5abNGnSt29fg5W7dOkyZsyYR9SSzMzMGjVq1KtXz9PTs5B8eC0n26JF C1vWRD0BAAD1BPj/GDzNbaqeYpZdu3ZVy1euXOnevXvlypV9fHwSEhKkZurUqc7OzlIjdrhu3Tqp CQkJWbZsmVp/6dKl3bp1U8thYWFz584dNmyYrHzjxg15GRMTM2XKFC8vr1atWu3Zs0e3JXFxca6u rnv37nVwcNi4caNWn5aWNnjwYHd39/Llyzdu3Nig0rLNQlJSUmBgoFTK0S9fvmxQaYt6ynHldNzc 3KpXrx4eHq7dB9XU8/r167L81VdfGTTJxoAAGQp0DbEF1BPsEoPfsFDqKYYkEvnEE0+sXr1a1QcE BAwZMkTEcf78+b6+vlKTnp7eoUOH4cOHy8oZGRlSU79+/djYWLX+nDlzGjVqpHmYi4vLjBkzkpOT 79+/Ly9r1KgxYsSIw4cPi4eFhobqtiQ4OFhJcLNmzXr06KHVS0tq1669YcOGu3fvHjlyxLjSrM2C uJ14cHZ29unTp7WHWXUrbVFPiYC/v/8vD2jfvn2nTp1M1VN2JZUSItPGWzbJxoAAGQp0DbEF1BOK oHqWLl3a0dHRwcFhy5YtqvLkyZPyMi4uTgTrwIEDTk5OKSkpf1h84G6gnkOHDtVWk5f9+vVTy4sX L/b09LRsxq+//ipHOX78uCwvXLiwVKlS6makaons3HRlg0rLNrdp0yYoKMjsEVXdyhzV89SpU3II dcf3jwff0JKX0nJ1jlFRUQMGDOjcuXNWVpZxk2wJCJChQNcQW0A9oWiqZ0REhHiet7f3W2+9pSoT EhLEmVq2bPnin+zcuTNX6mn64KPpy2XLlnl4eFg2Q1aoVKnSiAcMGjRIjj5z5kytJT/++KPpygaV lm0WvwwMDCxZsuTYsWPv3LmjVtatzFE91SEuXryoXp4/f15e7tixQ52jrCkvk5KScmySLQEBMhTo GmILqCcUTfVUH3Nv3769RIkS8fHxsnzixAlxps2bN5utbKmec+fOVcuTJk3Ks3pmZWVJ5ciRI+f/ SVBQkI+Pj9aSBQsWmK5vUGnZZoUIoouLy7x583KsNFDPo0ePyiG+/fZb9XLTpk3yUt2pVec4atSo 6tWrS0uMm4R6AnMwXQPEFvWEooyNXzMScxIVUx8K+/v7t2vXTn0kfevWrZs3b8pCRESEVGrb9ujR o1+/fhkZGUuXLq1YsWKe1VN8t1q1aqbPXKovG6l7hHJEX1/f/fv3y/KxY8fUl991K3XbnJiYmJmZ mZ2d7efnFxMTo/avW5mjespRmjZt2r9/f9nztWvXevfu3axZM9mJdo6yHBYW9vTTT6sYWmsS6gm2 ZyjQNcQWUE8oUpiq5+3bt+vVq9ehQwdRKJGn4OBgJyen2rVru7m5qY+VDx06VLduXS8vL/VU6LZt 29zd3UuXLh0aGjpt2rQ8q2fXrl0jIyPNKhs2bBgeHi4LFy5ckD2IiVapUsXT01N9w0m3UrfN0uDK lSt7e3uHhITICaqd61bmqJ5CcnKy6KZ4drly5eRP6pan6TmK0co+GzRoIG5qrUmoJwAAoJ5QrMlI vaZbn56ebvl/C4n2ab+7mZWVpRzrUfPbb79ZHki30rLNNx9gtppupY2kpaXl6qx1wwgAAIB6QvEi M/32wYnz41yCeOYGAAAA9QR4VFzetv+71kO/cmop0qkKMQEAAEA9AfIB7Wlu09ucZoUoATz2DAW6 htgC6glFATFLy9ucqCdA4clQgkDXEFtAPaFIZTiFQinMhWEKPSK2gHpCkcrwjNRrx+b8c0O9XnGu QWs9ujDzATAHA11DbAH1hEee4Ze3Hdgz8P2vy7aOr9P96zKtUU8A5mCga4gt6gmQn1g+zW15E5Qo ARSeDAW6htgC6glFE3UTFPUEAABAPQEKCGv/mxEAAACgngAAAAAAqCcAAAAAoJ5QnOFpbgAyFOga YguoJxQQfIsIgAwFuobYAuoJZDgAkKF0DbEF1BPIcAAgQ+kauobYop4AZDgAGQp0DbEF1BMKLzzN DUCGAl1DbAH1BAAAAADUs6gzZ86cl4o64eHhkwEAoNgj04FMCtHR0cz+gHo+Nho2bOgAAABQbGjU qBGzP6Cejw3JQJWKfymKqFNr27btuwAAUOypVasW6gmo52PmpZdeUt55tSgybtw4ObvJkydr58vT 3ACFGTKUrimAKa9t27bEFlBP1LOA1JPfsAAozJChdE0xVE8ue9QT9UQ9AYA5GFBPYot6QqFRzzfe eKNr164XL15EPQGAOZiuQT2JLeoJj1Y9n332Wdnq7NmzhVw9hw8fjnoC4DdA16CegHqino+cn3/+ WX3Dna8ZAdgLZChdUwzVk8se9UQ9c6ee//3vf/v06VO9evUKFSq8+OKLmzdvVutYq+/YsWOdOnU2 bdrUrFkz+VOXLl1OnTqV7955+PDhp556Shrp4eFx+vRpOhoAAAqnegLqiXrmQj2vXLlSv379EiVK jB079pNPPnFzcytduvSePXus1WvbPv/882+99dbTTz8ty5MmTXpE3lmrVi28EwAAUE9APYuIeq5a tUoWGjZsqOpFNOXlX//6V2v12rZJSUmyvG3bNllu3rx5/n7Ornnn8ePH6WIAAEA9AfUsIuo5a9Ys WQgLC1P1y5cvl5eBgYHW6s0+rE9JSZHlUqVK/fbbb/nlnbVr18Y7AQAA9QTUswiq55dffikLfn5+ qv69996Tl+Hh4dbqzdRT3fX08PDIX+80eL6Tp7kBCjNkKF1TDNWTyx71RD1zoZ7nz5/39PR84okn FixYkJCQ8Nxzzzk6Om7atMlavbbtkCFDduzY0bFjR1keNWpUgX2viN+wACjMkKF0TTFUTy571BP1 zN033JOSkho3bqx+xsjV1XXRokVqHWv1attevXo5PqBz587nzp0rsO8VkeEA+A2gnsQWUE87U09L zpw5c+zYMVvqNW0VRBML+HtFZDgAfgOoJ7EF1POx0bBhQ3VjclxB4eLiIoeLiIjIl72p/6/I9u8V keEA+A2gnsQWUM/HhrpfaO/Y/rvxPM0NUJghQ+maYqieXPaoZ/FC3fWsVavWZHuG340HAAA7VU9A PclDAAAApjxAPYE8BAAAYMoD1JM8BAAAYMoD1BPIw/+Bp7kByFAotl3D14wA9SQPCxp+wwKADIVi 2zX8uBKgnuQhGQ4AZChdg3oC6ol6MnoCABkKqCexRT0B9STDAchQoGtQT0A9yUM7gKe5AchQKLZd w9eMAPUkDwEAAJjyAPUkDwEAAJjyAPUE8hAAAIApD1BPu2TgwIGSh/IvoQAAAKY8QD3h0TJ58mTJ w3fffbeYnG+BPc2dmZl5//79ohG07Ozse/fukSx2hz1ehHzfgq4phlMelz3qiXoWZQx+w2LNmjUL TfjPf/7zMAdq27atxLZoBG3lypWVK1cuJlfIwYMH9+7da1qTkpIi18OlS5ceb8O+/PLLhXrcunWr KF2E/MoMXVMMpzwue9QT9Symo2fz5s3r168/+E82btxobc1z586dOXPmsaunLc3Ilw2LlXr27t17 1apVpjUTJ06UHImKinq8DYuMjFRXplylLi4u2oV69epV1BPoGtQTUE/y0C7VU2Z3W3bSpUuXMWPG PHb1tKUZ+bJh8VHPe/fuubq6pqenazWZmZk1atSoV6+ep6dnIfnwWvquRYsWtqyJegJdg3oC6kke 2pl6XrlypXv37iJePj4+CQkJUjN16lRnZ2epER1Zt26d1KSlpQ0ePNjd3b18+fKNGzc2nfWnTJni 5eXVqlWrPXv2WB4xLCwsOjp69OjRbm5uderUWbNmjVY/d+7cYcOGyVFu3Lgh+5caWad69erh4eHq LpdlMyybqts2GzdMTU3t1q1blSpVZCsJi656mrVTdz9JSUmBgYFSKXG4fPmy1irLMxJCQkKWLVum lpcuXSoNsBYQy4DrHl0jNDR0+fLlavmNN954+eWX1XJiYmLPnj211b777rsOHTqYbhgXFycyunfv XkkT0xvhum2wvWG6YdGttEU9rcVTU8/r16/L8ldffWXQJNlDTEyM8RXLHIx6MuURW9QTUM/cYfA0 t6hn//79dz9Ae9AzICBgyJAhojvz58/39fWVmvT0dLGT4cOHy/ydkZGh1qldu/aGDRvu3r175MgR bdavUaPGiBEjDh8+LNO8qI/uTSkPD4/Zs2cfPHhQlKVq1apZWVmq3sXFZcaMGcnJyffv35fD+fv7 //KA9u3bd+rUyVozzJqq2zYbN+zYsWNQUNCZM2fOnz8vRqirnmbt1N2PSIxYY3Z29unTp6UNqlL3 jIT69evHxsaq5Tlz5jRq1MjagSwDrnt0jXHjxindlE0kzk5OTsrPJA4iW9pq8jZAa4AiODhYtpWF Zs2a9ejRQ6u31gYbG6YbFt1KW9TTWjyVesqupFLO1LTxlk2y5Yp9vBkKhXbwZMojtqgnoJ55QdTT 3d299QPCwsKk5uTJkxKcuLg4mdEPHDggvpKSkvLH/35grdYRT7LUsn79+qnlxYsXe3p66qrb+PHj tRtXsp9du3ap+qFDh6r6U6dOSb26PfnHg+9Cyctff/1VtxlmTbXWthw3PHv2rFSKQql1rH3gbtpO a7Fq06aNUlhtK4MzMlBPswOZnZS1o2ts3769fPny9+7d27Rpk5hZw4YN5aTEYqtXr3706FFttTp1 6pg2VVoluzp+/LgsL1y4sFSpUupmpEEbbGyYZVisVeaongbxlLhFRUUNGDCgc+fO6l2NQZNsuWIB mPIA9QTyMD/V0+wD94SEBAlOy5YtX/yTnTt3mqmbWufHH3+01DLtMbtly5Z5eHjoqpvpo3iurq7R 0dFm9Wr/Fy9eVC/Pnz8vL3fs2KHbDLOmWmtbjhuKqJke1EA9zdppGSsRqcDAwJIlS44dO/bOnTvG Z2SgnmYHMjspa0fXyMzMrFixoqw2fPjwf/zjH2+//fbrr7+emJj4/PPPa+uIipndLpWDVqpUacQD Bg0aJIeYOXOmcRtsbJhlWKxV5qieBvGUuMma8jIpKSnHJtlyxQIw5QHqCeThI1TPEydOSHA2b95s oG5qnQULFjykeqampsp+RPLM6o8ePSr13377rXq5adMmeanuw1k2w6yp1tqW44YpKSmOjo7qFqyN 6mktVgoxIRcXl3nz5hmfkajn3LlzVf2kSZN01VP3pIyPrujZs6f0r6enp1iaHP3pp58eNWqUqfp/ +OGHEydO1F5mZWVJr40cOXL+nwQFBfn4+Bi3IVcNMw2LcaWBehrEU8VNTrN69erSEuMmoZ7AlAeA epKHj1k9BX9//3bt2qnPQG/dunXz5k1ZiIiIkEptHVn29fXdv3+/LB87dkx9D9pG9QwICLh27ZpY zvTp06tWrar2b7qt7K1p06b9+/eXP8mavXv3btasWXZ2tmUzdJuq2zZbNpSDhoWFXb16dd++fQ0b NsxRPa3tJzExMTMzUxrs5+cXExNjfEY9evTo169fRkbG0qVLK1asqKue1k5K9+imLFmyRPappE0O UbZsWXl56NAhbYXWrVtrti3Ex8dXq1bN9JlL9WUjdY9Qtw22N8wyLNYqc1RPg3iquMmydKWotvYQ gm6TrF2xItNycTI+AFMeoJ5AHuYF468ZWaqnzNbBwcFOTk61a9d2c3NTn2OKr9StW9fLy2vLli3y 8sKFCzJtSxirVKni6empvrtjo3p27tz5mWeekb+6uLhoN67MTCs5OVlkQjypXLly4hzqhpZlM3Sb qts2WzbcsGFDhQoVpFJcKjY21hb11N2PHEi29fb2DgkJuX37tvEZbdu2zd3dvXTp0qGhodOmTbOm nronpXt0Uy5evOjo6KhZVKdOnSTy2l/T0tJq1Khh+vNJXbt2tbwexMLDw8OttcH2humGRbcyR/U0 iKcWNzFa2WeDBg3ETa01ydoVGxgY+OyzzxaGDIVCO3gy5RFb1BNQT6vk7Tcs0tPTLf8zG/EMU1P5 7bff1LxuO9pNKdmVuk1lgLiR7v7NmqHbVN225bih+Eoe/gsfy/3cfICNZ5SVlWVjGHVPSvf0bUFk Kw//rbNuG2xsmG5YrMXKFqxdIbm6qu00Q4Gusespj8se9UQ9GT0LiKL0n23aO6NGjVq/fj1xIEOL Mxmp11BPLntAPVHPopzhS5YssfzxcwDUEx5X8Le8EH7xm12oJ5c96gmoJxkOQIbCIw++lK9KtFhZ oe2BUbPNboKinlz2qCegnnmBp7kByFAwUE+tfFXCz/QmKF8z4rJHPQH1BACAR6WexjdBmfIA9QTy 8KGGVwqFQqEYl7Nff8eUB6gnkIcAAJD/b8s31u/3ffdx3zzbJ75O91+mL+WuJ6CeQB4CAEA+q+fK ci8ldhqd2DliVSX/pJ7jL23dk52ZxZQHqCeQh3mEp7kByFCwpp4Gtzn5mhGXPeoJqGcex1Y6HYAM Bd3gG9zm5MeVuOxRT0A9yXAAMhTyDf43Iy57QD1RTzIcAPUEugb1BNQT9WT0BAAylK5hyiO2qCeg nsbwNDcAGQrFtmv4mhGgnuQhAAAAUx6gnuQhAAAAUx6gnkAeAgAAMOUB6kkeAgAAMOUB6gnk4Z/w NDcAGQrFtmv4mhGgnuRhQcNvWACQoVBsu4YfVwLUkzwkwwGADKVrUE9APVFPRk8AIEMB9SS2qCeg nmQ4ABkKdA3qCagneWgH8DR3fpGdnX3v3j3iAGQoXcOUR2xRT0A988KaNWsWPmDr1q13794lIMas XLmycuXKxAEAmPIA9QTyMC80b968QYMGvXv39vLyKleu3Pfff2+w8rlz586cOVMIzyLPDcvthqgn ADDlAeoJ5OFDqee4cePUcpMmTfr27WuwcpcuXcaMGVMIzyLPDcvthqgnADDlAeoJ5GH+qKd4WNeu XdXylStXunfvLprl4+OTkJAgNVOnTnV2dpaaevXqrVu3TmpCQkKWLVum1l+6dGm3bt3UclhY2Ny5 c4cNGyYr37hxQ17GxMRMmTLFy8urVatWe/bssWyGrBMdHT169Gg3N7c6deqsWbNGd1dpaWlSI+tU r149PDz86tWrug2zbLwg2w4ePNjd3b18+fKNGze2fcPU1FQ5tSpVqshWkZGRuupp1k7d/SQlJQUG BkqlxOHy5ctaqyzPyPbYWp6UtbMAAKY8QgGoJ3lYQBg8za3UU2RFROeJJ55YvXq1qg8ICBgyZIjI zfz58319faUmPT29Q4cOw4cPl5UzMjKkpn79+rGxsWr9OXPmNGrUSC23bdvWxcVlxowZycnJ9+/f l5c1atQYMWLE4cOHRYlCQ0MtmyHreHh4zJ49++DBg+JSVatWzcrKstyVNMDf3/+XB7Rv375Tp066 DbNsvKqsXbv2hg0b7t69e+TIEds37NixY1BQ0JkzZ86fPy9GqKueZu3U3Y9ot1hjdnb26dOntcdq dc/I9thanpS1swA7zVCga4rqlMdlj3qinkUZg9+wEPUsXbq0o6OjBGTLli2q8uTJk/IyLi5OfOjA gQNOTk4pKSl/WHw8baBHQ4cONdWyfv36qeXFixd7enrqqtv48ePVclpamhx9165dZrs6deqU1Kvb k388+IKUvPz111/NGqbbeFUpjTQ7bo4bnj17VirF7dQ61j5wN22ntei1adNGKay2lcEZ2RJb3ZOy dnSw0wwFuqaoTnlc9qgn6ll81TMiIuLy5cve3t5vvfWWqkxISJD4tGzZ8sU/2blzZ67UUyJsqmXa y2XLlnl4eOiqm+kmrq6u0dHRZvWqVRcvXlQvz58/Ly937Nhh1jDdxqvKH3/80UA9dTfcvn276UEN 1NOsnZbRE+kMDAwsWbLk2LFj79y5Y3xGtsRW96SsHR3wG0A9iS2gnuRhoVBP9aynOFaJEiXi4+Nl +cSJExKfzZs3G4ia0qO5c+eq5UmTJuWXeqampsrRRfLM6o8ePSr13377rXq5adMmeXn8+HGzhuk2 XlUuWLDA4Ix0N0xJSXF0dFS3YG1UT2vRU4hZuri4zJs3z/iMbImt7kkZHx3wG0A9iS2gnuRhoVBP YdSoUWJF6vNZf3//du3aqU+Hb926dfPmTVmIiIiQSm3bHj169OvXLyMjY+nSpRUrVnxI9QwICLh2 7VpWVtb06dOrVq2qjmi67f3795s2bdq/f3/5k6zZu3fvZs2aZWdnWzZMt/FS4+vru3//flk+duyY 7M3GDeWgYWFhV69e3bdvX8OGDXNUT2v7SUxMzMzMlAb7+fnFxMQYn5GNsdU9Kd2ji6FKYMl9/AZQ T2ILqCd5+MjJ8WtGavn27dv16tXr0KGD2I8IaHBwsJOTU+3atd3c3NSnwIcOHapbt66Xl5d6KnTb tm3u7u6lS5cODQ2dNm3aQ6pn586dn3nmGfmr6K92I9BsV8nJySJnomLlypVr0aKFukFo2TDdxl+4 cEH2Jv1epUoVT09P9b0iWzbcsGFDhQoVpFIkLzY21hb11N2PHEi29fb2DgkJkVAbn5GNsdU9Kd2j BwYGPvvss+S+3WUo0DVFdcrjskc9UU/QIT09/dKlS2aVojvq7pqQlZV17dq1hz+QMipRXtm5uu1n QFpamu5BTRtmrfG//fab5bY5bpiZmWm5qzxE7+YDbDwj22Ore1K6pw8ATHkAqCd5+PjJSL32eBtg djMPAACY8gD1JA+LGpnptw9OnB/nEvTYn7lZsmQJP34OAMCUB6gneVg0ubxt/3eth37l1FKkUxWu CgAApjxAPYE8zAe0p7lNb3OaFa4KgMeeoUDXFJ8pj8se9UQ9izJilpa3OVFPgMKToQSBriluUx6X PeqJehbx0ZNCoVAoeShMeagn6gmoZ14yPCP12rE5/9xQr1eca9Bajy7c9QRgDgbuehJbQD1Rz0ee 4Ze3Hdgz8P2vy7aOr9P96zKtUU8A5mBAPYkt6gmoZ35i+TS35U1QrgqAwpOhQNcU+SmPyx71RD2L KeomKOoJAMCUB6gnkIcFxGP/34wAAIApD1BP8hAAAIApD1BPIA8BAACY8gD1JA8LITzNDUCGQrHt Gr5mBKjn4yc8PFzysG3btpOLBz0d3CcDABkKxbJrXnrpJZnyBg4cWKgmYr7einoWL1QeAgAAFBPa tm2LegLq+diIjo6WJJS3gO8WD+SN+7sAQIZCsewamexkypOJD/UE1BPIcAAgQ+kaYguoJxQteJob gAwFuobYAuoJAAAAAKgnAAAAAKCeAAAAAACoJwAAAACgnlDs4WluADIU6BpiC6gnFBD8hgUAGQp0 DbEF1BPIcAAgQ+kaYguoJ5DhAECG0jV0DbFFPQHIcAAyFOgaYguoJxReeJobgAwFuobYAupZqN+N UQp54SolNyn2m6QEp1CNikQJUM9CMb1lZ/9IKbSF4YPcpNh1ktKPhWpULD7dwdyBejK9URg+gNxE PSmoJ3MH6sn0xrDI8AHkJgX1RD2JEuoJTG8Uhg9yk4J6UlBP5g7Uk+mNwvAB5CYF9UQ9mTtQTyAP GT6A3KSgnoyKqCdzB+rJ9EZh+AByE/WkoJ7MHagn0xvDIsMHkJsU1BP1JEqoJzC9URg+yE0K6klB PZk7UE+mNwrDB9hvbt67ty8raz/JhXqingVWCj7pmDtQT7uc3uLiZn/yyd+kbNmyICNjjx0NTPfv H1i3Lvrdd4cNH95rxoxRK1fOunYtEfWEoqSeFy9uldxMSdmah4uqbdsXJk9+Pc/X5Pr10fv3f/mQ F3a+7ETN6Bs2xI4c2W/69JEJCQvtSD3tdIAt/AHPc1rJxLFq1UcTJgyOjHx1xYppd+/uLcikW7r0 /RMn1qtlObQc6NSpeC3mCxe+I/+qRq5dO1d29cYbvT/8cPTq1R9dv76TuQP1LDrTW/Pm9Rs0qNu7 d6CXV/Vy5cru3LnELkbG1NRt/v7NPTzcZASZN298RET/55+v/d13n6CeUJTUc+LE1xwcHKKihtpy FZ09u/H06Q35pZ59+wbNnh2Z263M2pC3nViWzp1b+/nVnzkz4tVXQ3r2DLAj9bTTAbbwBzxvafXb b9sDAvzq1XvqvfeGT5s2onFjnxdeeE4u2gJLujZtmsicpZaTkpbKgaZOfUu9TExcIg2znN3GjBlQ v34da7Mbcwfqaa/qOW7cQLXcpImPTBV2MTIOHdrd29v98uXvzN7Oop5QZHLz3r19NWpUk9nI09PN lk/xunRpI7NUfqln3opZG/KlJCevLVGixIULW+zxA3d7HGDtIuB5S6s33+xdq1ZN7fOx27d3i3q+ /HK7Aks6+atcEmp5xoxREmexfPVy0qTXRozoq81uly59a8vsxtyBetq9ekoWde36kloWq+vevX3l yhV8fGpp77e+//6zwMAWUinv4LXEkLdoYWGd3dyqVq9eNTy8i7ytVPUhIa2/+OLvavmzz97r1q2t WpaV58yJHDasp+zn+vWdsvngwd3c3V3Ll3eW96AGRzd95yoZ+8knf7N2Q1S3PVIZHT32/fffkMa3 atVw9+4vDE7KoPGyExkjatZ0adr02WPH1shqdet6Pffc0+vXRxs03uysGT4gx9xcvfojV9cqe/Ys c3Bw+OabeVq97sX597+/6excRq4umTXXrp2rzYKWF7xBgpheovIyJmacmoxln6ZFTa6SCK1bN65W rVJAgJ/auWUbtJ3kITFNbyw5OjouXjzZrD7HRBswoPOsWWNMtWP+/Il5y9B8UU97GWDtIuB5SKur V3eULOmk9E4r06ePlPw6enT1I006rezY8amTUwl1vrLPnj0DqlSpqLRS3pnEx8cYz26oJ+pZpNRT hgbJqyeeKLVq1UeqXqaTIUNCJUM+/niCr28dVSm5JIOF5MmpU/Hac0sdOrT0929+5MgqKe3bN+vU 6UVVX79+HW3WmT07slGjZ7T3hS4ulSXhxdvkbaUcqHZtD0k52eHhwysNjq6VH374QsaFn3/+SveM rLVHjitvZ2XcOXToaxkHQ0PbGZyUQeNlAnjvveGy8osvNqpTx/OVVzrJsCWDrPZeVrfxZmfN8AE5 5mZw8F+UtTRr9nyPHv5ave7FefPm93LlDx/eS3L5zp3dBhe8QYKYXqKm929kn6osWDBJRgn18N/K lbN++ulfcqz+/YP79OlgrQ3aTnKbmKZlwoTBIkMDB3a9ciVBq8wx0RYvjvL2dlfzumxYpkxp9dlo HjL0IdXTvgZYuwh4HtJKTRzr1kWbVv744z+lUi7mR5p0WpFeKFv2SfFUiZJI5969y+Xo0rPyTkPC devWLuPZDfVEPYuOepYu/YSMMnK5b948X1WeOLFeXsr7P0mJ/fu/lHdpFy9uVc+pBAW1NH205eTJ /1tTveFTz9TLyzNnvjEeGYcO7W56ILOnwawdXSsydsgKZg/o5NgeOW6/fh1V/aJFUZ6ebtrDN2Yn Zdz4N97orZbHjx/UuLGPGjSlSTJwGDTe9KwZPiDH3JSLVi6e5OS1svzJJ38rVaqkdhvM2sVp+dmf 5QVvnCCml6jlR4cyTcqsuWTJu2ZNnT9/ogiH8eePeUhMy+/ryLs+d3dX9bikLYkmZuDsXGbbtkWy PGvWmI4dW+U5Qx9GPe1ugLWLgOchrdTEod3g1D5hl96R91SPLunMSmBgi9GjX/nPf/793HNPy0uJ sKz5+edTpN7a7Hb79m5rn/4zd6Ce9qqeERH9JcFk8njrrT6q8rvvPpGrv2XLBi++2EiVxMT/G31k TJT0KFnSaezYcEkGbU3tqaBz5zbJy+3bFxuPjNqUpjY/cOB/vgNr7ehaOXjw37KCWaXptrrtMT3u F1/83cPj/w8KlidlY+MnTnzN37+59k1epZ7WGm/8DBDDB7lp+UxYpUrlR4zoK2XQoK5yUX344ejc zoKWF7yNCWL5UmZlEZFJk17TatasmePnV79JEx8ptWrVNG5DHhJT9zsinTu3lkQTxbEx0V59NSQ8 vIss+PjUUne28pahD6OedjfA2kXA85BWhw+vlJaYfZYtkqe9K3hESWdWpk0b4etbZ9688cOG9ZSX vXoFyrFeeaXTzJkR2uxm+nW069d3mr5vYe5APYvOB+6yIG9VS5QooR5YPH58nVzrmzZ9rLuJDHwu LpVjY8fL8i+/rJY1t279h/rTxo0fy0v1rlFydc6cSO0Bat2RUR1IPQ+kFeOjS7lzZ3fVqhX/+led d8wG7TEeFExPysbG66qntcajnmB7bmZm7pfrc+TIfh9/PEGVoKCWMpcbX5y2zII2JojZS5n85KB9 +nTQvutw7NgaMSQ1HS5Z8m6O6pnnxLS8GawewrMx0cR7nJ3LxMfHiDern63JW4Y+/LOedjTA2kXA 85BWd+/urVnTRVTPtFLiXK5c2dTUbY8u6czK7t1fODo6ytyxfPlUeSm7rVvXq1q1SocOfa3Nbtpn a6gn6lnE1VPKqFGvyJCnPg2RxGjXrpn66Cc9PenGjZ3qEWkZTWT68fOrHx09VmqysvY3bfps//7B ssLVqzt69w5s1ux5NT/16OHfr19HSaTPPnuvYsVyuiOjFDmKvAXct2+FLP/3v3HqYwXdo5t9xufk VGLWrDEyXqhmrFsXrTa31h5rg4LlSdnYeF31tNZ41BNsz025nGQqMv0ZSPW9B3W7yNrFGRHRXy48 41nQxgQxfSnZIXNwy5YNtM8E1BdiRD1Pnlwvw8WAAcGVK1cwbkMeElMrR46sEm9Tv7/46afvynHV LyPakmhyiKeequHqWkX7RZu8ZWi+fM3IXgZYuwh43qa8zz+fUrbsk2Lw2tOf0iPq540eXdJZvrGs UMFZ+1RdPe5puqZYr8Rc/kU9Uc9ioZ6///5DvXpPdejQUoYPGR+Dg/8iele7toebW1X1EY+8OZM5 xtvbPSSktays3f+Q0VCyUd47tmjhq96RS0lIWOju7lq69BOhoe0kt62NjOfPb5YaSa0qVSp6erqp h7V1j25WFi+eLO8ORfieeaaW5K00SQZWg/ZYGxR0T8qWxltTT93Go55ge2527fpSZOSrZpUNG9ZT H2VauzgPHvy3XMxeXtXVLGXtgrclQUxfqu89yIRdqVJ5VVQz5OhPPvlEzZouCxe+I5movmlk0Ibc JqbpQ4dy9PLlnWXPMl6tWDEtV4n2zjt/dXR01H7HO28Zmi/qaS8DrF0EPM9TnlxjEgoJcp06nqKA c+e+rVT+kSad5U8yaR8UyJsNifaQIaFms5t4sORakyY+IseysngwcwfqWXTU07jcvPm92X/qIG9Y Le9Bql8AkTfllm/vLCt1S1qazuaWR9f9RV95j275m2e67bFWdE/K9sbbGDq+pQj5lZsGF6eohi2/ R5irBDHYiTpWenqSFFvakLfjyt6OH1+n+0uTuUq0h9nwUfxHmoV2gC38AX+YtJL5Qs5OJD5X/+nl wyddbsu5c5t++ulfppnF3IF6Fgv1pPCT8kBuUvg/3Pk/3Jk7UE8gDxk+gNykoJ6MiqgnoJ5MbxSG DyA3UU8K6sncgXoyvVEYPoDcpKCeqCdRQj2B6Y1BluGD3KSgnhTUk7kD9WR6ozB8ALlJQT1RT+YO 1BPIQ4YPIDcpqCejIuoJqCfTG4XhA8hN1JOCejJ3oJ7Fe3qjFPLCVUpuUuw3SQlOoRoViRL8P/hk lSjMaY+8AAAAAElFTkSuQmCC --00c09fa21bcdfaf6a3048cdd0a05 Content-Type: image/png; name="device.png" Content-Disposition: attachment; filename="device.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gcdrt9la5 iVBORw0KGgoAAAANSUhEUgAABJoAAAOnCAIAAADnSLssAAAANXRFWHRjb3B5bGVmdABHZW5lcmF0 ZWQgYnkgaHR0cDovL3BsYW50dW1sLnNvdXJjZWZvcmdlLm5ldDpnVRsAAAJTelRYdHBsYW50dW1s AAB4nJVUYW/aMBD97l9x6ifQBg2spRqaplHWaa3KWiXQTv0yGecQVhM7sy+g7tfvnISWrGzSviSK /d7de+fnfPIkHZV5JqQi62Dh0YmCl7TShTQERwlJk8rMGoTPuNEKj0B6iKdt1D0u4dzZLdOr/cWk vT8paW2d/iVJWwMJuk0DDBsPbWyM3pZO4T4sTgRpynYa4F5zvZLg0hT8nCF/pSKIh95HFjeGuXxE D2wq9KO1JHD4s9QO65bPWkQ8DZRKxhhuliS1aSNgalMMsA+9HeyWyyBLfY2DjgnyeGTgeYu6Tf0g 7YXndV6wl0V8DW8ONdsZaVjrJ6+VzLInyO0GgSxIUDZn5wzb8iT4e8sHsKwPoP/Cn4zhTntNoZVY TPadFmh2q4eNfXsAbbjDSqpGEeNCxX+DmrY7kHKY8lvLzMMxyJZXFQYWRhWWA0hJwrbM54mVy1wT YQor63JIJUlYOZvXga3Ae6w7dHr1VJ8Cpxprqdy/Bv7BPjgBXyqF3r+4ewspp0cRlMEln0GdxIOT +T9yk9hLk1YDqI42w+C1jm87on/PXjujMVLpOMq1krl9RCMya4umWpyM4QuSWkPhLLE0bud2F297 vE/rN4UDpan6mtMXaFIhbjO+wovZNfDF9UHYaTQ66yR8/a7KDAZnMDgZn0bj4QCmF8kchtEg6oor uZGd+awLyQXEJecgR7gwG+2sydlqtQ9fLSWFpQo3Oumdc6jr/wPczcSgP+pHP4ZRbxkNe8Oz971B NHsXjU7FTCq4SeD7b9ioo/4qLTo1AACAAElEQVR42uzdCXxNd/7/8SxqjV3EkqRiSWnFUmMfiojU XkuRooZRg1bb+CvF1NaxdIyKpXRibXW6DJqQxNqKpYwtrVYxYq0tSJqIKCGL/2fy/Tlz5t5zT242 Wbyej/vwOPfk3O/5nu853+89b+eeex0eAgAAAAAKIQeaAAAAAACIcwAAAAAA4hwAAAAAgDgHAAAA AMQ5AAAAAABxDgAAAABAnAMAAAAA4hwAAAAAgDgHAAAAACDOAQDyyLZt27766quUlJR8XNH48eP7 9+9/9+5ddkemcthW4eHh8vKwsDBaEgCIcwCAfNCwYUOHR0qXLu3j4zN58uTbt2/npLRsv1z4+vpK CZcvX1ZPmzRp4ujoGB8fr57WrVt3xowZ5ivKeR2ytLHnz5/Pl11WuXLlBw8eaDOfffZZmTls2LDH ub8WLlwoL1+wYAH9CACIcwCAfItzW7ZsOXz48Ndff921a1d5KjOTk5OzUdrFixdPnz6dlpaW7frM mTNHKrB27VqZlhTn5OQkT9X1n3Pnzsn0gQMHLFYUEBBQsmTJM2fO5EWcsyj8scW5TNcrNm3apOYc OXJEzck0zuVuWxHnAIA4BwDI/zinZZL09PR69erJnMWLF8vTy5cv9+3bt1KlSjVq1HjnnXfUhxun TZv2zDPPbNy4Ub1EQtdzzz23e/dume7Zs6f86c6dOzJ948aNP/7xj56enqVLl27QoMH3339vq0C9 gwcPytqHDBki0xJXihcvLk8nTpwoT5ctW1ahQoXU1FT9ioKCgqR8WaZ27dpqMbVFP/zwQ8eOHatW rfrWW29phcfExAwdOlRWXb58+RdeeEElQ9GuXTt5lZqWAqVklZSsC7fVdKo+P/74o/VK1Z/279/f unVrWa9svnaxMdvrbdSokQTdl19+Wc154403ZBfo45xhO+dKW0mo7tSpU9myZVu1avXqq68S5wCA OAcAKChxTowbN07mjBgx4sGDBxLDypUrt379+sDAQJm5atUqWWDPnj0y3aFDB7W8BD83Nzf1wT/t ao/kh6ZNm8r0gAEDJKLIGX90dLStAvUkrckC1atXl2lZpn///vJUgpA87d27t0QUfbVlRadOnZJs I9Mff/yxSozqT97e3m+++abkFpk+dOiQzJcqNW7cWFKQxNHPPvtMVlGiRAl5ufxJpp966ilV8p// /Gd5ybp162TaunBbTWdrpdqfpJwJEybUrVtXpv/yl7+oP2V7vd26dZP2L1my5K1bt+7fv1+5cuW5 c+dqcc5WO+e8rdLS0tSnOsePHy+FeHh4EOcAgDgHAChAcS44OFjmSI7asmWLTLz00kvXrl07duyY TPfo0UMtIwHA0dFREppM+/j4aFeQtJS1fft2mahTp45+XSYF6vXs2VP+dPLkyeeff37p0qVdunQp Xrx4YmJi2bJlJUJYrOjho9vtLD5AuHPnTpmW4CTTQUFBMq2qJGWqxSSoyNM33njDJFZZF24e56xX qv3p+PHjMh0VFSXTbdq0MY9zma5X4pzaTStXrty4caOrq6vEMy3OmbRzDttq3759Kv6p+XzYEgCI cwCAghXnVK6YPHnysmXLZKJEiRLlH3nhhRfUMvPmzVOfgTx06JBMnD592iJlqdcOHz5cvy6TAvUk Uchis2bNcnJy+vHHH2fOnClP1b9aPTONc+pPKm/Iv9raR44cqRYLDQ2Vp5KLcjHOWa/U4k/Jycky LetKT0/PYZz79ddf5bXSgL169Ro3btxPP/2kxTmTds5hW3366acyERAQQJwDAOIcAKDAxbk7d+64 u7vLnH379kVEROgvJenFxMQUK1asatWqkh/at29vUZrEg82bN8vEM888o3+VSYF6x48fl8UqZkhL S9u5c6c8lUxSt25d6xVpEUV9bNIkoqgqtW3bVi3217/+VZ6OGjVKxSpnZ2d1g5lkFetYpRWewzin rs55enqqP2V7vSqF9uzZ09HRUXbE4cOH9XHOpJ1z2Faq/i1atFDzp0+fTpwDAOIcACCf49zy5cv/ +c9/fvDBB3Xq1JGnf/rTn+RPd+/eVV+LMmXKFDmP/+abb/S3uvXu3Vt9m6KWQPTxQGLh008/LdOB gYEnTpyQSHbhwgXzAvUkKGofEUxKSpLMI0/Hjh1rGOekNJmeOnWqhEyTiKKqVLx48U8//fTo0aM+ Pj6Shfbv3y9/6tKliyw2bdq0P/7xj2XKlJFpWUatyKLwbMe5119//YcfflCfI500aZL6U7bXq+Lc 559/rmVmfZwzaecctlV6erpEUAmQEydOnDVrlmRs4hwAEOcAAPkc55RKlSr9/ve//+STT7S/RkdH d+zYUU7l5a8lS5bs3r279qewsDCZWaFCBf2PUOvjwfHjx1u0aKH9ot327dvNC9QbNGiQLCDxUj1t 0qSJPA0NDTVc0ZkzZ2RFUqZU3jxZSZWaN2+uqlStWjWJQ2r+li1batSoIaFR1itBRZ9RLQrPdpwb PHiwY4aXXnpJAmoO16vi3G+//bZ27Vr1nZP6OGfSzjlvKzk8pEB17U59ApY4BwDEOQBAwSWB7dKl S9n7NbnExMSrV6+qW8VypUBbYmNj7fytvFu3bl2/ft1iZkpKiszPeeG2AvPtDAkJCY9tvSbtnMO2 un///s2bN+kXAECcAwCgiMvdnzUHAIA4BwDAY7J06dJp06bdv3+fpgAAEOcAAAAAAMQ5AAAAACDO AQAAAACIcwAAAAAA4hwAAAAAgDgHAAAAAMQ5AAAAAEDhjHMpSXevbT1wav5nx6cHy7+X1n8rc2hQ AAAAACi4cS45NkEi3AaX9l86tNA/Nri8cGzCIvkrzQoAAAAABS7O3YiM2uzeTeW3LfV7Rb0x8fj0 WccmTN3WpN9XxVrJzJAqXa5tPUDLAgAAAEABinOS5dRFOQlv8d9vSk//Xv+4dXLLzlYD5a9fFWt9 NWwfjQsAAAAABSLOJccmhFbzl7T2/dvvpj04apHltIf8VV2juxcTR/sCAAAAQP7HuZ/+vFxdl0u5 e9hWllOPHb8bIEsem7CI9gUAAACAfI5zKUl31ccsrT9jaf24dXLLV8Vab3B54UHCbZoYAAAAAPIz zl0N2ydZbmvDPplmuUcX6P5zE92l9d/SxAAAAACQn3Hu1PzPJJ5FvTHRzjh3bMJUWV5eRRMDAAAA QH7GuePTgyWeHZ8+y844J0tmLB9MEwMAAABAfsa5rF+d+zNX5wAAAAAg/+Nc1u+dG8S9cwAAAACQ /3GOb7YEAAAAgEIZ5x7+53fnPla/O2fyG+LqsbPVK/zuHAAAAAAUlDiXHJsQWq2r5LTv337XJNF9 //YUWSakSpd7MXG0LwAAAADkf5wTNyKjNri8oK7RWX/q8tbJLTtbBchfvyrW+mrYPhoXAAAAAApK nFOJLqRKF8ls6ptRvus/+tsXhvxr4Ngdvxu4vmRbdV2OLAcAAAAABS7OPcz41OVPf/5YXabTP2TO sQmL+IwlAAAAABTQOKekJN29GrYv0m+cBLndXcZdWv8t32MJAAAAAIUgzinHpwdLnPt5xgqaEgAA AACIcwAAAAAA4hwAAAAAEOeIcwAAAABAnAMAAAAA5EGcuxEZJVEt08e3L4yWOLerw2h7Fr65O4oW BwAAAIC8jXPqslvuPriIBwAAAAB5Hudu7o6S9JXpY1cHdXVujD0Lc3UOAAAAAPI8ztmJe+cAAAAA gDgHAAAAACDOAQAAAABxjjgHAAAAAMQ5AAAAAABxDgAAAACIc8Q5AAAAACDOAQAAAACIcwAAAAAA 4hwAAAAAEOeIcwAAAABAnAMAAAAAEOcAAAAAgDhHnAMAAAAA4hwAAAAAgDgHAAAAAMS57Dsy9q8S 546+Pp+mBAAAAIBCE+dS7yavL9Ve4pz8K9O0JgAAAAAUgjiXnpb2XZ+JkuW+dGol/8q0zKFBAQAA AKCgx7kfAhdKivu6ou/ViO/kX5mWOTQoAAAAABToOBe95J+S3/5ZvO3N3VHyVP6VaZkj82lTIBv+ c6GbR34/2EG522gAox/9HXRhHnnd17IT565u3vtVxgcsL362VZt5cd0WmfOVcyv5K0c2kI3RMD39 ex75+Mg0ztFEWW00gNGP/g66MI+87mtZjnPxR09tKPOCrObE+6ss/vTzrJUyX/4qy3BwA4yGxDne cgBGP/o76MI8ClCcu3MxJrRaV1nHoeGzDBc49IdZ8ldZ5rdfYji+AUZD4hxvOQCjH/0ddGEeBSLO PbiVtPW5QbKCyM5vpD1IMVxG5kf6vi7LyJKyPIc4wGhInOMtB6Bz0d9BF+aRz3HO/pz239Tn+7qt 1AeA0ZA4x+kdQOeiv4MuzOMxxTn1KcpN1bvZ8ylKWeb/PpP5h1kc5QCjIXGOtxyAzkV/B12YR77F uWx8x4n2jSnyWg50gNGQOMdbDkDnor+DLswjH+Lcf3+BIGxflor+z+8ZOGf8nsG6LRzrAKMhcY63 HIDORX8HXZjHY41zNyIf/T740vXZ2MEWvzYOoKCNhmlpUffvHzZZ4MGDI6mpRxk9c30HFY2G5fQO BXn0e3KGL/o7iHPEOWOJpy58XdFXSvwhcGG297G8VkqQcqQ0jnggG6OhnJFERCx5882AuXPf3LUr OHeHjPXr51esWM5kgQ4dfjd9+p/yaMAKCfnw73//szw++eT9fftW37y5K3vlhIUtOnr083yJc2vX zjp7NkxNSzCWbTl/PlzbccHB78m/2W5Y1T6rVs344YcvJXhzeocn8Fzw2rWd0gtiYnZm4/jM4fCV KwNLrhSS128E9HfkURfW3uV37FienHyosKSpfO9uuRbn7t2ID/N6SYr7ru+k9LS0bO9jee13fSZK OVKalMlBD2R1NOzevV3Llg3nzw989dUe/ft3VjMvXdp64UJEYY9zLVo0bNiw7vDhvWQbGzTwKlGi +KJFE7NRzqBB/h9+OCFf4lz79s9PnjxCTe/fv9bBwWH27DfU0717V3t7P52ThpX2adSoXteubWUf 1ajhmpi4jziHJy3OTZnyR+lW06aNsueAtBgYczh8ZW9gsahDroxOtt4I6O8o4F1YvYsNGODn6VnN xaX0vn2rC0Wcy/fulmtxbv+AKVLWzpbDU+8m53A3Swk7WgyX0qRMDnogS6NhdPQmJyenq1d3WMzv 2bP9+PFDikCcmzDhVe3psmVT5Lzts89mF6IPW0rjyFao6Xnz3pKdJW8D6unUqX8cN25QDuPcpEl/ kIkrV7aXLJnNrMvpHQrvueCDB0eqV6/i7f20h4ebPR+btBgY83T4srMOufKw9UZAf0fBj3PqXUwe zz9ff9Ag/4Kf5QpCd8vNq3OSvnLrelrulgY8OaPhpUtbHR0dV66crp/5l7+8XqZMKYlhcpazaVOQ zJET/XbtmlapUqFz55YHD36qFhs6tLvMnzVrrKdntTZtGmvzb97c1bt3h0qVyjdtWl/SlBbnDAvR nw/FxkZKmW5ulatVqzxsWM9ff91tvqIbN77t27eTlF+/fq1vv/17pnFOHr16vdCoUT1bLx8xovff /jZeW/j11wdIAlQVWLx4klZJWaxmzaply5aRDbSzJtmOc3v2rHJ2drp16z/XzXr0aNe/f2dpWPXB SHnrCg9fbGvt0rDTpo16++1XpD3r1vUICfnQ5I0wPn6Pi0tpta9lYxcunDB6dH8pUNZruFP69Om4 bt1fVCFjxw546aWOWm3VfzR+990aP79WUoLssuvXvzFpJYvVcXqHx3ku+PXXC6pWrXTo0DoHB4ct W5Zq86Wvffrp/x3ha9bMlAHNcGBUw5f10GQylOmPdm1gkVQpZeofalS0HjOt62AxOmVpCDV/I7Cn zw4Z0t1wzMxGZ6e/I4dxrmfP9vIWb3LoGr4x2eo1hoOA4VtkVk8JCkJ3y6vfnQOQX6Ph5MkjZGT5 wx96abeW3b79XZcurceMeVnGiHv3DsqcDRv+9sMPX8r04MHdBg7sogWG6tWrjBs36Pjx9TKUyCm+ mv/ii238/VtfuBBx+fI2GRC1OGerEC3OyUp9fVucOLFRHp06Ne/ata35iuQUZ+TIPjJOffTRZB+f uvbEuQ8/nFC8+FMpKUcNX75q1Qwvr5oqLElrlCpVQn2oSV9JeVWdOu6So5KTD/388wY7a5LtOCdr KV26pJy3Sa0kyB0+/Jmcd0r7yFuRVO/OnQO21i51dnd3W7Dg//344z/lzaZy5fJqqy3aR/aFvKnI O5wEP/WlNfJCV9eKc+e+efp0aGrqUcOdIm+fKsJJ9aRkCZzqLVCOGTlllAk5ZZQ3Eqnz+fPh2v0M tuqpXx2nd3ico1+3br9X54LNmz/Xr5+vNr9hw7paRpJBo0mTZwwHRltDk8lQpj/a9QOLlKkey5dP lTFK3U5jPWYa1iHbQ6j5G4E9fXblymmGY2Y2Ojv9HdmOc9IdJHpJx9m4cYHJoWv4xmSr1xgOAtaH cfZOCfK9uxHngKI2GqqbiatVq1yzZlXtc+e2Ps+zbNkUGU20wSIg4EU1vWLFNA8PN5n45ZetkjfU VSNbH7a0KESdi5w7FyYvVP/frKokTy9e3GJrRWfP/mf5r79eIEPw0aOfS6K4dm1npnFOApuTk5Oc Bhm+XE6VypQpFRm5Qpb829/GSy61qKR6lcWdKvbUJCffbKmylqSyZ5+tLU9lN0kjfPLJ+zLfZO1S 53ffHa7976Mss3//Wuv2adzYu1UrHxn016yZqd4k5IWjRvVVC9jaKdJEZcuWkfi3detH8uYnhciO ljcMOYpOnvxa3fKnIn2mraRfHad3eJyjnxzJchxGR2+S6b///c9PPVVM+w97W2dy1h+2tB6azIcy /dFu/VnNw4c/K1265OrVM0zGTFsf+MzqEJrpG4E9fdZwzMxeZ6e/I3txrkSJ4hKN5JDbvn2Z+duN 9RuTSa8xiXPaYZyTU4L87W7EOaAIxjl5/Prr7u7d25UqVULGC+szhtDQhS1bNnz++fryqFWrhvW5 yKef/sXd/T+nCDLQyMiifShcH+fMC/n227/rX3j58jZ5unv3SlsrUsu3bt2obdsm6rF37+pM49x7 772mzopsvfzVV3sMG9ZTJurXr7Vhw98MKxkV9T/fI2dPTXIS5+bMGefjU3fp0ndHj+4vT19+2W/4 8F6vvNJ1/vxAk7VbnClWrVopKOgdWx9TkXcviWczZoy2eKGtnfLgwZHy5V3kr2PGvLx8+dR33hn2 pz/127Nn1XPP1VFLyvulpM1ixZwnThx29+5B++vJ6R0e2+gnB16FCmXHjRskD+lTcnz+9a9vZzXO 2RqaMh3KrJ9KN5TTu6lT/2g+8NqqQ1aH0EzfCOzss9ZjZvY6O/0d2YtzgYGDr1//Rt7Z33hjoPmb sq03JsNeYxLnLN4is3dKkL/dLRfi3Jdffnns2DHt6aVLl7744gsOViB/45w6mdBuINGfMZw+HSrD n/p/r9WrZ5jHuWvXdjo6OmoXgrQ4l2khJ09+LWvfufNjNX/r1o/kqfqPc8MVnTmzWRbYtu0j+78K 5f79wzLiv/XWKyYvl5GxTJlS4eGL5bxK+w0ArQLqVerT6trDnprkJM4dPPipNKmvbwv1JS4LF06o V8+zSpUKx4+vN1m7vtFu3twly8i+MLnrQN4IVRjTv9Bkp/Tv31na1sPDTd4IZYHatf/TsBZvHvKm 6OpaccmSd+2sJ6d3eGyjX0rKURlJ3nwz4KOPJquHv39rOUPS4px0NO07h7IU5+wcyiye3rq1T1Y6 cGAX7SdDbI2ZtuqQ1SE00zcCO/us9ZiZvc5Of0f24px6F4uMXOHk5BQWtijTN2X9G5NJr7E1COgP 45ycEuRvd8uFOFe7du25c+dqTyMiIp5++mkOViBfRsMTJzbKIKhumlq1aoacPahfOQsMHNyxY3Pt 7mGZf+5cmES1IUO6aVfbbJ0iNGvWYOjQ7r/+uvvw4c8aN/ZWy2daSGrqUXnh4MHdEhP3xcfvGTDA r3nz57SP/xmuSBKOVFJ9cCIpab/19+xrce633/519OjncromcS4hYa/Jy2WNTz9dvWrVStrPA1hU QF7i41P3yJF/yPS//x2iPpKeaU1yEufkvLNcuTIyXl+6tFV9HEum9SdkhmuXOnfu3FJaUl4+Z864 ypXLG7aPvBHKW4IcBg0aeKnvydRvrMlOkaOlfHmXVq18ZPrevYOlS5eUpz/99E/tO1GkWFmyZcuG 2hdm2qoncQ6Pf/ST074qVSrof6hKfSGK+o/tfv18AwJelAN7zZqZcmBrZ3L6gdHW0GTnUKZ/Kp1F RqfWrRupKwbmA6+tOmRjCM30jcCePms4Zmajs9PfkZM4J4+33npFcpr6qKHhEWj9xmTSa2wNAhaH cTZOCQpCdyPOAUVqNAwJ+VBOxMuWLVOvnqcMi//4xxw1X87LZY6nZzX1f8N9+nQsWbJ4jRquwcHv STBQN+XbOkUID18s8cPZ2UnGuMWLJ2lnIZkWcvp0qIykMm66uJSWnKD+h8xkRTJqd+v2e1lRnTru bm6V1QckLAZ6OT9zdHQsVaqEBMvx44foR1VbL3/vvdfkJdqPd1tU4MqV7fJUiq1UqbyHh5v6NoJM a5KTOKf+P177v3l5N5JdNnJkH/MNkUoOGuT/zDO1pLnkHU7730fr9hF163qMHTvg8uVt1u8BtnbK 1as7pJUkKKqnXbu2lXVpr5KDR/a7hOcePdpJljavJ3EOj3/069XrBYtPYstDRgn1QaZdu4Jr1qxa okRxGbVmz35DO5OzGBhtDU32DGX6p//616fSDaVfV6hQVj1UNQzHTJM6ZHUIzfSNwM4+az1mZqOz 09+Rwzgn7zXe3k936dJaMo/hEWj4xmSr19gaBCwO42ycEhSE7pa3cW7//v1+fn4VK1aUgerGjRtq 5s2bN/v27Ssz69evv2vXLjVz6NChQUFBo0ePlvmJiYkc60C2R8PU1KNnzmw2/AkUGae0L0SKjY1U 00lJ++Vh/vkBiRwxMQb3/tpTiCwTH7/H/p9PuX37O8N15enL4+IMKmleVE7iXDY25NatfcnJh+Rd TXai9vGtbD+yulPkIcnZ8Cpllhqc0zvk6ehn8khJOWrrmNcPjLnba+wfM03qkL31mrwRZHuMzeoL 6e/I3fdH6yPQ1huTYa8xGQRyeEqQ790tb+NcmzZtJKSlp6dfuHDh/v37ambnzp1HjhwpmW3ZsmU+ Pj5qZocOHVxdXefNmxcdHZ2WlsaxDuTRaMgjf39GnEaj84LRj/4OujCPgvUz4iZxrn379v7+/hcv XtT+eu7cOQcHh5CQkJMnT0ZFRTk7O8fExKg4N2rUKA5xgNGQOMdbDkDnor+DLszj8cU5b2/vmTNn ak/DwsIk4KlpCXJ+fn7FihWbOHHivXv3ZM6uXbsyvn+zddtH9u3bp+Lc9OnTOcQBRkPiHG85AJ2L /g66MI/HF+c6derUtWtX7enq1aslpOkX2LNnj6ur69KlS2X67NmzGb8MuN2iEOIcwGhInOMtB2D0 o7+DLszjcce5OXPmuLi4HDlyRKZjYmI6duw4efJk9ae9e/empKSkp6e3bNly8eLFaqavr68soz6B eefOndu3bxPnAEZD4hyNBjD60d9BF+aRD3Hu7t27AwYMcHBwqF27drFixTp37hwfH6/+VK9evYoV K3p5efXo0UMWUzMl8nXr1s3Z2blOnTpubm579uwhzgGMhsQ5Gg1g9KO/gy7MIx/inBIXFxcVFXXt 2jWL+bczWC+flJR0/fp1jmmA0ZA4R6MBjH70d9CFeeRznAPAaMjoyQ7i9A6Mfjzo76ALF/E4d3x6 MIcykPPRkEe+P9hBudtoAKMf/R10YR553dcccmUvcigDjOY0Ak0NgH4K0CsfM+IcAEZJmhoA/RSg VxLnADBKgqYG6Kf0U4BeSZwDwCgJmhqgnwKgV+ZtnOOrUAAwDtDUAOinAL2yUMY5AAAAAABxDgAA AABAnAMAAAAA4hwAAAAAoKjFOe73BcA4QFMDoJ8C9MpCGef4Nl4AjAM0NQD6KUCvJM4BYJQETQ3Q TwHQK4lzABglaWoA9FOAXkmcY8wCwDhAUwOgnwL0yqIW57jfFwDjAE0NgH4K0CsLZZwDAAAAABDn AAAAAADEOQAAAAAgzuW1lJSUtLS0otrKRXvraC4AAACgsMY5wzsLP//882Ajd+7cMSykQ4cO06dP z/fmCA8Pj4qKyvViC8jWPc5NjomJkd19/fr1x99cubJFedQsRRj3/dPUAOinAL2yUMY5w+/9nDBh wogMDRs2dHV1HfFIfHx8gQo8ly9fvnjxovZ00KBBCxcuzPVis7R1Fq/Na7m1yRamTJni4OAwbdq0 vG6u3NqiPDoSnhx8KzdNDYB+CtAri06c04wfP75Vq1aZFpJfca5nz55Sw7wuNktbl0dVepxSUlKq V6/u7e3t4eFhz8cmc9JcBfxIYJQETQ3QTwHQK4tUnFu8eHG7du2qVKnSuXPnQ4cOWZzB37p1S6a/ +uorNf/mzZt9+/atWLFi/fr1d+3apWbu37/fz89PZnp6et64ccN6pYariIuLGzFiRM2aNcuWLdu0 aVOZM3v27DJlykg5Ejw2b94sc4YOHbpkyRJteXnq5uZWrVq1YcOGadcVZaaU//7778va27Rpo5Wv sS5WbZ31S6zraf1aPVl1UFDQ6NGjZYHExETDxomNje3du3elSpVkG2fMmNG8eXM1v0ePHuvWrVPT a9eulWW0MrVNtqf8TBtfhISEVK1a9fDhww4ODlu3btXmG9bB/uYy2SP6amtbJKnS+39Jg9jZ7Lly JDBKgqYG6KcA6JVFLc5t3Ljx2LFjycnJgwcPHjhwoD7O3b9/v1OnTmPGjNEWlhPukSNHyjn6smXL fHx81Ew5dZbT9/T09AsXLshLrFdquAopqk6dOhEREfKSEydOyJykpKQuXbrI6iS3yMIP//e6kPzJ 19f3ZAapVdeuXbWqVq9efdy4cT///LOknT59+lis3bBYw5dY19P6tXpSjqur67x586Kjo9PS0gwb 58UXX/T397948eKVK1ckPklEUfMbNmyo5ZOFCxc2adLEIkjbWX6mjS+6des2adIkmZAw2a9fP22+ YR3sby6TPaKvtn6Lbj7y8ccfFy9ePDIy0s5mz5UjgVESNDVAPwVAryzocc78zkKTD1suX77cy8tL OzOeNm3akCFDunfvnpqaqmaeO3fOwcEhJCRETqOjoqKcnZ1jYmJkfvv27VViybRu2ipUUdZ3Q9n6 mN/58+dlee36WGhoqDz95Zdf1DIBAQFq/sqVKz08PKzXa12s+Uv0TWHyqT8pZ9SoUSaNc+nSJZkp kVUts2HDhqzGOfPy7Wl8aSVZ+MyZMzIdHBz81FNPaRfxbNXBnuYy3yNatR8afVbzyJEjpUuXXrNm jf3NnltHwpOD+/5pagD0U4BeWSjjnDnrOLdp06aWLVs+n6FWrVra2bMsJifK+/fv15bctWuXzGnd unXbR/bt2yfzJUv4+fkVK1Zs4sSJ9+7ds16p9SpUUd9//72dcU4tf+3aNTX/ypUr8nTPnj0WaWHd unXu7u72xDnDlxg2hXmc08oxbJzdu3frq52NOGdevj2NLyVUqFBhXIbhw4dLIfPnz89qnLNuLjv3 iPVTiV7VqlWbOnWq+RGYR0cCAAAAUHTiXHR0tCSBHTt2yPSaNWv0cU7OjN966y058z579qyaKRNy 6rx9+3bDkuWU2tXVdenSpRbzDVehilq+fLmduevUqVOy/DfffKPmb9u2TZ6qK065FedsNYWdcc6w cWJiYhwdHQ8cOGAY54KCgtS0ZJtM41z2Gj81NVW27s0331z2iL+/f/369c3rYE9z2blHLJ4mJibK SgcOHJienm5+BObRkQAAAAAUnTi3f/9+OZk+f/68BI8hQ4ZoYUOdGcs599ChQ2vXrq0+1yd8fX07 duyoPtp3586d27dvy8TevXtTUlJk4ZYtWy5evNhijbZWIeX4+PgcPXpUpk+fPq2+cTEwMFDmW5/E y1+bNWs2ePBgWWNCQsKAAQOaN2+uIoE9J/G2itW/xFY9LV5rK87ZahyptrRhfHz8kSNHGjdurBXb r1+/gICA5OTktWvXli9fPtM4l73GDw8Pr1Kliv6eOvWFKOrKnq062NNcdu4R/VOpp4TJ1q1b668i 2tnsuXUkAAAAAEUnzok+ffqULFmyRo0aK1asqFy5svouCv0peI8ePRo1aiSnzg8zLjd169bN2dm5 Tp06bm5u6kNu9erVk7NwLy8vWfLu3bvWKzVcxdWrV2UtEi0qVark4eGhvvHi+PHjUpqnp6e6XKM/ QY+OjpYTd0kdLi4usgnqgoydJ/EmxepfYlhPi9eaxDnDxomIiChXrpzMlOy6ZMkSLa5ERkbWrFmz RIkSstI5c+bYE+ey0fi9evWaMGGCxUxJlcOGDTOpg53NZc8e0T89ePCg7O7SpUtXeERVw55mz60j AQAAACjQcS4bdxbGxcWpi2N3MmS6fFJS0vXr1/VzbmfIxip+/fVXFRT1JOnZ+nk0Kcd6eTuZFJtp Pe15ra3GkUis5ug/bPkw45OQ2diWbDS+CZM62LnJOdkjOWn2XFlvYZccm5CL4wAe25ALgH4K0CuJ czbxbbwFlkWcA3Le2Xf8bti1LQcYB/J3L9AIAP0UAL2SOFf0nThxYu7cubQDcnEolMdXTq02lOsQ 9daH+ot1jAO8IQGgnwL0SuIcgIIe57THV04ttYt1jAO8IQGgnwL0SuIcgEIT5/QX62TC5M468IYE 0E8B0CsLbpzjwYMHD3lcWv8tbxh5ja9YAOinAOiVuRnnADw5/7Olf2xtGPBd30lbGgwMr9v35Ny1 XJ0DAAAgzgEo0HFug8sLe7u+vbd74MYKvvv7v3t956H0lFQaBwAAgDgHoEDHOS7HAQAAEOcAFMo4 x+U4AACAIhXnuN8XeEKYXI5jHHhsaGqAfgqAXpmbcY5v4wXAOEBTA6CfAvRK4hwARknQ1AD9FAC9 kjgHgFGSpgZAPwXolcQ5xiwAjAM0NQD6KUCvLGpxjvt9ATAO0NQA6KcAvbJQxjkAAAAAAHEOAAAA AECcAwAAAADiHAAAAACgqMU57vcFwDhAUwOgnwL0ykIZ5/g2XgCMAzQ1APopQK8kzgFglARNDdBP AdAriXMAGCVpagD0U4BeSZxjzAKQF+NASkpKWlpaYdnMglDbAjLkpqenP3jwgCMf4NQIoFcW+jjH /b4AzMcBOfX/+uuvJ0+ePGHChM8//1wfAzp06DB9+vTsrTQ8PDwqKiqrr4qJiQkODr5+/Xo21piT 2ma7whY+emVczgvR9ktYWNjMmTPHjBnzwQcfbNy48datW3a+dsOGDRUrVuTIBzg1AuiVhT7OAYCJ +Pj4zp07e3t7z5o1a+7cuU2bNv3d7353+fJl84AkC1y8eNG85EGDBi1cuDCr9ZkyZYqDg8O0adPs WdiiGjmMc9mrsEUdsleItbi4OF9fX3d3d4nZH330UWBg4HPPPbdr1y7iHAAAxDkA+D+vv/56rVq1 tMs+9+7dkzj30ksvmQeknj17jh8/Ptcrk5KSUr16dcmWHh4e9nxs0qIaOYxz2ZNHTTFq1CgvL6+b N2/qZ6anpxPnAAAgzgHAfyQkJBQrVmzcuHH6mfPmzXNwcPj3v/+tAtK0adPefvttNze3unXrhoaG yszZs2eXKVNG0oLkrs2bN8ucxYsXt2vXrkqVKp07dz506JAqZ+jQoUuWLNGmZZn333/f09OzTZs2 2jIWQkJCqlatevjwYanA1q1btfk9evRYt26dml67dm3v3r0Nq6HinPVa4uLipAKyCdWqVRs2bFh8 fLxWq6CgoNGjR0shiYmJWoUlVXr/rxkzZhhupnUd9Fttsl7z1pAlnZycgoONP3liq9jY2FhpmUqV KjVt2nTChAlanJNM2LdvX3lav359+6/vAQAA4hyAAu3gwYMSnMLCwvQzf/jhB5m5ceNGFZDc3d0/ /PDDn376acSIEZUrV05NTU1KSurSpcuYMWMkJyQnJ8tisvCxY8dkevDgwQMHDlTl6K+VyXT16tUl N/78888SLfr06WNYn27duk2aNEkmmjdv3q9fP21+w4YNtYy0cOHCJk2ayIR1NWytRRbz9fU9maFT p05du3bVauXq6irxNTo6Oi0tTV/hm498/PHHxYsXj4yMNNxMwzpohZis17w11H758ccfDVvJVrEv vviiv7//xYsXr1y5IgFYi3MSPkeOHCl5ddmyZT4+Phz2AAAUpjjH/b4AbI0DEuS0C3GalJQUR0dH iTEqeLz77rtqflxcnCx84MCBh7Y/Ybh8+XIvLy/DOBcQEKCmV65c6eHhYf3aX375xdnZ+cyZMzId HBz81FNP3bhxwyTOPTT6sKX1Ws6fPy/VVpfORGhoqDyVdanlR40apX+5xWc1jxw5Urp06TVr1phs pkUdmtd6RhVivl7z1lD7RbuDUc9WsZcuXZKJiIgINV/7sOW5c+dkfkhIiGS/qKgoaeGYmBh6BBgS aQSAXllo4hzfxgvA1jhw4sQJOde3+FCfpAiZuWPHDuuEU7Vq1UWLFllnmE2bNrVs2fL5DLVq1TKM c9r0unXr3N3drSsjC1SoUGFchuHDh0sd5s+fn9U4Z72WXbt2SVHXrl1T869cuSJP9+zZY711Fk8l I1WrVm3q1Knmm2lRh2cdyqlC7FyvYWscP35cFt63b591K9kqdvfu3fr5WpxTy7du3brtI4bFAgyJ AOiVxDkAhWyUfPDgQY0aNV5++WX9zKVLl7q4uMTFxVkEj9jYWAkGkhMsMkx0dHSxYsVU/FuzZk32 4lxqaqrMfPPNN5c94u/vX79+fS3OBQUFqWnJV1mKc6dOnZJqf/PNN2r+tm3b5Km6BmgS5xITE2Wl AwcO1L59xNZm2opzdq7XsDWSk5MrV6782muvWe8yW8XGxMQ4Ojqqa6f6OHf27FlZYPv27fQCgFMj gF5JnANQ1EbJTz/9tHTp0pIK1NODBw+6urrOmTNHSzidO3dOSEiQuDV37lzJGLdv35b5gYGBHTt2 VMvs379fcs758+clUQwZMkS7ZStLcS48PLxKlSr379/X5qgvRFGXkvr16xcQECAhZ+3ateXLl9fi nL4attaSlpbWrFmzwYMHS81lQwYMGNC8eXMV0mzFuZSUFAmTrVu3vnfvnvZXW5tpUQctztm5XlvX KpcvX+7s7LxgwQJpeVVaWFjY6dOnTYqV+UOHDo2Pjz9y5Ejjxo21Gvr6+koN1a8p3LlzR+1BgCER AL2SOAegKIySkigqVark5eVVt27dcuXKLVq0SLskJcFj0KBBzzzzjEQOiXnaRaHjx4/Xq1fP09NT Xa3q06dPyZIla9SosWLFCol86mtCshTnevXqNWHCBIuZkkmGDRsmE5GRkTVr1ixRooSsSKKmFucs qmFrLdHR0ZJ5JAe6uLi0atVKXSIziXPqm0gk5VZ4RFXDcDMt6qDFOTvXayvOiVWrVslaSpUqpdq/ R48eEudMio2IiJDdJyHQx8dnyZIlWpyT/NmtWzeZX6dOHTc3N/WBT4AhEQC9snDEOe73BZDpOCD5 7ezZsxIMLH7tLTEx8f79+/LXq1evWv/omczUlo+Li1PTdzLk+iakpqYmJCQY/klfDRNSQ1sl2M/W Zmp1sG7qHK738uXLJ0+etG58w2JTUlKuX79uWE5SUpKtPwFFT3JsAqdGQFE6UXmi4xwAAMAT5UuH Fjt+N+zalgM0BQDiHAAAQCGLc/L4yqnVhnIdot760PxiHQAQ5wAAAApWnNMeXzm15GIdAOIcAABA 4YtzXKwDUIjjHPf7ApBxwPDkhgcPHjyezMel9d/y1gAUqBMV4pzZf1BxiABPOMYBmhp40nqi/rG1 YcB3fSdtaTAwvG7fk3PX0k8B3j2JcwAYJUFTAwU6zm1weWFv17f3dg/cWMF3f/93r+88lJ6SSj8F ePckzgFglARNDRTonqi/HGdxsxz9FODdkzgHgFESNDVQcHui/nIc/RTg3bMQxzm+CgUA4wBNDTxR zL+7kn4K8O5ZmOIcAAAAAIA4BwAAAAAgzgEAAAAAcQ4AAAAAUNTiHPf7AmAcoKkB0E8BemWhjHN8 Gy8AxgGaGgD9FKBXEucAMEqCpgbopwDolcQ5AIySNDUA+ilAryTOMWYBYBygqQHQTwF6ZVGLc9zv C4BxgKYGQD8F6JWFMs4BAAAAAIhzAAAAAADiHAAAAAAQ5wAAeikpKWlpabSDSE9Pf/DgwRO4LRwD AICiEOe43xeAyTgQGhoaHBy8YsWKjRs3nj9/vkBVOyYmRup2/fr1bLy2Q4cO06dPz/aqw8PDo6Ki ctjU2S7EMMaEhYXNnDlzzJgxH3zwgeysW7du2fnaDRs2VKxYMUvrWrx4cV40Ts5laVtyeAzoffLJ JwkJCYwkT8KQCIBeWeDiHN/GC8BkHGjRokWjRo0GDBhQu3ZtJyenkJCQx1ary5cvX7x40WSBKVOm ODg4TJs2LRul5fBUftCgQQsXLszGFi11aJzDQqzFxcX5+vq6u7tPnjz5o48+CgwMfO6553bt2pVH ce7dd9/99NNPc71xCl2c0x9Rp06devHFF1NSUhhMivyQCIBeSZwDUMji3KRJk9R0p06d/P39H1ut evbsOX78eFt/lVPn6tWre3t7e3h42POROYvScvHKTJa2qLtDtVwvdtSoUV5eXjdv3tTPTE9Pz4sI JAv//ve/L7BH8uOMcxZH1DvvvGNyuIITRwD0SuIcgHyOc2PHjvX09JSJoUOHBgUFjR49Wk6dExMT JUj07dtXpuvXr69dFNq/f7+fn5/MlJfcuHFDzTRcUkpbvHjx+++/L0u2adPm0KFDMnP27NllypSR JSWwbd682bpiISEhVatWPXz4sIODw9atW7X5PXr0WLdunZpeu3Zt7969DUtTp/IWK32YcaVL6uPm 5latWrVhw4bFx8drldRvsjxdsmSJSpXe/2vGjBkyX7aoXbt2VapU6dy5s36LyjgU0+qgFWK+XuvG 0ZMlnZycgoONP4Viq9jY2FhpmUqVKjVt2nTChAlaBDLcQXqS5T755BPzulls14gRI2rWrFm2bFlZ l51rsW49k9XZ2hY9w6MxJ8fAtGnTLI6oM2fOuLi4/Pbbb4wnnDgCoFcS5wAUuDgnZ6vlypV77bXX 1Hmwq6vrvHnzoqOj09LS5Jx75MiREnKWLVvm4+OjXijnx3Lum56efuHChfv376uZhktKadWrVx83 btzPP/8sZ/l9+vSRmUlJSV26dBkzZoyc+icnJ1tXrFu3bqpizZs379evnza/YcOGWpZYuHBhkyZN DEszXKmQxXx9fU9m6NSpU9euXbVK6jdZf2Hn5iMff/xx8eLFIyMjZebGjRuPHTsm6xo8ePDAgQO1 Ovg5VNXXQSvEZL2G9dQcPHhQAu2PP/5ouPtsFfviiy/6+/tfvHjxypUrEoC1CGS4gzS3b9+WdX33 3XfmddNvlxRYp06diIgIOQZOnDhhz1oMW89kdba2Rc/waMzJMSCVtziiJNg7Oztv376d8YQTRwD0 ysca57jfF4DJOCBxrnbt2g0aNHB0dJTUJCf06rx21KhRaoFz587JKX5ISIic+0ZFRckZbUxMjMxv 3769OsnWirK1pJQWEBCgllm5cqWHh4eaNvmw5S+//CIvl4Qp08HBwU899ZR2ycUwzj00+rCl9UrP nz8vNdQuBoaGhspTWZfFJj80+pzekSNHSpcuvWbNGouqLl++3MvLS6vDq639rAsxX69h42jCwsJk 4cuXL1u3kq1iL126JBMSsdR87QOKtnaQRvKYLKB994ytumnbpQq0uI8u07XYaj3D1dnaFgvWR2PO jwHr41N6iq3LpCgyQyIAemWBi3MAYELiXP/+/ffu3Xvt2jXDMLNr1y45323dunXbR/bt2yfz5dTZ z8+vWLFiEydOvHfvnsmS+tLWrVvn7u6eaZyT5StUqDAuw/Dhw6XY+fPnZzXOWa9U1VDb0itXrsjT PXv2WOc3i6dyul+tWrWpU6dqczZt2tSyZcvnM9SqVcu8DnauV984/32HO35cFlYtacFWsbt379bP 1yKQrR2kOXXqlCwg5Zi0ofV2ff/999a1MlmLrdYzXJ2tbbFgfTTm/BiwPj49PT1XrVrFoAEAIM4B KEBxTrt3zjDMnD17Vs53bX3GTM6DXV1dly5darJkVuNcamqqLPPmm28ue8Tf379+/fpanAsKClLT kq+yFOdUXPnmm2/U/G3btslTdQ3QJM4lJibKSgcOHKh9+0h0dLQkhx07dsj0mjVrMo1zdq7XMM4l JydXrlxZfQjWgq1iY2JiHB0dDxw4YBGBzHel+O2335ycnFS2sSfOqQKXL1+uLyTTtdhqPcPV2dqW TI/GnB8DFnvz/v370jjffvstgwYAgDgHoNDEOeHr69uxY0f1SbY7d+6oD2Tu3bs3JSVFEk7Lli21 nykzXNJWKggMDJSFrasUHh5epUoV7Q4oob4QRV3k6devX0BAgISctWvXli9fXotzFqUZrjQtLa1Z s2aDBw+WiiUkJAwYMKB58+YqpNmKc7KNEiZbt26tXfN5mPHFGxJIzp8/L2FjyJAhWsCwVQc712sY 5x5mfCLR2dl5wYIFEnRVaWFhYadPnzYpVuYPHTo0Pj7+yJEjjRs31mpouIP0unTpsnLlSjvjnJDS fHx8jh49KtOqSpmuxVbr2VqdrW3RMzwac3gMWOzNkydPVqpUSX9YAgBAnANQCOKcnHZ369ZNEkWd OnXc3NzU1Zt69erJibWXl1ePHj3u3r1rsqSt0/Tjx49LIZ6enupCjaZXr14TJkywqJKcxw8bNkwm IiMja9asWaJEiT59+syZM0eLcxal2VppdHS0nL5LDnRxcWnVqpW6LGMS59Q3kZQuXbrCI6oasvaS JUvWqFFjxYoVlStXVt/nYVIHe9ZrK86JVatWyVpKlSr1zDPPyDLS5pKdTIqNiIgoV66c7AjJWkuW LNEikOEO0tu5c2fTpk3VD6zZE+euXr0qT6WJJOp4eHiobw3JdC2GrWdrdba2Rc/waMzhMWCxN0eO HPmXv/yFEQMA8LjjHPf7AsiVcSApKUn7kgzldgZ7ljQhecCen5XTS01NTUhIyElpcXFxtkqwnxSi 1nUng9bUJnXI4XovX7588uRJ61+cMyxWIpmtvWC+gyQyffjhh1mq2K+//mpdAfO1GLaeLSbbkunR mMNjQO3Nf/3rX4MHD2YkYUgEQK/MhzjHt/ECyHQcSI5NoJUeT1MXCuvXr2dX6m3evNnw5zRAPwVA ryTOAci3UTIl6e5PU5aFuPozUPCGBNBPAdAriXMACscoeSPy6LftRn3l3Fr+pB60Em9IAP0UAL2S OAeg4I6S+stxFg9aiTckgH4KgF5Z4OIc9/sCkHHA+nIccS6PmppGAOinAOiVuRbnAODa1gO2UhwP Hjx4PIEP3hcAEOcAFCbJsQmnF34R4f1ySFX/Te49ObkBAAAgzgEoZG5ERh36w6z1pduF1+27vlQ7 4hwAAABxDkBhYn2xjjYBAAAocHGO+30BmIwD6mIdce4xNDUA+imAJ61X8kMFAHJBpuNAcmwCrfR4 mhoA/RTAk9MriXMAGCVpagD0U4BeSZwDwCgJmhqgn9JPAXolcQ4AoyRoaoB+CoBembdxjvt9ATAO 0NQA6KcAvbJQxjkAAAAAAHEOAAAAAECcAwAAAADiHAAAAACgqMU57vcFwDhAUwOgnwL0ykIZ5/g2 XgCMAzQ1APopQK8kzgFglARNDdBPAdAriXMAGCVpagD0U4BeSZxjzALAOEBTA6CfAvTKohbnuN9X k5KSkpaWxsY+adLT0x88ePCENwLjAE0NgH4K0CsLZZyzJTQ0NDg4eMWKFRs3bjx//nxBboXw8PCo qKicl9OhQ4fp06fb+58EX3557Ngx7emlS5e++OILfdOJnTt33r9/X9+kBw8ezMUNj4mJkbVcv349 rzc2j9o8t3acimRhYWEzZ84cM2bMBx98IAftrVu37Hzthg0bKlasyEAJAACAohPnWrRo0ahRowED BtSuXdvJySkkJOSxbdXly5cvXrxo//KDBg1auHDhY45z0ixz587VnkZERDz99NMWTefp6eni4vLd d99p8ydMmJCLDTVlyhQHB4dp06Zlo1VzGOey1+YWdcitHRcXF+fr6+vu7j558uSPPvooMDDwueee 27VrF3EOAAAAT26cmzRpkpru1KmTv7//Y9uqnj17jh8//vG3Zi7GOa3pnn/+eQktWY1z0dHRmzZt Ml8mJSWlevXq3t7eHh4e9nxs0qJVcxjnCtSeHTVqlJeX182bN/Uz09PTiXMAAAAgzj0cO3asp6en TAwdOjQoKGj06NFy+puYmCgn0H379pXp+vXraxdD9u/f7+fnJzPlJTdu3FAzDZeU0hYvXvz+++/L km3atDl06JDMnD17dpkyZWRJCSqbN2+2qJVh4VLOkiVL9GVOnTq1Ro0azZo1k1y0bt26evXqPfvs s+Hh4doyixYtevvtt93c3OrWrRsaGmqdcAwrnI04JwGmV69eWY1zsuFSSfNlQkJCqlatevjwYQcH h61bt2rze/ToIZuspteuXdu7d2/DVlUba9H4DzOudMmqpWWqVas2bNiw+Ph4rdH0u15rc0mV3v9r xowZMl/2Qrt27apUqdK5c2dbe1a/40zWa32Q6MmSTk5OwcHGn6i2VWxsbKy0TKVKlZo2bSo7RYtz me53AAAAoADFOVt3FmqZ5MyZM+XKlXvttddUBnB1dZ03b57EpLS0NDlTHzlypJzcL1u2zMfHR71Q zrnlvD89Pf3ChQvanWOGS0pp1atXHzdu3M8//yzn0H369JGZSUlJXbp0GTNmjJxYJycnW9TKsHB9 DJNpOXGfNWuWLNC2bVtJa6+88sq///3v119/XbZIW8bd3f3DDz/86aefRowYUbly5dTUVItyDCuc pTgn9ZdYVbx48a+//jov4ly3bt3UDmrevHm/fv20+Q0bNtQy0sKFC5s0aWLYqoaNL2QxX1/fkxk6 derUtWtXrdH0u94i+ioff/yxbG9kZKTM3Lhx47Fjx2RdgwcPHjhwoK06aIWYrNewnpqDBw9KoP3x xx8NW8lWsS+++KK/v//FixevXLkiAViLc5nu96KK+/5pagD0U4BeWSjjnK3v/ZTsIYmlQYMGjo6O khZu376tzq1HjRqlFjh37pycRoeEhMiJclRUlLOzc0xMjMxv3769OlHWirK1pJQWEBCgllm5cqWH h4eaNvlInnXh1nFu7Nixavrdd99t2rSp+iBiWFhYqVKltGXkT2o6Li5O6nbgwAF9ObYqbH+cK1Gi hLSbFLJjxw59k5rHuV9++eVoBomaktbUtP4LV/RLSq0kact0cHDwU089pV2rNIxzD40+bGnd+OfP n5c6axdFQ0ND5amsy2LXPzT6rOaRI0dKly69Zs0ai6ouX77cy8vLVh1UIebrNTxINLJnZeHLly9b t5KtYi9duiQTssvUfO3Dlvbs96KKb+WmqQHQTwF6ZVGLc/3799+7d++1a9cMT+J37dol576tW7du +8i+fftkvmQtPz+/YsWKTZw48d69eyZL6ktbt26du7t7pnHOunDrOKdNT5kyxdfXV02Hh4fr45w+ ilStWnXRokX6+bYqrOft7T1z5kx9qJCApzVdYGCg5CuJMW+88Yb9cU6q0TlD48aNq1evrqb79u1r vaTUs0KFCuMyDB8+XGo7f/78rMY568ZXG67t8StXrsjTPXv2WDeaxVPJSNWqVZs6dao2Z9OmTS1b tnw+Q61atczrYOd69QfJf/+35vhxWdh6B5kUu3v3bv18Lc7Zs98ZJUFTA/RTAPTKwhHntBvADE/i z549K+e+27dvN3y5nDS7urouXbrUZMlsxDnrwnMY52JjY6VuckKvn2++aYr+k3ti9erVcvZv0XQS G5ycnLR79nLrw5apqanSVm+++eayR/z9/evXr6/FuaCgIDUt+SpLce7UqVOy4d98842av23bNnmq rgGaxLnExERZ6cCBA7VvH4mOjpbIra5MrlmzJtM4Z+d6DeNccnJy5cqV1YeBLdgqNiYmxtHRUV2S 1cc5e/Y7oyRoaoB+CoBeWRTinJCw1LFjR/XRxzt37qgPZO7duzclJUXO7Fu2bLl48WKTJW2dqQcG BsrChrUyLDwbca5z584JCQmSi+bOnSthwLo+hhXWmzNnjouLy5EjRx5m/P6bLDx58mTrpnvrrbck earP7OVWnJNtqVKliv4X7dQXoqhLSf369QsICJCQs3bt2vLly2txzqJVDRs/LS2tWbNmgwcPlu2V 9hkwYEDz5s1VSLMV52R3SJhs3bq1drH0YcY31kicO3/+vGz4kCFDtDvTbNXBzvUaxrmHGZ/ndHZ2 XrBggboHUkoLCws7ffq0SbEyX1o4Pj5e9mDjxo21Gma63xklQVMD9FMA9MoCFOcy/SoUkzgnJ+vd unWTM+k6deq4ubmpT8fVq1dPTo69vLx69Ohx9+5dkyVtnakfP35cCvH09NTfeKYYFp6NONe9e/dn nnlG1ihZS7t6o3+tYYX1ZO0SDyRE1a5dW6KL5EPtWxP1TSeLeXt7d+nSRVKEzJflHR/RruZlNc71 6tXLOhZKJhk2bJhMREZG1qxZs0SJEn369JHMqcU5i1a11fjR0dGSeSQHSlht1aqVukRmEufUN5GU Ll26wiOqGrL2kiVL1qhRY8WKFRKY1behmNTBnvXainNi1apVshbZxWq3yuEhcc6k2IiIiHLlysn+ 9fHxWbJkiRbnMt3vRRX3/dPUAOinAL2yUMY5c8mxCZkuk5SUdP36df2c2xnsWdLE1atXDX9OzVbh 9lMJQfKVrML818kyrXBcXFxUVJT+9sKCIDU1NSEhIUutar1dtkqwnxSi1nUngz11yOF6L1++fPLk Set9alhsSkqKrZ2bpQMVAAAAKFhxLiXp7k9TloW4+hfJK5v58gvaAAAAAJC3ce5G5NFv2436yrm1 BDn1KHqttnr1an4hGgAAAEARiXP6y3EWD1oZAAAAAApinDs4bIbF5TjiHPCk4b5/mhoA/RSgVxa+ OHdt6wFbKY4HDx5P2oN3i8eAdgbopwDolbkW51TrnF74RYT3yyFV/Te59+QMD2CUBE0N0E8B0CsL TZxTEzciow79Ydb60u3C6/ZdX6odcQ5glARNDdBPAdArC0ecU5JjEywu1nEAAYySoKkB+ikAemVB jHO27ixUF+sY0YAnAff909QA6KcAvbJQxjlzybEJHEAAAAAAUPjiHAAAAACAOAcAAAAAIM4BAAAA wBMe57jfFwDjAE0NgH4K0CsLZZzjuysBMA7Q1ADopwC9kjgHgFESNDVAPwVAryTOAWCUpKkB0E8B eiVxjjELAOMATQ2AfgrQK4tanON+XwCMAzQ1APopQK8slHEOAAAAAECcAwAAAAAQ5wAAAACAOAcA AAAAKGpxLkt3FqakpKSlpT3+7dSvN7/qgPzd7wVtvUXsOOS+f5oaAP0UoFcWyjhn63s/Q0NDg4OD V6xYsXHjxvPnz6uZHTp0mD59ek5WFx4eHhUVldVX6deb8zqgQDE5JPJrX9uz3iJ2HPKt3DQ1APop QK8sUnGuRYsWjRo1GjBgQO3atZ2cnEJCQnLlFHbQoEELFy4swnHu8uXLFy9eLGLHWZ5ulP6QsFgR cY5RkjckAPRTAMS5bMa5SZMmqelOnTr5+/sXkNPrAn4a3bNnz/Hjxxex4+yxbZTFiohzjJK8IQGg nwIgzuU0zo0dO9bT01M7hX3//fflaZs2bQ4dOiQz//CHP0yZMkV74TvvvPPBBx/IxP79+/38/CpW rCgL37hxQ/116NChS5YsUdNxcXEjRoyoWbNm2bJlmzZtqmYuXry4Xbt2VapU6dy5syrfVpyztV49 WZ0UOHXq1Bo1ajRr1iw6OnrdunX16tV79tlnw8PDtWrIYm5ubtWqVRs2bFh8fLzMlIotWLBAK+f1 119fvny5TNy8ebNv376yUfXr19+1a5fF6mbPnl2mTBn5q7e39+bNm20VbsFwk/UMG8pWyfZssiyz aNGit99+W15et27d0NBQNb9Hjx6ysJpeu3Zt7969DTfKsBGkzKCgoNGjR8v8xMRErfJ9+vT57LPP tAPppZdeUtN79+7t37+//pCwXpHh8Zal1st07YbbIuudNm2adftYxDnDZSzawXA3ZVorw76TpWZn lOQNCQD9FKBXPhFxztadhVqcO3PmTLly5V577TV1Clu9evVx48b9/PPPcmYpZ6XqvL9ChQr37t2T 6Vu3bskZ+fHjx2Vazr/lRDM9Pf3ChQv379+3DmZy/l2nTp2IiAj564kTJ9TMjRs3Hjt2LDk5efDg wQMHDjSJc7bWa3HOLafRs2bNkjq0bdtWTrtfeeWVf//73xLPZAPVMl26dPH19T2ZoVOnTl27dpWZ q1ev9vLyksrLdGxsbKlSpdSHAKXOI0eOlPPmZcuW+fj4WKwuKSlJShszZoycecsm2CrcguEm6xk2 lK2S7dlkWcbd3f3DDz/86aefJChWrlw5NTVV5jds2FAL2wsXLmzSpInhRhk2gpTp6uo6b948CZD6 7wiRo0jFFam8rMjZ2VlFGilQcpp+h1qvyPB4y1LrZbp2W9ti2D4Wh5bhMhbtYLibMq2VYd/JUrPn 1jiAXEdTA/RTAPTK3Ixztsipf+3atRs0aODo6NivX7/bt2+rc8eAgAC1wMqVKz08PGTit99+k7z3 j3/8Q6YlDMiZqFqgffv2/v7+Fvdcaefu586dc3BwMLmPbvny5RKoTOKcrfVarG7s2LFq+t13323a tKk65Q0LC5OEJhPnz5+XaqhrQQ8zvgBGnv7yyy8SLSQf7t69W2YuWLDgxRdf1OocEhIip+ZRUVFy Fh4TE2OxRv3HBW0Vbs8mawwbyqTkTDdZLSN/UtNxcXHy2gMHDtiKcxYbZasRpMxRo0ZZb5S0Ydmy ZR88eLBt2zYJM40bN96wYYNUSTLnqVOnLHau9YctrY+3LLWe+dpNtsWwfSwOLcNl9O1gazdl2ibW fSerzQ4AAIAnPc71799/7969165dsw5jYt26de7u7mr6T3/6k6+vr0w8++yzn3zyiZopJ6N+fn7F ihWbOHGiuoamL2HXrl1yevr9999brHfTpk0tW7Z8PkOtWrVM4pyt9RqmRzFlyhS18MOMb1NU2UZV Q9vGK1euyNM9e/bI9Kuvvjps2DCZqF+//saNG7WFW7du3faRffv2mcQ5k8Iz3WSNYUOZlJzpJj+0 uu+ratWqixYtsjPO2WoEW/eSpaSklC9fXl41ZsyYjz/++J133pG9JsfVc889Z10Zk3vn9Meb/a1n vnY7t0VrH1uHln4Z/XxbuynTNrHuO1ltdgAAADzpcU67dy7T0+sjR444OjpKoKpYsaKW3BQ5eXV1 dV26dKlFCWfPnpXTU3VDmiY6OlpOYXfs2CHTa9asyTTOmazXzjh36tQpqcY333yj5m/btk2enjlz Rp1AlylTJiIiolq1anL+rdV5+/btJu2mDyQmhWe6yRrDhjIpOatxLjY2Vl67YcMGFeeCgoLU/KlT pxrGOVuNYJIr+vfvP2HCBA8PDwk2UufatWu/9dZbhjs0q3Eu09YzX7s926JvH3uW0c832U3mbWLd d7LR7AAAACDO2RXnRKNGjSQtyCmpNmfv3r2SgtLT01u2bLl48WLrEjp27Ojj43P06FGZPn36dFpa 2v79++Xs/Pz58zExMUOGDJGQZh7nDNebpTgnK23WrNngwYNv376dkJAwYMCA5s2bq1vm5N+nn366 atWqkydP1gqUEqTa6lNwd+7cUZ9B1QsMDJQF1LRJ4Rpbm6xn3VAmJdsZ5zp37iwvTE1NnTt3buXK ldWG9OvXLyAgIDk5ee3ateXLl9finH6jbDWCSa5YvXq1lNaqVSuZlsJLly4tT7UbHfUvtFhRpnHO ntYzX7utbTFsH4tDy3AZfZ1NdpN5rQz7jj3NLrFfKsPICAAA8KTEuUy/CsXOOCcnnQ4ODidPntTm 1KtXT06vvby8evTocffuXesSrl69Kk/lVZUqVfLw8FDfftGnT5+SJUvWqFFjxYoVcoqsvtzCJM5Z rzdLce5hxhUeOcmWk2kXFxc5vdZfPXvvvfccHR3PnTunzZHY0K1bN2dn5zp16ri5uVl/clLOyGXD PT091SUjk8I1hpusZ9hQtkq2M8517979mWeekT3o6uqqXT6KjIysWbNmiRIlpEpz5szR4pzFRhk2 gkmcu3btmjSjFjO6du0qqzbcRxYrsufDlpm2nvnabW3LoEGDrNvH4tAyXMaiHWztJvNaGfYde5rd z8+vQYMGuTgOINfR1AD9FAC9MjfjXG597+f8+fPbtWtnMfN2BvMX/vrrrwkJCfo5cXFx6ts77mTI xnqzQVZqUQ0TSUlJ169fN1lAApj+awYzLdyeTbZuqKxW2yJBpaenSz0trhampqbaKtBiozJthGyz WJE9+87+A8aeHZqYmHj//n3D9snSMjnZTbb6Th41O9/K/djQ1AD9FAC9ssDFuZSUFA8PD+2ntB6b /FpvYccNV+DchaYGQD8F6JXEuf/zyy+/TJs2TX0I8HHKr/UWdqtXr7b+DXQwSoKmBkA/BeiVT2Kc A8AoCZoaoJ8CoFc+7jjH/b4AGAdoagD0U4BeWSjjHAAAAACgUMa5Lx1aFJAHuxMAAAAAca7wIc4B AAAAIM4R5wAAAADgCYhzBeTOQuIckI+475+mBkA/BeiVhTLOFZAcRZwD6IA0NQD6KYAnqlcS5wDQ AWlqAPRTgF5JnGMnAYySoKkB+in9FKBXEufYSQCjJGhqgH4KgF6Zt3HO/M7C5NgEdhJQ5HHfP00N gH4K0CsLZZwzlJJ096cpy0Jc/R9byiLOAQAAAHii5H6cuxF59Nt2o75ybi35Sj2IcwAAAABQcOOc /nKcxYM4BwAAAAAFMc5ZX44jzgEAAABAQY9z17YesJXiHv+D3QnkF+77p6kB0E8BemXhi3MPMy6L nV74RYT3yyFV/Te59yRlAU8gejpNDYB+CtArC2ucUxM3IqMO/WHW+tLtwuv2XV+qHXEOYJQETQ3Q TwHQKwtHnFOSYxMsLtZxAAGMkqCpAfopAHplIYhzGnWxjhENYJQETQ3QTwHQKwtonDO/szA5NoED CCjyuO+fpgZAPwXolYUyzgEAAAAAiHMAAAAAAOIcAAAAABDnAAAAAABFLc5xvy8AxgGaGgD9FKBX Fso4x7fxAmAcoKkB0E8BeiVxDgCjJGhqgH4KgF5JnAPAKElTA6CfAvRK4hxjFgDGAZoaAP0UoFcW tTjH/b4AGAdoagD0U4BeWSjjHAAAAACAOAcAAAAAIM4BAAAAAHEuq7Zv3x4ZGWkxMyQkJDo6Ojw8 PCoqyuS1mS6gfPnll8eOHdOeXrp06YsvvlDToaGhwRl27tx5//59bRmZf/DgQfY6AAAAAOLcfxje WRgUFOTu7p6WlqbNiYuLK1GixMWLFwcNGrRw4UKTAvULXL58WV5iuFjt2rXnzp2rPY2IiHj66afV dIsWLRo1ajRgwABPT08XF5fvvvtOmz9hwgT2OpDruO+fpgZAPwXolYUyzhl+72dsbOxTTz21fft2 bc5HH33Uvn37rBbes2fP8ePHZyPOTZo0SU0///zzkg+Jc0Ce4lu5aWoA9FOAXll04pzo27evlqNE q1atVqxYIRNDhw5dsmSJmrl//34/P7+KFSt6enreuHFDzdQWmD17dpkyZeSv3t7emzdvzl6ck0DY q1cv4hzAKElTA6CfAvRK4py9rRMWFlayZMmEhASZjo6Olulbt27JdIcOHaZPn66WadOmTVBQUHp6 +oULF7Sb3LQFkpKSunTpMmbMmJs3byYnJ2c1zsmr1q1bV7x48a+//po4BzBK0tQA6KcAvZI4Z2/r pKSkuLm5LV++XKbfe++9l19+2SKtifbt2/v7+1vcHadfINsftixRooSjo6ODg8OOHTu0ZYhzAKMk TQ2AfgrQK4lz/2VyZ6FkJ0lQ6enpXl5e2qcl9WlNgpyfn1+xYsUmTpx47969LMU5b2/vmTNnak/D wsIk4GmxLTAw8MaNG7LeN954gzgH5DXu+6epAdBPAXploYxzJn7++WcHB4e///3vVapUefDggXVa U/bs2ePq6rp06dIsxblOnTp17dpVe7p69eq2bdtqsU3dO7d7924nJ6fw8HDiHAAAAADiXNY0b968 VKlS+ktk+rS2d+/elJSU9PT0li1bLl682HqBwMDAjh07GpY8Z84cFxeXI0eOyHRMTIwsNnnyZIs4 J9566y3JirIAcQ4AAAAAcS4Lli1b5uDgoP/xbn1aq1evXsWKFb28vHr06HH37l3rBY4fPy7LeHp6 6m+BU2T5AQMGSOG1a9cuVqxY586d4+PjreOcLObt7d2lSxcJjTJflnd8RLuaBwAAAADEuSy7ncF8 matXr+p/kVwvLi4uKirq2rVr7EsAAAAAxLms4X5fAIwDuSs5NoGmBhgSAdArH0ec49t4ATAO5Hp7 7vjdsGtbDtDUAEMiAHolcQ4Ao2Qha095fOXUakO5DlFvfai/WEdTAwyJAOiVxDkAjJIFPc5pj6+c WmoX62hqgCERAL2SOAeAUbLQxDn9xTqZMLmzDgBDIgDiXC6cdvDgwYMHj7x7XFr/Le/NQIHFV6EA 9MrCFOcAALn+n4j6x9aGAd/1nbSlwcDwun1Pzl3L1TkAAECcA4ACHec2uLywt+vbe7sHbqzgu7// u9d3HkpPSaVxAAAAcQ4ACnSc43IcAAAgzgFAoYxzXI4DAACPI85xvy8AxoHcZXI5jqYGGBIB0Ctz M87xbbwAGAdoagD0U4BeSZwDwCgJmhqgnwKgVxLngP/P3t3HVVXm+//nxvIGw0QRUUABJS3xJkdR C1MQSMU8qIMyyFg+zK/aOIXj0dImp3x4M9MUhI56wEdyhuk0PZIBFaakQsXw4U10PGpZqIi3iBCk OAoC29/ny/q2fvvsvdZmg0B74+v52H8sFmtf67quta6L9XbttQWzJF0NgHEKMCqJc8xZAJgH6GoA jFOAUdne4hzP+wJgHqCrATBOAUalXcY5AAAAAABxDgAAAABAnAMAAAAA4hwAAAAAoL3FOZ73BcA8 QFcDYJwCjEq7jHN8Gy8A5gG6GgDjFGBUEucAMEuCrgYYpwAYlcQ5AMySdDUAxinAqCTOMWcBYB6w /a42GAz/+Mc/XnvtteXLl//Xf/3X3bt3W7Emf//78ePH1R8vXrz44YcfKsuZmZnJDT777LOamhp1 G1l/+PBhDiKYEgEwKm0ozvG8LwDmAVvo6oqKikmTJgUEBLz11lsbNmwYMWLEL37xi0uXLrVSTfz8 /GQv6o/Z2dn9+vVTlkePHj106NDo6GgfH5+uXbt++eWX6nrJmRxEMCUCYFTaUJwDANiCl156qX// /j/++KPy4507dyTO/du//dvPEudWrlypLD/55JNz5swhzgEAQJwDAGirrKzs0KHD0qVLjVdu3LjR wcHhu+++k+W4uLj33nvvlVde8fDwGDBgQGZmprLN9evXZ8yY0b1790GDBuXm5iorZeOkpKS1a9f6 +PiMGzfuyJEjzY5z06ZNe+6554hzAAAQ5wAA2g4fPizJbc+ePcYr//u//1tWpqeny/KECRO8vLze fffdEydOzJ8/v0ePHnV1dbJ+0qRJCxYsuHHjxpYtWwIDA5U3ysaenp4SDk+dOiVhLyoqqhlxToJi Wlraww8//I9//IM4BwAAcQ4AoE2CnHojTlVbW+vo6Lht2zYlob366qvK+vLyctn40KFD586dk4WM jIxvv/22oKDA2dm5pKRE2TgmJkbZePv27d7e3k2Ncx07dpRdS+E5OTnqNsQ5AABsLs7xvC8A5oGf vau/+eYbyU7Jyf/rt5cuXVIDlSS0NWvWqL/q1avXe++9l5ubKxuMHTv2qZ8cPHjQZOO0tDQvLy/z PQYEBLz55pvGeVICnhrb4uPjS0tLfX19f/Ob3xDnwDgFwKi03TjHt/ECYB742bv67t27ffr0+eUv f2m8cvPmzV27di0vLzdJaGVlZZLidu7cefbsWVnYu3evSWnWxLmQkJDJkyerP77//vuSBtXYpjw7 t3//ficnp6ysLOIcGKcAGJXEOQDMknS1blf/9a9/7dKly6effqr8ePjwYXd39/Xr16sJbdKkSZWV lXV1dRs2bOjRo8fNmzdlfWho6MSJE4uLi2X51q1bykpr4pyULFnx2LFjslxSUiKFvPbaayZxTrz8 8stSDeUznMQ5ME4BMCqJcwCYJelqbRK93NzcfH19BwwY4Orq+t577xkMBjXOTZ069bHHHpNsJvnq 888/V9ZL0JoyZYqzs7O/v7+Hh8eBAwesjHO3b9+Ojo52cHDw8/Pr0KGDZMWKigrzOCebBQQEhIeH S01kvWzv+BP1bh7AlAiAUUmcA8AsSVffk9R09uzZM2fO1NfXG69XEpr89sqVK2rGU1VVVV27dq0Z 9SkvLy8oKLh69SqHBmBKBBiVdhnneN4XAPOA7Xe1yVehALgf1WWVTIkAFyrtJM4BAGzf+++/r/4v 4QDu098dRuf8Yt7Vfx6iKwAQ5wAAAOwszsnrI6cxO10nFLz8ruWbdQBAnAMAALCtOKe+PnIK4mYd AOIcAACA/cU5btYBsOM4x/O+AJgH2rKrNa8jefHiZVOvix9/wXwFcKFiH3GOb+MFwDxAVwMP2kg0 fn0yJObLGSv/OXh21oAZ325IZZwC/PUkzgFglgRdDdh0nNvZ9Zm8ya/kTY1PfzQ0f9ar1z47Yqit Y5wC/PUkzgFglgRdDdj0SDS+HWfysBzjFOCvJ3EOALMk6GrAdkei8e04xinAX087jnN8BQIA5gG6 GnigWP7uSsYpwF9Pe4pzAAAAAADiHAAAAACAOAcAAAAAxDkAAAAAQHuLczzvC4B5gK4GwDgFGJV2 Gef4Nl4AzAN0NQDGKcCoJM4BYJYEXQ0wTgEwKolzAJgl6WoAjFOAUUmcY84CwDxAVwNgnAKMyvYW 53jeFwDzAF0NgHEKMCrtMs4BAAAAAIhzAAAAAADiHAAAAAAQ5wAA+FnU1tbW19fbXbVLS0srKio4 fAAAW49zPO8LgHnAFro6MzMzOTk5JSUlPT29qKjIpqpdUlIidbt27Voz3jthwoQ1a9Zotjc3N9d4 TVZW1nfffScLd+7cSTZz9epVkxJk+4KCghZvbE1NTXh4uL+/v5eX1+nTpzlpGacAGJU2Hef4Nl4A zAO20NWjR48eOnRodHS0n5+fk5NTRkZGm9Xq0qVLxcXFFjZYtWqVg4PDG2+80YzS9OKctLdz585n z55V1zzzzDOSZmXh5s2b8408+eSTsnfz5DZnzpyEhIT7bJq5nJycfv36ca4yTgEwKolzAJgl0YQ4 t3LlSmU5JCQkIiKizWo1bdq0ZcuW6f22trbW09MzICDA29vbmo9NmpRmIc45OzvLbw0Gg0mcM1ZR UdG3b9+5c+e2RtM0SW0nTpzIuco4BcCoJM4BYJZEc+LckiVLfHx8ZCEuLi4xMXHRokXdu3e/cePG 9evXZ8yYIcuDBg1SP6mYn58fFhYmK+UtpaWlykrNLaW0pKSktWvXypbjxo07cuSIrFy3bp2Li4ts KYFt9+7d5hXLyMjo1avX0aNHHRwcPvnkE3V9ZGRkWlqaspyamjp9+nTN0pQ4Z7JTpb2/+93vOnTo sG3bNgtxLiYmRmJkZWWlecWkOZs2bWpS0/S6Re3kd955x83NrUuXLvIWpTJSbHBwcM+ePSdNmqRW vry8fP78+ZIzH3nkkREjRljoczAlAmBUEucAMEs+QHHuzJkzrq6uL774opKF3N3dN27cWFhYWF9f L4liwYIFkuu2bNkSGBiovFHSi6QRg8Fw/vz5mpoaZaXmllKap6fn0qVLT506JcEjKipKVlZVVYWH hy9evFjSSHV1tXnFpkyZolRs1KhRM2fOVNcPGTJETVMJCQnDhw/XLE1zp0p7P/jgg1WrVkljL126 pBnnPvroI0dHx88++0yzx4zv+1nZNL1uUTtZ3hIfH//000/LW27fvi2/TU9PP378uLw9NjZ29uzZ avf6+/tnZ2dLh3/zzTcW+hxMiQAYla0b53jeFwDzgC10tcQbPz+/wYMHS4CR1HTz5k0laSxcuFDZ 4Ny5cw4ODhkZGd9++21BQYGzs3NJSYmsHz9+fEREhPETYnpbSmkxMTHKNtu3b/f29laWLXwi8cKF C/J2SZiynJyc/NBDD6k3ADXj3D2tD1tq7lSJcxKTHn/88alTp5rHuatXr7q5uUlC0+sxkzjXaNMs dIvayeL1118PCQkx393WrVt9fX3Vckwe29MrHEyJABiVrRvnAAC2QOLNrFmz8vLyjL/C0Tix5Obm SmAYO3bsUz85ePCgrJcgFxYW1qFDhxUrVty5c8fClsalpaWleXl5NRrnZPtHH310aYMXXnhBin37 7bebGuc0d6rEOVk4fPiwk5PT3/72N5M4N3ny5Mcee0y5RWZNnGu0adZ0i3mc27VrV1BQ0JMN+vfv r5bz9ddfG1dGr3AAAIhzAPBAxDn12TnNxHL27FkJDHv37tV8+4EDB9zd3Tdv3mxhy6bGubq6Otnm t7/97ZafREREDBo0SI1ziYmJyvLq1aubHeeEbN+zZ88nnnhCjXPbtm2TgHr06FELPdbUOGdNt5jE ucLCQqlGTk6OLO/YsUOJc0o5W7duNS7E8tEBAIA4BwAPdJwToaGhEydOVD5XeevWLeUDmXl5ebW1 tQaDISgoKCkpycKWepknPj5e87scs7KyJGWpz+MJ5QtRlPtOM2fOjImJqa6uTk1N7datmxrnTEqz Js7dvn17wIABUrIS5yQaubi4SDk/GpFs2Yw4Z1KZRrvFJM7l5+dLnCsqKiopKZk7d2737t2V9VJI YGDgV199Jcvff/+98oWfmoUDAECcAwDi3P8loWLKlCnOzs7+/v4eHh4HDhyQlQMHDpSY4evrGxkZ qX40UXNLvcxz8uRJKcTHx0e5DaV67rnnli9fblKlYcOGzZs3Txb27dvXt2/fjh07RkVFrV+/Xo1z JqVZE+fuNdxddHR0VOJccnKyg5n9+/c3I86ZVKbRbrln9mFLaV2nTp369OkjdevRo4fybShXrlyR d0mt3NzcvL29le9Z0SwcAIDWjXM87wuAecB2urq6rLLRQqqqqq5du2a85mYDa7a0QCKKNf+tnLG6 ujrN/0KgeaW1HpPKNKlb7jX8twTK2281UNf/8MMP5s1vauFgSgTwII9K/qMCAC2AeeBn7+raqtsn Vm3JcI/gWABMiQAenFFJnAPALGnfXV2676svghd+5DxWfqW86CWAKREAcY7eAcA8YLtdbXw7zuRF LwFMiQCIc/QOAOYBW+xq89txxDmAKREAca6ZeN4XAPNAmzkU+4ZeiuPFi5ftvJisAC5U7CbOAQDa UnVZ5fcJH2YH/DKjV8Qur2lcRwIA8MAizgGAvSrdV3Dk+bc+7hKcNWDGx52DiXMAABDnAAD2xPxm HX0CAABxDgBgT5SbdcQ5AACIc03AVyAAYB6wna6uLquklwCmRAAPyKjkPyoA0AKYB+hqAIxTgFFJ nAPALAm6GmCcAmBUEucAMEvS1QAYpwCjkjjHnAWAeYCuBsA4BRiV7S3O8bwvAOYBuhoA4xRgVNpl nAMAAAAAEOcAAAAAAMQ5AAAAACDOAQAAAADaW5zjeV8AzAN0NQDGKcCotMs4x7fxAmAeoKsBME4B RiVxDgCzJOhqgHEKgFFJnAPALElXA2CcAoxK4hxzlqq2tra+vt7uql1aWlpRUcFgBrMkXQ2AcQow Kolz/z+9JwszMzOTk5NTUlLS09OLiopsqtklJSVSt2vXrjXjvRMmTFizZo1me3Nzc43XZGVlfffd d7Jw586dZDNXr141KUG2LygoaPHG1tTUhIeH+/v7e3l5nT59mvGM1sBz/3Q1AMYpwKi0yzinZ/To 0UOHDo2Ojvbz83NycsrIyGizVl26dKm4uNjCBqtWrXJwcHjjjTeaUZpenJP2du7c+ezZs+qaZ555 RtKsLNy8eXO+kSeffFL2bp7c5syZk5CQcJ9NM5eTk9OvXz+GMQAAAECca0KcW7lypbIcEhISERHR Zq2aNm3asmXL9H5bW1vr6ekZEBDg7e1tzccmTUqzEOecnZ3ltwaDwSTOGauoqOjbt+/cuXNbo2ma pLYTJ07kXAcAAACIc82Jc0uWLPHx8ZGFuLi4xMTERYsWde/e/caNG9evX58xY4YsDxo0SP2kYn5+ flhYmKyUt5SWliorNbeU0pKSktauXStbjhs37siRI7Jy3bp1Li4usqUEtt27d5tXLCMjo1evXkeP HnVwcPjkk0/U9ZGRkWlpacpyamrq9OnTNUtT4pzJTpX2/u53v+vQocO2bdssxLmYmBiJkZWVleYV k+Zs2rSpSU3T6xa1k9955x03N7cuXbrIW5TKSLHBwcE9e/acNGmSWvny8vL58+dLznzkkUdGjBhh oc8BAAAAPEBx7syZM66uri+++KKShdzd3Tdu3FhYWFhfXy+JYsGCBZLrtmzZEhgYqLxR0oukEYPB cP78+ZqaGmWl5pZSmqen59KlS0+dOiXBIyoqSlZWVVWFh4cvXrxY0kh1dbV5xaZMmaJUbNSoUTNn zlTXDxkyRE1TCQkJw4cP1yxNc6dKez/44INVq1ZJYy9duqQZ5z766CNHR8fPPvtMs8eM7/tZ2TS9 blE7Wd4SHx//9NNPy1tu374tv01PTz9+/Li8PTY2dvbs2Wr3+vv7Z2dnS4d/8803FvocAAAAQPuJ c3pPFkq88fPzGzx4sAQYSU03b95UksbChQuVDc6dO+fg4JCRkfHtt98WFBQ4OzuXlJTI+vHjx0dE RBg/Iaa3pZQWExOjbLN9+3Zvb29l2cInEi9cuCBvl4Qpy8nJyQ899JB6A1Azzt3T+rCl5k6VOCcx 6fHHH586dap5nLt69aqbm5skNL2eNIlzjTbNQreonSxef/31kJAQ891t3brV19dXLcfksT29woEm zQOgqwHGKQBGpU3HOb3v/ZR4M2vWrLy8POOvcDROLLm5uRIYxo4d+9RPDh48KOslyIWFhXXo0GHF ihV37tyxsKVxaWlpaV5eXo3GOdn+0UcfXdrghRdekGLffvvtpsY5zZ0qcU4WDh8+7OTk9Le//c0k zk2ePPmxxx5TbpFZE+cabZo13WIe53bt2hUUFPRkg/79+6vlfP3118aV0SscaNI8ALoaYJwCYFTa a5xTn53TTCxnz56VwLB3717Ntx84cMDd3X3z5s0WtmxqnKurq5Ntfvvb3275SURExKBBg9Q4l5iY qCyvXr262XFOyPY9e/Z84okn1Di3bds2CahHjx610JNNjXPWdItJnCssLJRq5OTkyPKOHTuUOKeU s3XrVuNCLB8dgGsXuhoA4xRgVD7QcU6EhoZOnDhR+VzlrVu3lA9k5uXl1dbWGgyGoKCgpKQkC1vq ZZ74+HjN73LMysqSlKU+jyeUL0RR7jvNnDkzJiamuro6NTW1W7duapwzKc2aOHf79u0BAwZIyUqc k2jk4uIi5fxoRLJlM+KcSWUa7RaTOJefny9xrqioqKSkZO7cud27d1fWSyGBgYFfffWVLH///ffK F35qFg5w7UJXA2CcAoxK4tz/JaFiypQpzs7O/v7+Hh4eBw4ckJUDBw6UmOHr6xsZGal+NFFzS73M c/LkSSnEx8dHuQ2leu6555YvX25SpWHDhs2bN08W9u3b17dv344dO0ZFRa1fv16NcyalWRPn7jXc XXR0dFTiXHJysoOZ/fv3NyPOmVSm0W65Z/ZhS2ldp06d+vTpI3Xr0aOH8m0oV65ckXdJrdzc3Ly9 vZXvWdEsHODaha4GwDgFGJXtJ87d/5OFVVVV165dM15zs4E1W1ogEcWa/1bOWF1dneZ/IdC80lqP SWWa1C33Gv5bAuXttxqo63/44Qfz5je1cDyYeO6frgbAOAUYlXYZ5yyrLqvkBAIAAAAAu4lztVW3 T6zakuEewecNAAAAAMA+4lzpvq++CF74kfNYCXLKi14GAAAAANuNc8a340xe9DIAAAAA2GKcOzzv Dya344hzwIOG5/7pagCMU4BRaX9x7uonh/RSHC9evHjxaqUXf5gBW8YgBRiVdhPnlN75PuHD7IBf ZvSK2OU1jcsOgFkSdDXAOAXAqLSbOKcslO4rOPL8Wx93Cc4aMOPjzsHEOYBZEnQ1wDgFwKi0jzin qC6rNLlZxwkEMEuCrgYYpwAYlbYY5/SeLFRu1jGjAQ8CnvunqwEwTgFGpV3GOcuqyyo5gQAAAADA /uIcAAAAAIA4BwAAAAAgzgEAAADAAx7neN4XAPMAXQ2AcQowKu0yzvHdlQCYB+hqAIxTgFFJnAPA LAm6GmCcAmBUEucAMEvS1QAYpwCjkjjHnAWAeYCuBsA4BRiV7S3O8bwvAOYBuhoA4xRgVNplnAMA AAAAEOcAAAAAAMQ5AAAAACDOwZjBYLh7924b7Ki2tra+vt4Wmmw7NWn3x7019sLhAwAAIM5p03uy MDMzMzk5OSUlJT09vaioqD312s6dO7t3737/5WRlZRUUFFjYYMKECWvWrGlqsSdOnDh69GjLNrl5 NbG+pW1WiC0c97bfy30ePmsOB8/9txm6GmCcAmBUtmSc0/vez9GjRw8dOjQ6OtrPz8/JySkjI6PN WnXp0qXi4mIbvOA2qdicOXMSEhJa/Cpc+lwidMv24X3mgUZb2iLdRZxrpcNnzeGw8vt/W3tsPgj4 AnSAcQqAUdlGcW7lypXKckhISERERJu1atq0acuWLbPBC+6mVqwZV+F3797t1atXVVVVy/Zha9ze +dmPYzuOc61x+CwfDitnSVs7pvxBAsA4BRiVxLnG49ySJUt8fHxkIS4uLjExcdGiRXLBeuPGjevX r8+YMUOWBw0alJubq2ycn58fFhYmK+UtpaWlykrNLaW0pKSktWvXypbjxo07cuSIrFy3bp2Li4ts GRAQsHv3bpNalZeXz58/v2/fvo888siIESPUchqtVVlZ2fTp093c3ORdy5cvVy+476distmmTZuU t8j2wcHBPXv2nDRpkrK9yVW4ZreY++KLL8LDwzV/pbmLyMjItLQ0ZTk1NVXaqFlVpSYmLVL6U1rh 4eHRu3fvefPmVVRUaHap2tLa2tqA/+0Pf/iDZt0sd5eF/Zr3vDXngF6BTTrujfa2XvX09tLah6+l zl7pvYkO7iZdas0xbbQbwWUiwDgFwKj8mePcmTNnXF1dX3zxReWy0t3dfePGjYWFhfX19XKdt2DB Arnc37JlS2BgoPJGuYKUJGAwGM6fP19TU6Os1NxSSvP09Fy6dOmpU6fkojAqKkpWVlVVSZ5ZvHix XClWV1eb1ErK8ff3z87OlpK/+eYbtZxGa/Xss89GREQUFxdfvnxZrqHVC+77qZhxWktPTz9+/Lis j42NnT17tnmc0+wWc6+88op6kW1CcxdDhgxRt09ISBg+fLheVc1bJGSz0NDQbxuEhIRMnjxZs0uN G3L9J9u2bXv44Yf37dunWTfL3WVhv5r1bPQc0CuwSce90d7Wq57eXlr78LXU2SvleDh0NOlSa45p o90ILhMBxikARmXrxjm9Jwslzvn5+Q0ePNjR0XHmzJk3b95ULgEXLlyobHDu3DkHB4eMjAy5gC4o KHB2di4pKZH148ePVy5t1aL0tpTSYmJilG22b9/u7e2tLOt9oEspx/z5q0ZrdfHiRVkpV6vKNurH 4e6zYpofgdu6dauvr6/5BubdomnAgAGNbmO8C808oFlV8xYVFRVJ89VboJmZmfLjhQsXTLpUs6XH jh3r0qXLjh07LNRNr7ss71ez5y2fA3oFNvW4N9rbmtXT20trH76WOnuVclZERFtTYeNCmtSNaHTK BcA4BfAAjspW/I8KJM7NmjUrLy/v6tWrmpf1ubm5cjE3duzYp35y8OBBWS9pJCwsrEOHDitWrLhz 546FLY1LS0tL8/LyshznlHK+/vpr8zhnuVb79++XlWpD1Avu+6yY8Wa7du0KCgp6skH//v3NNzDv FnNyWWzhFofmLqzPA+YtUpqvdsvly5flxwMHDpjnN5MfJSn17t179erVluumVwcr92vc85bPAb0C m3rcG+1tzerp7aVtDt/9n716w6rRY2pNNwIAAOBni3Pqs3Oal5Vnz56Vi7m9e/dqvl0upt3d3Tdv 3mxhy6bGOaWcrVu3NrVWJSUljo6Ohw4dMrngvs+KqZsVFhZKTsvJyZHlHTt2aF79m3eLuT/96U+r Vq3S/JXeLiQPJCYmKsuSr5qUB06fPi3N//zzz5X1n376qfx45swZy3Huxo0bstPZs2cbDAbLddOr g5X71YxzmueAXoFNPe6N9rZm9fT20tqHr6XOXs0uteaYNtqNAAAAsN04J0JDQydOnKh8OPDWrVvK BzLz8vJqa2vlWj8oKCgpKcnClnrXnfHx8bKxZq1kfWBg4FdffSXL33//vfJ/K1tTq5EjR8bFxVVU VBw7dmzYsGHqBff9VEzdLD8/X659i4qK5Mp+7ty5auHG5Wh2i4ng4GA1FZjQ28XMmTNjYmKqq6tT U1O7deum5gG9qhq3SHpPuiU2NlZaXVlZGR0dPWrUKCWk6cU5aUJERMTYsWONbzDq1U2vDlbuVzPO aZ4DFgps0nFvtEV61dPbS6sevpY6ezW71MpjarkbAQAAYNNxTi71pkyZ4uzs7O/v7+HhoXxebuDA gXLx5+vrGxkZefv2bQtb6l13njx5Ugrx8fFRbg4Yu3LlirzLwcHBzc3N29vb/Esd9PaVnZ3t6uoq K+WyddOmTerl6f1UzHizqKioTp069enTJyUlpUePHspXRxhvoNktxsrLyz09PZWAqklzF/v27evb t2/Hjh3lt+vXr1fzgIWqGreosLBQko8Eia5du44ZM0a5RWYhzh0+fFg6v0uXLo/+ZN68eXp1s1AH a/arF+c0zwG9Apt03Bvtbb3q6e2ltQ9fS529ml1qzTFttBsBAADQunHu/p8srKqqunbtmvGamw2s 2dICucTUyzY//PBDZWVlU2tVW1urt/cWqZjkMWX9rQbmG+h1i3rl/fzzz1veteYu6urq9HrDQh+a FNtof1pTiGbzLdThfvareQ5oFtjs497oAbVyL619+Frk7JV5wLxLrTymTaoA+IoFgHEKgFHZknGO b+O1ES+//PKePXvoB/wsmAdaVnVZJV0NMCUCYFQS5wAwS9plf+b8Yt7Vfx6iqwGmRACMSuIcAGZJ O+tPeX3kNGan64SCl981vllHVwNMiQAYlcQ5AMySth7n1NdHTkHqzTq6GmBKBMCobMk4x/O+AJgH WjXOGd+sywmab+HJOgBMiQAeqFHZMnfnePHixYtXW74ufvwFf5sBAIADXQAAtsYkvH0yJObLGSv/ OXh21oAZ325I5e4cAAAgzgGATce5nV2fyZv8St7U+PRHQ/NnvXrtsyOG2jo6BwAAEOcAwKbjHLfj AABAW8Q5nvcFwDzQ4nFO73YcXQ0wJQJgVLZknOPbeAEwD7QsC7fj6GqAKREAo5I4B4BZkq4GwDgF GJXEOeYsgFmSeYCuBsA4BRiVxDkAzJKgqwHGKQBGZRvFOZ73BcA8QFcDYJwCjEq7jHMAAAAAAOIc AAAAAIA4BwAAAADEOQAAAABAe4tzPO8LgHmArgbAOAUYlXYZ5/g2XgDMA3Q1AMYpwKgkzgFglgRd DTBOATAqiXMAmCXpagCMU4BRSZxjzgLAPEBXA2CcAozK9hbneN4XAPMAXd0iamtr6+vrf/ZqGAyG u3fv6v22tLS0oqLCFmrSbG3ZBMYpAEalrcc5AIAtyMzMTE5OTklJSU9PLyoqsscmTJgwYc2aNc17 b1ZWVkFBQYtUY+fOnd27dzdfX1NTEx4e7u/v7+Xldfr06TboEL2aNFvbNOHvf//78ePH1R8vXrz4 4YcfMkIBgDgHANA1evTooUOHRkdH+/n5OTk5ZWRktNmuL126VFxc/PPGuTlz5iQkJGjWp6nV0wtR OTk5/fr1a8tj2mica2rT2qYJcgZu2LBB/TE7O7uN+w0AiHMAAPuLcytXrlSWQ0JCIiIi2mzX06ZN W7Zs2c8b5yzUp6nV0wtRUreJEyfaVJxratPapgnEOQAgzgEAmh/nlixZ4uPjIwtxcXGJiYmLFi2S VHDjxo3r16/PmDFDlgcNGpSbm6tsnJ+fHxYWJivlLaWlpcpKzS2ltKSkpLVr18qW48aNO3LkiKxc t26di4uLbBkQELB7926TWmkWHhkZmZaWpiynpqZOnz5djXNvvPHGK6+84uHhMWDAgMzMTOP9rl69 uk+fPiNHjiwsLJS3Dxw48PHHH8/KylK32bRpk3l9zKun2bSysjKphpub24gRI5YvX24eov7yl7/I b7t06SLlpKSkyJry8nLZqVS1d+/e8+bNU59GM+lzaypvTK8mUkhwcHDPnj0nTZqk1/Pm21hugklV LbSoSU2wEOeadLIZ140BDgCtFed43hcA84AtdLUa586cOePq6vriiy8qAcnd3X3jxo1yCV5fXy9X +QsWLJCL4y1btgQGBipvlGAm180Gg+H8+fM1NTXKSs0tpTRPT8+lS5eeOnVKrr+joqJkZVVVVXh4 +OLFi+WivLq62qRWmoUPGTJEiV4iISFh+PDhavleXl7vvvvuiRMn5s+f36NHj7q6OmW9BIy33npL Cnnqqack6f3qV7/67rvvXnrpJWm1+l7lzp5Jfcyrp9m0Z599NiIiori4+PLly5I2zePcv/71r/j4 +KefflrKuX37tqyRYkNDQ79tEBISMnnyZLUmxn1uTeWN6dUkPT39+PHj0oTY2NjZs2dr9rz5Npab YFJVCy1qUhMsxLkmnWzGdWNKBMCobK04x7fxAmAesIWulgtruYwePHiwo6PjzJkzb968qVwTL1y4 UNng3LlzDg4OGRkZcrFeUFDg7OxcUlIi68ePH6/kB7UovS2ltJiYGGWb7du3e3t7K8sWPvJnXrjl OPfqq68qy+Xl5VKHQ4cOKeuXLFmirJcNRowYoVzf79mzp3PnziZx7p7FD1tqNu3ixYuyUlKHso3e Rxxff/11CTnKclFRkbxFvRuZmZkpP164cMGkz62svMqammzdutXX19dyzxtvo9cEk6pabpH1TbAc 55p0shl3I1MiAEYlcQ4As2Q7j3OzZs3Ky8u7evWq8fW6GnJyc3Plunns2LFP/eTgwYOyXq6tw8LC OnTosGLFijt37ljY0ri0tLQ0Ly+vRuOceeGW45zxs3O9evV67733TNavWrUqNDRUWc7KympqnNNs 2v79+2Wl2m/WxDmlHPUtly9flh8PHDhg3gprKq+yUJNdu3YFBQU92aB///6aLdXcxnKcMzk9Gm1R o00QAQEBb775pvqjpD4JeHrngzUnG1MiAEYlcQ4As2T7j3Pqs3Oa1+tnz56V6+a9e/dqvl0u3N3d 3Tdv3mxhy2bEOfPClTiXmJioLK9evVozzpWVlUkdJM+0bJzTbFpJSYmjo6NyJ9DKOHf69Gkp5/PP P1d+/PTTT+XHM2fO3Gec06tJYWGhRKCcnBxZ3rFjh2ac09vGyjhnZYusiXPGH9QU77//voS0+znZ mBIBMCqJcwCYJR/0OCfkQnzixInKR91u3bqlfCAzLy+vtrbWYDAEBQUlJSVZ2FIvzsXHx+t9X6Jm 4TNnzoyJiamurk5NTe3WrZtxnJs0aVJlZWVdXd2GDRt69Ohhvl9r4pxJfUx+1GzayJEj4+LiKioq jh07NmzYsEbjXH19vbwlNjZW3i4Vjo6OHjVqlDTzPuOcXk3y8/MlqhUVFUnemzt3rlo946bpbWNl nLOyRdY0Yf369V27dpX6KwFVavjaa69ZOB8aPdmYEgEwKlsxzvG8LwDmAVvoamvinFxbT5kyxdnZ 2d/f38PDQ/ko3cCBA+XS39fXNzIyUvmGDL0t9eLcyZMnpRAfHx/l1pAxzcL37dvXt2/fjh07RkVF yaW/cZybM2fOY489JiW7u7urd4qaGudM6mPyo2bTsrOzXV1dZWVgYOCmTZusyUKFhYUSeCSOSnQZ M2aMciPr/uOcXk2krzp16tSnT5+UlBQJuso3nZg0TXMbK+OclS2ypglyoCUNOjg4+Pn5ScKUiK5+ SWbzTjamRACMylaMcwAA+1JVVXXt2jXjNTcbWLOlBVeuXNH8BkLNwuvq6iorK01W3rhxo6amxmAw SFHKfaH7YVIfkx/Nm1ZbW2t9Y1Xl5eXmDblPejWRfSlNuNVAs2l627R9i6ScgoIC4yc5W/Bk+9lV l1UykwAgzgEAANifvzuMzvnFvKv/PERXACDOAQAA2Fmck9dHTmN2uk4oePldbtYBIM4BAADYU5xT Xx85BXGzDoC9xjme9wXAPEBXAw9ynDO5Wfff/55EFwH89bSbOMe38QJgHvh5LyJ58eJla6+LH3/B fAVwoUKcA8AsCboasPV/WPlkSMyXM1b+c/DsrAEzvt2QyjgF+OtJnAPALAm6GrDpOLez6zN5k1/J mxqf/mho/qxXr312xFBbxzgF+OtJnAPALAm6GrDpkWh8O87kmy0ZpwB/Pe0pzvFcPgDmAboaeNAu DY1vxzFOAf562nGcAwAAeKDwH80BIM4BAAAAAIhzAAAAAECcAwAAAAA8EHGO530BMA/Q1QAYpwCj 0i7jHN/GC4B5gK4GwDgFGJXEOQDMkqCrAcYpAEYlcQ4AsyRdDYBxCjAqiXPMWQCYB+hqAIxTgFHZ 3uIcz/sCYB6gqwEwTgFGpV3GOQAAAAAAcQ4AAAAAQJwDAAAAAOIcAAAAAKC9xTme9wXAPEBXA2jj cVpaWlpRUdGquzAYDHfv3rX3w1FbW1tfX/+AVLKVDlkbnGz89fw54xzfxguAeYCuBmB5nO7du3ff vn0mKzMyMgoLC60pMysrq6CgQFmuqakJDw/39/f38vI6ffp06zVk586d3bt3t4UuLSkpSU5Ovnbt WjPeO2HChDVr1pivz8zMzM3NNenk7777zkJRJ06cOHr0aJtV8s6dO8lmrl692paHrG1Otr///e/H jx9Xf7x48eKHH37IX0/iHAAyBl0NwFbGaWJiolwQG9+BKS8v79ixY3FxsTVlzpkzJyEhQVnOycnp 169fGzSkSdng0qVLVralGVatWuXg4PDGG280oyZ6cW706NGdO3c+e/asuuaZZ55JSUmxUHJ0dHR6 enqbVfLmzZvzjTz55JNSvprqm3fImnqY2uZk8/Pz27Bhg/pjdnZ2i++UOMe1BQDmAboaQPPHaVlZ 2UMPPbR37151zV/+8pfx48c3o3y57p84caKtxblp06YtW7asNapRW1vr6ekZEBDg7e1tzScSTWpi Ic45OzvLbw0GgzVx7u7du7169aqqqmrLSqoqKir69u07d+7c+zxkTT1MbXOyEeeIcwDIGHQ1AFsf pzNmzJgzZ47645gxY5TwcP36dfmVXIUPGjRI/fhfXFxcYmLiokWLZP2NGzfkx02bNikh0M3NrUuX LpIc5O3PP//8qlWr1DL//d///Y9//KPJfpOSkoKDg3v27Dlp0qQjR46o5cv6tWvX+vj4jBs3Tl0v sXP69OmyixEjRixfvlwzG+Tn54eFhQNtX7sAAF4ZSURBVMmv5L2lpaWyZt26dS4uLrJGarV79+57 DfceZRceHh69e/eeN2+e+uSVSbs0224iIyNDctTRo0cdHBw++eQTdX1kZGRaWpqynJqaKtXWrImS lMxbKnHud7/7XYcOHbZt22ZNnPviiy/Cw8P1fttKlVTFxMRIUKysrNT8lwLNQ2Z+3M33q3luGP+L g/HJZn74LBxlKXn16tV9+vQZOXJkYWGhdMLAgQMff/zxrKysJsU585PNyiFDnGsCnssHwDxAVwNo dJzu2bOnU6dOyhW5XODK8o8//ijLciW9YMECuQDdsmVLYGCgsrFc37u7u2/cuFG2rK+vV+/e/Otf /4qPj3/66aflivb27duSEB599NE7d+7Ir6Q0uVg/efKkyX7T09OPHz9eXV0dGxs7e/ZstXxPT8+l S5eeOnVKroyjoqKU9c8++2xERERxcfHly5climjGOckbct1sMBjOnz9fU1Mja6qqqiTqLF68WGol O5I18mNoaOi3DUJCQiZPnqzZLs22m5gyZcrKlStlYdSoUTNnzlTXDxkyRIm4IiEhYfjw4Zo10Wup xLkPPvhAwrCrq+ulS5cajXOvvPKKurs2q6Tio48+cnR0/OyzzzR3rXfIzI+7+X41zw2Vyclmfvgs HGUJeG+99ZacIU899dSAAQN+9atffffddy+99JJ0e5PinPnJZuWQeXD+evIfFQAAALSF2tpaDw+P rVu3yvLvf//7X/7yl7Jw7tw5BweHjIwMuSAuKChwdnYuKSlRrk0XLlyovtf4w3ivv/66XDqrF9yS RiSWyLLEBrn2tVAB2bWvr69aYExMjLK8fft2b2/vew1fQSGVkYtpZb3eJ/fGjx+v5Afjlcaf4isq KpJylPs/9xq+dER+vHDhgkm79NpuTN4l68+cOSPLycnJDz30kHqLRjMp3dP6HKN5S9U4J0nm8ccf nzp1aqNxTjKJ3lNnrVdJcfXqVTc3N0l6mru25pAZH3e9D1sab2PM+GQzOXyWj/KSJUuU9a+++uqI ESOUfLVnz57OnTs3Kc6Zn2xWDpkHB3EOAACgjSxfvlxShMFgkEtn5To4NzdXrk3Hjh371E8OHjx4 z+xhKr04J/7P//k/oaGhsiCx5D//8z/Nd7pr166goKAnG/Tv39+8wLS0NC8vL1nYv3+/VEb97kS9 OCfX1mFhYR06dFixYoVyY9AkJyiNUsu5fPmy/HjgwAGT/eq13Zhs/Oijjy5t8MILL8j2b7/9dlOT knlL1TgnC4cPH3Zycvrb3/5mIc5JctC7ediqlRSTJ09+7LHHlJtj5iwcMs3jbrJfzW0sxzmTw9fo UV61apVyft5r+O5QzTgXEBDw5ptvqj9K6pOAp3eyWTlkiHMAAABoYadOnZIr0f/4j//o2bOn8v+D nT17VtYYf0WK+XWz5Th37NgxR0dHCXJyHa+GK1VhYaFcCufk5Mjyjh07LMe5kpISKerQoUOW45xC Ltzd3d03b95snhNOnz4tjfr888+VHz/99FP5Ubl5Zbxfvbar6urqpGK//e1vt/wkIiJi0KBBalJK TExUllevXt3sOCdkezkiTzzxhF6c+9Of/mT8jGKbVXLbtm1y+Cz/7wiah0zvuBvvV28bK+OclUfZ mjhn/EFN8f7770tI0zvZrBwyxDkAAAC0vFGjRskV7W9+8xt1jVzsTpw4Ufk42a1bt27evNmkOCeG Dh0qZb788svmu8vPz5dL9qKiIrnunzt3rhrP9PLDyJEj4+LiKioqJCUOGzZMM87l5eXV1tYaDIag oKCkpCRlZXx8vPoViPX19VJObGystKWysjI6OlparXyBpEm7NNuukqt/SVnqE1NC+a4R5W7MzJkz Y2JiqqurU1NTu3XrpiYl45pYGedu3749YMAAKVkvzgUHB6uRyUTrVVJyi4uLi2z5oxFJjyYV0Dxk esfdeL9621gZ56w8ytbEufXr13ft2lXqrwRUqeFrr71m4WSzZsgQ55qA5/IBMA/Q1QCsHKdbtmyR a/3Dhw+ra+T6dcqUKc7Ozv7+/h4eHuYfV2s0zsllrpT57bffau4xKiqqU6dOffr0kazSo0cP5Rsv 9EJOdna2q6urVCYwMHDTpk2al/gDBw6U9b6+vpGRkeqHAE+ePCnrfXx8lLs9hYWFcnEvAUYu08eM GaPctDFvl2bbVc8999zy5ctN9i6JZd68ebKwb9++vn37duzYURooeUBNSiY1sSbO3Wu4/+Po6KgZ 58rLyz09PfX++4HWq2RycrKDmf3795vsS++QaR53k/1qbmNlnLPyKFsT5+QskjQorfPz85OEOWnS JPVLMjVPNmuGzIPz15P/qABAC2AeoKsB3Oc4raqqunbtWvP2+PbbbwcHB1vYQAKJkkZuNbBcWm1t baM1udnAfP2VK1dM/qt0ze/Wb6m219XV6ZVvUpP7Ifnq+eefb/bb26CSeodM77gb77dJ54be2WXN UbamnIKCAvVhvEZPtiadNvxHBVxbAGAeoKsB2OI4lUt5b2/vv/3tb/R8K3n55Zf37NlDPzAqiXMA mCVBVwOM0xZ24cKFN954Q/lvxAAQ5+gdAMwDdDUAxinAqHww4hzP5QNgHqCrATBOAUalXcY5AAAA AABxDgAAwL793WG0jbw4FgBxDgAAAHaZKukEgDgHAAAA4hyAdhrneN4XAPMAXQ3A1sYpcQ54EP56 8h8VAOCiga4G0A7HKdMF8CAMB+IcAGZJuhoAcQ5gVBLnADBLgq4GGKfEOYBRSZwDwCwJuhpgnDJd AAyH1o1zPJcPgHmArgZg5TitLqvk+hXgr6cNxTkAAABYVlt1+8SqLRnuEW2WsohzwIOAOAcAANCK Svd99UXwwo+cx0q+Ul7EOQDEOQAAANtlfDvO5EWcA0CcAwAAsEXmt+OIcwBsN87xXD4A5gG6GoDi 6ieH9FJc2784HEC7/+vJf1QAoAUwD9DVAIzH6fcJH2YH/DKjV8Qur2mkLIC/nsQ5AMySoKsBOxun pfsKjjz/1sddgrMGzPi4czBxDuCvJ3EOALMkXQ3AnsZpdVmlyc06ugjgrydxDgCzJF0NwJ7GqXKz jlEM8NfTtuIcz+UDYB6gqwFYOU6ryyrpIoC/njYU5wAAAAAAxDkAAAAAAHEOAAAAAIhzAAAAAID2 Fud4Lh8A8wBdDYBxCjAq7TLO8X27AJgH6GoAjFOAUUmcA8AsCboaYJwCYFQS5wAwS9LVABinAKOS OMecBYB5gK4GwDgFGJXtLc7xvC8A5gG6GgDjFGBU2mWcAwAAAAAQ5wAAAAAAxDkAAH5WpaWlFRUV bbMvg8Fw9+5d+hwAiHMAAPuTmZmZnJyckpKSnp5eVFREh1gpKyuroKCgxYutqakJDw/39/f38vI6 ffp0GzRk586d3bt3b9VG2fjJL/76179++eWXZWVlNnUyAIBNxzme9wXAPGALXT169OihQ4dGR0f7 +fk5OTllZGS0Wa0uXbpUXFxsp106Z86chISEFm9gTk5Ov3792rIhxnHOmkbZ7GFtxn7l5B8yZMgL L7wwderUwYMHd+zYMSkpqZVOBqZEgAuV9hbn+DZeAMwDttDVckW7cuVKZTkkJCQiIqLNajVt2rRl y5a1425vRgPXrFkzceLEnyvO2fVhbcZ+5eRfvny5+uPWrVsdHBw++OADpkQA7X5UEucAMEu2wzi3 ZMkSHx8fWYiLi0tMTFy0aJFc6N+4ceP69eszZsyQ5UGDBuXm5iob5+fnh4WFyUp5S2lpqbJSc0sp LSkpae3atbLluHHjjhw5IivXrVvn4uIiWwYEBOzevdukVpqFR0ZGpqWlKcupqanTp09XlsvLy+fP n9+3b99HHnlkxIgRFlZa3xDNlcakUZs2bWpSA/U6R+3qd955x83NrUuXLvKWlJQU+a0UGxwc3LNn z0mTJinFNqlpesrKyqT3ZF/ydskzapwzaVSj54B5TSwfVr0j2KRzybhWasnm+5W6ycYeHh69e/ee N2+e5rOIJnFOPPfcc0OHDtWrgDRWjpG68UsvvSQJ0KTf7ufoMCUCXKgQ5wAwS6KZce7MmTOurq4v vviiLE+YMMHd3X3jxo2FhYX19fWSJRYsWCBXz1u2bAkMDFTeKLlFLqwNBsP58+dramqUlZpbSmme np5Lly49deqUXNRGRUXJyqqqqvDw8MWLF8uVbnV1tUmtNAsfMmSIetGckJAwfPhwdaf+/v7Z2dmy 5TfffGN5pZUN0VxpTBq1Zs2aJjVQr3PUrpa3xMfHP/300/KW27dvy2/T09OPHz8ub4+NjZ09e3ZT m6bn2WefjYiIKC4uvnz5skQsNc6ZNKrRc8C8JpYPq94RbNK5ZFwrtWTz/cqPoaGh3zYICQmZPHmy NXFOavXwww/X1dVpVuD999/39fWVeiqRuHPnzsrHO4377X6ODlMiwIUKcQ4AsySaHOf8/PwGDx7s 6Og4c+bMmzdvKpenCxcuVDY4d+6cg4NDRkaGXBYXFBQ4OzuXlJTI+vHjxyuRQC1Kb0spLSYmRtlm +/bt3t7eyrKFT8eZF64XBpSdmjy5ZGGlNQ3RW2khzjXaQAudo3a1eP311yV7mO9u69atEiSa2jRN Fy9elI0lbyg/Gn/Y0qRRls8BzZpYPqx6ca5J55Jxd+ntt6ioSN6u3h7MzMyUHy9cuNBonJPA5uTk JIFQswISGl1cXPbv3y9bvvPOO5KKTfrtPo8OUyLAhYo9xTme9wXAPGALXS1XtLNmzcrLy7t69apm VsnNzZWL0bFjxz71k4MHD8p6ufgOCwvr0KHDihUr7ty5Y2FL49LS0tK8vLwave43L1wvDCg7/frr r43fbmGlNQ3RW2khzjXaQGs6xzzO7dq1Kygo6MkG/fv3b2rTNEkakY3Vw20hzlk+BzRr0rw417xz ycJ+lberbbx8+bL8eODAgUbj3O9//3slNutV4Ne//vW8efNkYdCgQenp6SZ9dZ9HhykR4ELFnuIc AMAWGD87p5lVzp49Kxeje/fu1Xy7XCK7u7tv3rzZwpbNiHPmhSthIDExUVlevXq1EgaUnSqPMKks rLSmIZZXNi/OWdM5JnGusLBQEk5OTo4s79ixQ4lzzWiaiZKSEkdHx0OHDlkf5zTL16xJo3HO/Ag2 +1yysN/Tp0/L2z///HPlx08//VR+PHPmjOU4d/fuXclyL7/8soUKSDZzcXHJzs7u3bt3bW2tSa3u /+gAAHEOANCScU6EhoZOnDhR+SzcrVu3lA9k5uXlyeWswWAICgpSv95dc0u9tBMfH6/3LY6ahc+c OTMmJqa6ujo1NbVbt25qGJBCAgMDv/rqK1n+/vvvlUeqNFda3xDNlU2NcyYNbLRzTOJcfn6+xLmi oiIJYHPnzlVDl/VNk1yxYcMG88qPHDkyLi6uoqLi2LFjw4YNazTO6ZWvWRMLh1XvCDbvXDJhvF+p ibQxNjZW3lVZWRkdHT1q1CjlmTfNOHf79u2CgoKIiAiJcz/++KOFCkgh/fr169Wr12uvvaZ5Mlh/ dACAOAcAaIs4J3FiypQpzs7O/v7+Hh4eyofWBg4cKDFALn8jIyOV7+3Q21Iv7Zw8eVIK8fHxUW5A GdMsfN++fX379u3YsWNUVNT69evVMHDlyhXZhYODg5ubm7e3t/JNGJorrW+I5sqmxjmTBjbaOffM PmwpLe3UqVOfPn1SUlJ69OihfBuK9U0LCwt74oknzCufnZ3t6uoqG0vw2LRpkzVxTrN8zZpYOKx6 R7B555IJk/0WFhZKhJPQ2LVr1zFjxpjfmlNOfqm8o6Nj586dJdYuW7bMOGhpVuBewwcy5S3nzp3T PBmsPzoAQJwDALSdqqqqa9euGa+52cCaLS2Qy1/jryi0XHhdXV1lZaVmOT/88IP5rzRXWtkQvdY1 lUkDm9Q59xq++F55+60GTWraiRMnoqOjNYutra1tUjUsVF6zJnqHVe8Itsi5ZL5f6T29E+Z+mtwo K088ALDjOMfzvgCYB2ynq6vLKuml9ufPf/6z8jWMYEoEwKhs4TjHt/ECYB742bu6tur2iVVbMtwj OBYAUyKAB2dUEucAMEvad1eX7vvqi+CFHzmPlV8pL3oJYEoEQJyjdwAwD9huVxvfjjN50UsAUyIA 4hy9A4B5wBa72vx2HHEOYEoEQJxrJp73BcA80GYOxb6hl+J48eJlOy8mK4ALFbuJcwCAtlRdVvl9 wofZAb/M6BWxy2sa15EAADywiHMAYK9K9xUcef6tj7sEZw2Y8XHnYOIcAADEOQCAPTG/WUefAABA nAMA2BPlZh1xDgAA4lwT8BUIAJgHbKerq8sq6SWAKRHAAzIq+Y8KALQA5gG6GgDjFGBUEucAMEuC rgYYpwAYlcQ5AMySdDUAxinAqCTOMWcBYB6gqwEwTgFGZXuLczzvC4B5gK4GwDgFGJV2GecAAAAA AMQ5AAAAAABxDgAAAACIcwAAAACA9hbneN4XAPMAXQ2AcQowKu0yzvFtvACYB+hqAIxTgFFJnAPA LAm6GmCcAmBUEucAMEvS1QAYpwCjkjjHnNU+lJaWVlRUtM2+DAbD3bt36XNmSdDVAOMUAKPSduOc 3pOFmZmZycnJKSkp6enpRUVFnEZWysrKKigoaPFia2pqwsPD/f39vby8Tp8+3QYN2blzZ/fu3Vu1 UTZLOfnFX//61y+//LKsrMymTobWwHP/dDUAxinAqLTLOKdn9OjRQ4cOjY6O9vPzc3JyysjIaLNW Xbp0qbi42E4PyZw5cxISElq8gTk5Of369WvLhhjHOWsaZbOHtRn7lZN/yJAhL7zwwtSpUwcPHtyx Y8ekpKRWOhkAAADwwGrdOLdy5UplOSQkJCIios1aNW3atGXLlrXjw9aMBq5Zs2bixIk/V5yz68Pa jP3Kyb98+XL1x61btzo4OHzwwQfMOAAAALC/OLdkyRIfHx9ZiIuLS0xMXLRokVzo37hx4/r16zNm zJDlQYMG5ebmKhvn5+eHhYXJSnlLaWmpslJzSyktKSlp7dq1suW4ceOOHDkiK9etW+fi4iJbBgQE 7N6926RWmoVHRkampaUpy6mpqdOnT1eWy8vL58+f37dv30ceeWTEiBEWVlrfEM2VxqRRmzZtalID 9TpH7ep33nnHzc2tS5cu8paUlBT5rRQbHBzcs2fPSZMmKcU2qWl6ysrKpPdkX/J2yTNqnDNpVKPn gHlNLB9WvSPYpHPJuFZqyeb7lbrJxh4eHr179543b57ms4gmcU4899xzQ4cO1auANFaOkbrxSy+9 JAnQpN/u/+gAAACAONfkOHfmzBlXV9cXX3xRlidMmODu7r5x48bCwsL6+nrJEgsWLJCr5y1btgQG BipvlNwiF9YGg+H8+fM1NTXKSs0tpTRPT8+lS5eeOnVKLmqjoqJkZVVVVXh4+OLFi+VKt7q62qRW moUPGTJEvWhOSEgYPny4ulN/f//s7GzZ8ptvvrG80sqGaK40Jo1as2ZNkxqo1zlqV8tb4uPjn376 aXnL7du35bfp6enHjx+Xt8fGxs6ePbupTdPz7LPPRkREFBcXX758WSKWGudMGtXoOWBeE8uHVe8I NulcMq6VWrL5fuXH0NDQbxuEhIRMnjzZmjgntXr44Yfr6uo0K/D+++/7+vpKPZVI3LlzZ+Xjncb9 dv9HBwAAAMQ5U3pPFsoVrZ+f3+DBgx0dHWfOnHnz5k3l8nThwoXKBufOnXNwcMjIyJDL4oKCAmdn 55KSElk/fvx4JRKoReltKaXFxMQo22zfvt3b21tZtvDpOPPC9cKAslOTJ5csrLSmIXorLcS5Rhto oXPUrhavv/66ZA/z3W3dulWCRFObpunixYuyseQN5UfjD1uaNMryOaBZE8uHVS/ONelcMu4uvf0W FRXJ29Xbg5mZmfLjhQsXGo1zEticnJwkEGpWQEKji4vL/v37Zct33nlHUrFJv93/0WltPPdPVwNg nAKMSruMc3rf+ylXtLNmzcrLy7t69apmVsnNzZWL0bFjxz71k4MHD8p6ufgOCwvr0KHDihUr7ty5 Y2FL49LS0tK8vLwave43L1wvDCg7/frrr43fbmGlNQ3RW2khzjXaQGs6xzzO7dq1Kygo6MkG/fv3 b2rTNEkakY3Vw20hzlk+BzRr0rw417xzycJ+lberbbx8+bL8eODAgUbj3O9//3slNutV4Ne//vW8 efNkYdCgQenp6SZ9df9Hp7Xxrdx0NQDGKcCobG9xTn12TjOrnD17Vi5G9+7dq/l2uUR2d3ffvHmz hS2bEefMC1fCQGJiorK8evVqJQwoO1UeYVJZWGlNQyyvbF6cs6ZzTOJcYWGhJJycnBxZ3rFjhxLn mtE0EyUlJY6OjocOHbI+zmmWr1mTRuOc+RFs9rlkYb+nT5+Wt3/++efKj59++qn8eObMGctx7u7d u5LlXn75ZQsVkGzm4uKSnZ3du3fv2tpak1rd/9FhluQPEgDGKcCoJM61ZJwToaGhEydOVD4Ld+vW LeUDmXl5eXI5azAYgoKC1K9319xSL+3Ex8frfYujZuEzZ86MiYmprq5OTU3t1q2bGgakkMDAwK++ +kqWv//+e+WRKs2V1jdEc2VT45xJAxvtHJM4l5+fL3GuqKhIAtjcuXPV0GV90yRXbNiwwbzyI0eO jIuLq6ioOHbs2LBhwxqNc3rla9bEwmHVO4LNO5dMGO9XaiJtjI2NlXdVVlZGR0ePGjVKeeZNM87d vn27oKAgIiJC4tyPP/5ooQJSSL9+/Xr16vXaa69pngzWHx1mSf4gAWCcAiDOtUWckzgxZcoUZ2dn f39/Dw8P5UNrAwcOlBggl7+RkZHK93bobamXdk6ePCmF+Pj4KDegjGkWvm/fvr59+3bs2DEqKmr9 +vVqGLhy5YrswsHBwc3NzdvbW/kmDM2V1jdEc2VT45xJAxvtnHtmH7aUlnbq1KlPnz4pKSk9evRQ vg3F+qaFhYU98cQT5pXPzs52dXWVjSV4bNq0yZo4p1m+Zk0sHFa9I9i8c8mEyX4LCwslwklo7Nq1 65gxY8xvzSknv1Te0dGxc+fOEmuXLVtmHLQ0K3Cv4QOZ8pZz585pngzWHx1mSf4gAWCcAiDOWcvy k4XVZZWNllBVVXXt2jXjNTcbWLOlBXL5a/wVhZYLr6urq6zUruoPP/xg/ivNlVY2RK91TWXSwCZ1 zr2GL75X3n6rQZOaduLEiejoaM1ia2trm1QNC5XXrIneYdU7gi1yLpnvV3pP74S5nyY3ysoTr+3x 3D9dDYBxCjAq7TLOaV/TV90+sWpLhnsE/0DVLv35z39WvoYRAAAAQPuJc6X7vvoieOFHzmMlyCkv ehkAAAAAbDfOGd+OM3nRywAAAABgi3HO/HYccQ4AAAAAbD3OXf3kkF6K48WLFy9erfTirxdgy/gq FIBRaTdx7l7D935+n/BhdsAvM3pF7PKaxmUH8ABipNPVABinAKPSXuOcslC6r+DI82993CU4a8CM jzsHE+cAZknQ1QDjFACj0j7inKK6rNLkZh0nEMAsCboaYJwCYFTaQZxTKTfrmNEAZknQ1QDjFACj 0kbjnOUnC6vLKjmBgHaP5/7pagCMU4BRaZdxDgAAAABAnAMAAAAAEOcAAAAAgDgHAAAAAGhvcY7n fQEwD9DVABinAKPSLuMc38YLgHmArgbAOAUYlcQ5AMySoKsBxikARiVxDgCzJF0NgHEKMCqJc8xZ AJgH6GoAjFOAUdne4hzP+wJgHqCrATBOAUalXcY5AAAAAABxDgAAAABAnAMAAAAA4lwbMBgMd+/e bZe9XFtbW19fT18BAAAAsK04p/dkYUZGxpEjR6wvZ+fOnd27d1eWs7KyCgoK2k0vT5gwYc2aNS1Y oHFftYh21uFoezz3T1cDYJwCjEq7jHN63/v5i1/8YsWKFc2LKHPmzElISGhqTS5dulRcXGyPca6p Nb//OGeyx+Z1ONDoPAC6GmCcAmBUPnBxrnmmTZu2bNkye4xzTa15O+4rMEuCrgYYpwAYlbYV5+Li 4pKSktauXevj4zNu3Dj1Q5hlZWXTp093c3MbMWLE8uXL1Ygi22/atElZLi8vnz9/ft++fR955BHZ TFkppQUHB/fs2XPSpElKaevWrXNxcZESAgICdu/eLWuuX78+Y8YMWTNo0KDc3FzzGmqWLCtl7x4e Hr179543b15FRYVxE1avXt2nT5+RI0cWFhampaUNHDjw8ccfz8rKUrd57733XnnlFXn7gAEDMjMz zeOcea2srLleXxkz7xbNZprv0aTDLfSA+UEEuHahqwEwTgFGZXuOc5JnPD09ly5deurUKQkqUVFR yvpnn302IiKiuLj48uXLkZGRakQxzj+STPz9/bOzs2tqar755htlZXp6+vHjx6urq2NjY2fPni1r qqqqwsPDFy9eLFlI1itvXLBgwY0bN7Zs2RIYGGheQ82SpZDQ0NBvG4SEhEyePFmtksSbt9566/z5 80899ZSktV/96lfffffdSy+9NHr0aHUbLy+vd99998SJE5KgevToUVdXZ94ck1pZWXO9vjJm3i2a zTTfo3ENLfSA5kEEuHahqwEwTgFGpb3GOb0nC03iXExMjLK8fft2b29vWbh48aKDg4PEDGW98QcI 1XRx7tw52cbCY11bt2719fVVlo0/QKi8MSMjQzJJQUGBs7NzSUmJ8Rs1Sy4qKpKVyg0rkZmZKT9e uHBBqdKSJUuU9a+++uqIESOUL6vcs2dP586d1WrLr5Tl8vJyee+hQ4fMm2Neq0ZrbqGvLHeLXgea fNhSraHlHjA/iIDleQB0NcA4BcCotOk4p8ckzqk3f9LS0ry8vGRh//79EhWuXr1qIc7l5ubKNl9/ /bVJ4bt27QoKCnqyQf/+/c0jivLGsWPHPvWTgwcPGpegWbKyUq3S5cuX5ccDBw6YNGHVqlWhoaHK clZWlnGcM35GrlevXu+99555c8xr1WjNLfSV5W7R60C9OGdlD6gHEQAAAMCDGOdKSkocHR2V+1d6 ce7s2bMSJ7Zu3WpccmFhYYcOHXJycmR5x44dmnFOeePevXv1qqdZ8unTp2Xl559/rvz46aefyo9n zpxpRpwrKyuT90qjzJtjXqtGa26hryx3i2YzLcQ5K3uAOAcAAAA80HFOjBw5Mi4urqKi4tixY8OG DdN8dm7ixImBgYFfffWVLH///ff19fX5+fmSW4qKiiTkzJ07V31XfHy8bKxWQBKX/Kh8Hf+tW7du 3rxpUkPzkoVUKTY2VjaurKyMjo4eNWqUwWCwPs5NmjRJ3lhXV7dhw4YePXooOzV+r2atrKm5Xl+p 9LrFvJnme1RraGUPEOcAAACABz3OZWdnu7q6Ojs7S97YtGmTZpy7cuWK/Ojg4ODm5ubt7a18dUdU VFSnTp369OmTkpIiqUn52o+TJ08OHDjQx8dHuUMlqWbKlClSuL+/v4eHh/KJQWOaJRcWFkqA6dat W9euXceMGaPcmLI+zk2dOvWxxx6TBrq7u6v3uIzfq1kra2qu11fGNLtFs5kmezSuoTU9QJwDAAAA 2kOcu88nC2tra69du9boZj/88ENlZaXxmvLycuVG060GxiFNWa+oqqqyXL55yUrh5isbpQQeg8Eg dVDuaOnRrFWjNbemr/S6RbOZJnu8/x5A+1ZdVtlK8wDabMoFwDgFGJXEuf+Fb+M1iXP0A9orGew5 v5h39Z+HmAd+3qNAJwCMUwCMSuJcy3v//fc1/79yoN1MhfL6yGnMTtcJBS+/a3yzjnmAP0gAGKcA o5I4B8DW45z6+sgpSL1ZxzzAHyQAjFOAUUmcA2A3cc74Zp0sWHiyDvxBAhinABiVthvnePHixUte Fz/+gj8YrY2vWAAYpwAYlS0Z5wA8OP+yZfz6ZEjMlzNW/nPw7KwBM77dkMrdOQAAAOIcAJuOczu7 PpM3+ZW8qfHpj4bmz3r12mdHDLV1dA4AAABxDoBNxzluxwEAABDnANhlnON2HAAAQLuKczzvCzwg LNyOYx5oM3Q1wDgFwKhsyTjHt/ECYB6gqwEwTgFGJXEOALMk6GqAcQqAUUmcA8AsSVcDYJwCjEri HHMWAOYBuhoA4xRgVLa3OMfzvgCYB+hqAIxTgFFpl3EOAAAAAECcAwAAAAAQ5wAAAACAOAcAAAAA aG9xjud9ATAP0NUAGKcAo9Iu4xzfxguAeYCuBsA4BRiVxDkAzJKgqwHGKQBGJXEOALMkXQ2AcQow KolzzFkAmAeM1dbW1tfX09XCYDDcvXuXUQBwaQQwKu0yzvG8LwAL80BmZmZycnJKSkp6enpRUZFN VbukpETqdu3atWa8d8KECWvWrGn2rrOysgoKCu6zq5tdiGYk27Nnz5tvvrl48eI//vGPcrB+/PFH K9+7c+fO7t27MwoALo0ARqVdxjkAsGD06NFDhw6Njo728/NzcnLKyMhos11funSpuLjYwgarVq1y cHB44403mlHafca5OXPmJCQk3GeLmleIufLy8tDQUC8vr9dee+0vf/lLfHz8E088kZubS5wDAIA4 B+BBj3MrV65UlkNCQiIiItps19OmTVu2bJneb2traz09PQMCAry9va352KRJafcZ51qjRc22cOFC X1/f69evG680GAzEOQAAiHMAiHP/L84tWbLEx8dHFuLi4hITExctWiQx4MaNGxIkZsyYIcuDBg1S bwrl5+eHhYXJSnlLaWmpslJzSyktKSlp7dq1suW4ceOOHDkiK9etW+fi4iJbSmDbvXu3ecUyMjJ6 9ep19OhRBweHTz75RF0fGRmZlpamLKempk6fPl2zNCXOmez0XsOdLqmPh4dH7969582bV1FRoVbS uMny46ZNm5RUGfC//eEPf5D10qLg4OCePXtOmjRJr0VqIZb3a945xmRLJyen5GTtT6HoFVtWViY9 4+bmNmLEiOXLl6txTvMAAQAA4hwA+45zZ86ccXV1ffHFF5Us5O7uvnHjxsLCwvr6ekksCxYskJCz ZcuWwMBA5Y2SPST/GAyG8+fP19TUKCs1t5TSPD09ly5deurUKckSUVFRsrKqqio8PHzx4sUSMKqr q80rNmXKFKVio0aNmjlzprp+yJAhakZKSEgYPny4ZmmaOxWyWWho6LcNQkJCJk+erFbSuMnGN/eu /2Tbtm0PP/zwvn37ZGV6evrx48dlX7GxsbNnz9arg1qIhf1q1lN1+PBhCbT/8z//o3n49Ip99tln IyIiiouLL1++LAFYjXOaBwgAANhunON5XwAW5gGJc35+foMHD3Z0dJTUdPPmTSVjLFy4UNng3Llz EicyMjIkMBQUFDg7O5eUlMj68ePHK4FBLUpvSyktJiZG2Wb79u3e3t7KsoWPJl64cEHeLglTlpOT kx966CH1BqBmnLun9WFL850WFRVJDdWbgZmZmfKj7Mukyfe0Pqt57NixLl267Nixw6SqW7du9fX1 Vevw67Fh5oVY3q9m56j27NkjG1+6dMm8l/SKvXjxoixkZ2cr69UPW+odIIApEQCj0nbjHN/GC8DC PCBxbtasWXl5eVevXtUMM7m5uZIBxo4d+9RPDh48KOslyIWFhXXo0GHFihV37tyxsKVxaWlpaV5e Xo3GOdn+0UcfXdrghRdekGLffvvtpsY5850qNVRbevn/a+9O4Gu68z6OJ6JSxC4SjaQIGtNEqCHo g5BEiNAJGjJkgscYOpbGo7RM0XYsr2lrCaVVVVN9OjW00aK2SmwxtUQ7KCPWWhJLJCUeQpY+v+b/ 9Mx97j335Mp+k8/7dV5e956c5X//9/7+53ydu1y5Inf37Nljmd/M7kpGcnd3nzlzpjbniy++CAgI eKZA8+bNtTb0d3C33IiN+zXtnH8f4Y4fl4VVT5qxttndu3ebztfinLUnCGBIBEBVEucA2Guc0z47 pxtmzp49Kxlg+/btuqtLeHB1dV22bJnBko8a53Jzc2WZSZMmLf9FaGioj4+PFucWL16sbku+eqQ4 d+rUKWnh119/reZv27ZN7qprgAZx7vbt27LToUOHat8+kpKSIjl2x44dcvvDDz8sNM7ZuF/dOJed nd2oUSP1Jlgz1jablpbm6Oh44MABszhn/FQCDIkAqEriHIDKFudEUFBQr1691Psq7969q96QuXfv 3pycHEk4AQEBcXFxBktaSyyxsbGysGWTNm/e3LhxY+3zeEJ9IYq6lDR48OCoqCgJOWvWrKlXr54W 58y2prvTvLy8jh07Dh8+XBqWmZkZGRnZqVMnFdKsxTl5jBImu3btqq5AKklJSRLnzp8/L8FpxIgR 2ifTfv4JAYe6lhuxcb+6ce6ngvdzOjk5vf322xJ01dY2bdp0+vRpg83K/Ojo6IyMjMOHD/v7+2st 1H2CAIZEAFQlcQ5ApY1zElrCwsIkUXh7e7u5ual3CbZu3VpCQosWLcLDw+/du2ewpLXEcvz4cdmI l5eXusylGThw4NSpU82aJJkkJiZGbiQmJnp4eDg7O0dERMybN0+Lc2Zbs7bTlJQUyTySA11cXLp0 6aIukRnEOfVNJLVq1ar/C9UM2fvjjz/+xBNPvP/++40aNVLfhiJtcHd4XLcNtuzXWpwTH3zwgeyl Zs2aTz31lCwjfS5xzmCzW7ZsqVu3rjwRfn5+S5cu1eKc7hMEMCQCoCorbpzj874ASmQcyMrKunbt mumcOwVsWdLA1atXbflZOVO5ubmZmZnF2Vp6erq1LdhONqL2dbeA1tUGbSjmfi9fvnzy5EnLX5zT 3WxOTo61Z+GRniCAIREAVVmecQ4AAKBKyb6ZSScAIM4BAADYn08dOu/4dUzqVwfoCgDEOQAAADuL czKtq9ZlQ93A5MkLuVgHgDgHAABgT3FOm9ZVC+BiHQB7jXN83hcA4wBdDVTlOGd2se7bl+LoIoCj p93EOb6NF4DumQ0TExNTlZ0urd/FoQGoUCcqxDniHADGAboagM7/YW31jdo/aPpXbYdubjXo5Pw1 1CnA0ZM4B4BREnQ1UKHj3AaXnnv7vbi3f+xn9YOShrx8befB/Jxc6hTg6EmcA8AoCboaqNCVaHo5 zuybLalTgKOnPcU5PpcPgHGArgaq2qmh6eU46hTg6GnHcQ4AAKBK4YfmABDnAAAAAADEOQAAAAAg zgEAAAAAqkSc4/O+ABgH6GoA1ClAVdplnOPbeAEwDtDVAKhTgKokzgFglARdDVCnAKhK4hwARkm6 GgB1ClCVxDnGLACMA3Q1AOoUoCorW5zj874AGAfoagDUKUBV2mWcAwAAAAAQ5wAAAAAAxDkAAAAA IM4BAAAAACpbnOPzvgAYB0pbTk5OXl4eXQ0wJAKgKks4zvFtvAAMxoGNGzeuLLBz584HDx6UbzvT 0tKkJdeuXSvfZnzyyScr9dy9e9faKoGBgbNnz2bIBex9SARAVRLnANjTKNm5c+d27dpFRkZ6eXm5 uLjs37/fYDuXL1++ePFi6bVzxowZDg4Os2bNKt/umjp16ugCvr6+rq6uo3+RkZFBnAM4cQRAVRLn AFSgODd9+nR1+5lnnhk2bJjBdgYMGDBlypRSamROTk7Tpk3btGnj6emp3rhY7uTBdunSxZYliXMA J44AqEriHIDyjHOS1gYOHKhu37hxY9CgQQ0aNPDx8UlISJA5c+fOrV27tsyRxPXll1/KnPDw8LVr 16rl16xZ89xzz6nb0dHRixcvHjdunCx8+/ZtuRsXF/fGG294eXl169bt4MGDui2Jj49v0qTJoUOH HBwctm7dqs1PT08fPXq0h4dHnTp1OnToYDDTss0iKSkpJCREZsrer1+/bjDTljgn+5WH4+bm5u7u HhMTo12v0+LcaoeOcnvdunUGTbKxQwBw4ghQlcQ5Pu8LwGgcUHFOUocEsxo1anz++edqfnBw8Jgx YySMLV++3M/PT+ZkZWX16dNn/PjxsnB2drbM8fX1Xbp0qVp+0aJF7du317KNq6vrggULUlJS8vLy 5G7Tpk0nTpx44sQJyTYRERG6LQkLC1PBslOnToMHD9bmS0u8vb23bNny4MGD77//3nimWZuF5CXJ lvn5+RcuXNA+HKg705Y4Jz0QFBR0skDv3r379etnGudkUwEtfKSLTBtv2SQbOwRA2Q+JAKjKChfn AMCAxDlnZ2dHR0cHB4cdO3aomefOnZO78fHxElqSk5OdnJzS0tJ+snizpUGcGzt2rLaY3I2KilK3 V61a5enpadmMH374QfZy5swZub1y5crHHntMXTRTLZGNmy5sMNOyzT169AgNDTX7yJ/uzELj3Pnz 52UX6srkTwXfIiN3peXqMc6aNWvEiBH9+/fPzc01bpItHQIAAIhzAFB4nIuNjZXs1KJFiwkTJqiZ CQkJkkO6du367C/27dv3SHFOvfPQ8u7atWubNWtm2QxZoH79+hMLjBo1Svb+5ptvai05evSo6cIG My3bLJktJCSkevXq06ZNu3//vlpYd2ahcU7tIjU1Vd29cuWK3N2zZ496jLKk3E1KSiq0SbZ0CAAA IM4BQOFxTr3Fcffu3dWqVdu8ebPcPnv2rOSQ7du3my1sGecWL16sbs+cObPIcS43N1dmTpo0afkv QkNDfXx8tJasWLHCdHmDmZZtViR0ubq6Llu2rNCZBnHu1KlTsouvv/5a3d22bZvcVVcU1WOcPHmy u7u7tMS4ScQ5AACIcwBQknFOSBqReKPeEBgUFNSrVy/1dsS7d+/euXNHbsTGxspMbd3BgwdHRUVl Z2evWbOmXr16RY5zkiEbN25s+hk29YUo6lqW7NHPz+/IkSNy+/Tp0+pLL3Vn6rZ57969OTk5+fn5 AQEBcXFxavu6MwuNc7KXjh07Dh8+XLacmZkZGRnZqVMn2Yj2GOV2dHR0y5YtVR9aaxJxDgAA4pyt +LwvgEK/CkXdvnfvXps2bfr06SOxRAJJWFiYk5OTt7e3m5ubekvh8ePHW7du7eXlpT5ll5iY6OHh 4ezsHBERMW/evCLHuYEDB06dOtVspr+/f0xMjNy4evWqbEHSXcOGDT09PdW3sOjO1G2zNLhBgwYt WrQIDw+XB6g2rjuz0DgnUlJSJMJJdnVxcZE/qUtzpo/xu1fflW22a9dO8p61JhHngAo7JAKgKitc nOPbeAEUOg5k38zUnZ+VlXXt2jWzmRKltN+Fy83NVbmltN26dctyR7ozLdt8p4DZYrozbZSenm7t Uet2tW43AqiwQyIAqpI4B8AORsmcrHvHZiyPdw1loOCABFCnAKhK4hwA+xglryce2dV97DqnrvIn NdFLHJAA6hQAVUmcA1BxR0nTy3FmE73EAQmgTgFQlRUuzvF5XwAyDlhejiPOlVJX0wkAdQqAqiyx OAcAqVsPWEtxTExMTFVw4rgAgDgHwJ5k38w8vehvW9o8H98k9ItmAzi5AQAAIM4BsDPXE5MPjnx9 fa3um1sNWl+zO3EOAACAOAfAnlherKNPAAAAKlyc4/O+AAzGAXWxjjhXBl0NgDoFUNWqkh8qAFAC Ch0Hsm9m0ktl09UAqFMAVacqiXMAGCXpagDUKUBVEucAMEqCrgaoU+oUoCqJcwAYJUFXA9QpAKqy dOMcn/cFwDhAVwOgTgGq0i7jHAAAAACAOAcAAAAAIM4BAAAAAHEOAAAAAFDZ4hyf9wXAOEBXA6BO AarSLuMc38YLFGrRokU9K7VfOdSJiYmZjdI3xMGDTgCoUwBVsCrlXEtOupYsWUKcA8qav7+/AwAA AFA87du3J84BZU0KT1Xgf1RG6qEFBgbOQekb4uBBJwDUKYAqWJXNmzcnzgHlo2fPnirLZVRG06dP l0c3e/ZsnugywJALUKcAqmZVqvPJwMDAEo5zfN4XIM4R58oMQy5AnQKomlVZWnEOAHGOOAcAAECc A4hz//bCCy8MHDgwNTWVOAcAAMD5JHEOsKc417ZtW1nr0qVLFTzOjR8/njgHAABAnAOIc3YW5777 7jv1zZbEOQAAAPuLc3zeFyiDOPevf/1r6NCh7u7udevWffbZZ7dv366WsTa/b9++rVq12rZtW6dO neRPAwYMOH/+fIlnuRMnTjz55JPSSLe6DS5cuMATXQYYcgHqFEDVrMrSinN8Gy9Q2nHuxo0bvr6+ 1apVmzZt2nvvvefm5ubs7Hzw4EFr87V1n3766QkTJrRs2VJuz5w5s5SyXPPmzZc6+PMslw2GXIA6 BVA1q5I4B9hrnPvss8/khr+/v5ov4U3u/v73v7c2X1s3KSlJbicmJsrtzp07l+x7LLUsd+bMGcYB DkgAqFOAqiTOAcQ5nTj31ltvyY3o6Gg1/+OPP5a7ISEh1uabvVEzLS1Nbj/22GO3bt0qqSzn7e2t ZTnGAQ5IAKhTgKokzgHEOf0498knn8iNgIAANf+1116TuzExMdbmm8U5dXWuWbNmJZvlZIPa5+UY BzggAaBOAarSLuMcn/cFSjvOXblyxdPTs0aNGitWrEhISPjVr37l6Oi4bds2a/O1dceMGbNnz56+ ffvK7cmTJ5fg5+VMsxzjQFmiqwHqFEDVrEp+qACw1zgnt5OSkjp06KB+EqBJkybvv/++WsbafLXu 888/71igf//+ly9fLsHvPuF7LAEAAIhzAHHuEVy8ePH06dO2zNeioJDoVeLffcJzCgAAQJwDqgR/ f391AW16WXF1dZXdxcbGlsjWxo8fr9pPlgMAACDOAVWLuq5l78w+LwcAAAC7j3N83hcolLo617x5 89n2zCDLMQ6UGboaoE4BVM2q5IcKgIpVfpUJ4wBdDYA6BahK4hxAnGOUBF0NUKcAqEriHECcY5Sk qwFQpwBVSZxjzAKIc4wDdDUA6hSgKitbnOPzvgBxjnGArgZAnQJUpV3GOQDEOQAAABDnAOIcAAAA QJwDiHMAAAAgzgEgzgEAAKCyxTk+7wsQ5xgH6GoA1ClAVdplnOPbeAHiHOMAXQ2AOgWoSuIcQJxj lARdDVCnAKhK4hxQYYwcOVLKT/5llARdDVCnAKjKkjqfJM4BZWH27NlSfnPmzGGULKacnJy8vLzK 0Wn5+fkPHz5kyLU7lelFCE4cAarS3s8n+SoUgDj3U6mOAxs3blxp4p///GdxdhQYGCidWTk6bcOG DQ0aNKgiQ+6xY8cOHTpkOictLU1eD9euXSvfhn3yyScr9dy9e7cqvAhR9kMiAKqywsU5AMQ5A507 d/b19R39i61bt1pb8vLlyxcvXiz3OGdLM0pkxaLFOTsVGRn52Wefmc6ZMWOGFMWsWbPKt2FTp05V r0x5lbq6umov1IyMDOIcAIA4B4A411nOmG1ZcsCAAVOmTCn3OGdLM0pkxaoT5x4+fNikSZOsrCxt Tk5OTtOmTdu0aePp6VlB3rgoz12XLl1sWZI4BwAgzgGUX5WOczdu3Bg0aJCEGR8fn4SEBJkzd+7c 2rVryxw5xf/yyy9lTnp6+ujRoz08POrUqdOhQwfTM+k33njDy8urW7duBw8etNxjdHT0kiVLXnzx RTc3t1atWm3cuFGbv3jx4nHjxslebt++LduXObKMu7t7TEyMuhpj2QzLpuq2zcYVb968+dxzzzVs 2FDWkm7RjXNm7dTdTlJSUkhIiMyUfrh+/brWKstHJMLDw9euXatur1mzRhpgrUMsO1x375qIiIiP P/5Y3X7hhRd+85vfqNt79+4dMmSIttiuXbv69OljumJ8fLwEvEOHDkldmF6w1W2D7Q3T7RbdmbbE OWv9qcW5H3/8UW6vW7fOoEmyhbi4OONXLAAAxDmAOFdx49zw4cO/KaB9cC44OHjMmDESIZYvX+7n 5ydzsrKy5Ix//Pjxck6cnZ2tlvH29t6yZcuDBw++//577Uy6adOmEydOPHHihJw6S5yw3KMs06xZ s4ULFx47dkxiQKNGjXJzc9V8V1fXBQsWpKSk5OXlye6CgoJOFujdu3e/fv2sNcOsqbpts3HFvn37 hoaGXrx48cqVK5KydOOcWTt1tyPBQJJYfn7+hQsXpA1qpu4jEr6+vkuXLlW3Fy1a1L59e2s7suxw 3b1rpk+friKcrCL97OTkpDKP9IMEGG0xidZaA5SwsDBZV2506tRp8ODB2nxrbbCxYbrdojvTljhn rT9VnJNNyUx5pKaNt2ySLa9YAADKM87xeV+AOGcwDkic8/Dw6F4gOjpa5pw7d056Iz4+Xs6Sk5OT JQOkpaX99P/frKiWkexhGXWioqLU7VWrVnl6eurGoZdfflndTk9Pl+0cOHBAzR87dqyaf/78eZmv LqP9VPB9LXL3hx9+0G2GWVOtta3QFS9duiQzJZaoZay92dK0nZbbSfyvt2R+jx49VCzU1jJ4RAZx zmxHZg/K2jOl2b17d506dR4+fLht2zZJO/7+/vKgJBm6u7ufOnVKW6xVq1amTZVWyabOnDkjt1eu XPnYY4+pi2YGbbCxYZbdYm1moXHOoD+l32bNmjVixIj+/fur/ykwaJItr1hUqSERAFVZ4eIc38YL EOcMxgHLN1smJCRIb3Tt2vXZX+zbt88sDqlljh49ahl1tI8trV27tlmzZrpxyPSjTU2aNFmyZInZ fLX91NRUdffKlStyd8+ePbrNMGuqtbYVuqKEH9OdGsQ5s3aabmeOQ1uZL+EkJCSkevXq06ZNu3// vvEjMohzZjsye1DWnilNTk5OvXr1ZLHx48e/++67L7300h/+8Ie9e/c+/fTT2jISb8wu68lO69ev P7HAqFGjZBdvvvmmcRtsbJhlt1ibWWicM+hP6TdZUu4mJSUV2iRbXrGoUkMiAKqSOAcQ5+w7zp09 e1Z6Y/v27QZxSC2zYsWKYsa5mzdvynYkOJnNP3XqlMz/+uuv1d1t27bJXXW9yLIZZk211rZCV0xL S3N0dFSXCm2Mc5bbMe1qSReurq7Lli0zfkQS5xYvXqzmz5w5UzfO6T4oa8+UqSFDhsjz6+npKclH 9t6yZcvJkyebxum//OUvM2bM0O7m5ubKszZp0qTlvwgNDfXx8TFuwyM1zLRbjGcaxDmD/lT9Jg/T 3d1dWmLcJOIcJ44AqEriHECcq1RxTgQFBfXq1Uu9/+3u3bt37tyRG7GxsTJTW0Zu+/n5HTlyRG6f Pn1aff+hjXEuODg4MzNTksP8+fMbNWqktm+6rmytY8eOw4cPlz/JkpGRkZ06dcrPz7dshm5Tddtm y4qy0+jo6IyMjMOHD/v7+xca5yy386FDx58KvmskJydHGhwQEBAXF2f8iAYPHhwVFZWdnb1mzZp6 9erpxjlrD0r3UZhavXq1bFMFIdlFrVq15O7x48e1Bbp3764lWLF58+bGjRubfoZNfSGKupal2wbb G2bZLdZmFhrnDPpT9ZvclqdS4qv2BlTdJll7xUpAlRcnYyMnjgCoSuIcQJyzvzgnZ8BhYWFOTk7e 3t5ubm7qPWySAVq3bu3l5bVjxw65e/XqVTkVln5r2LChp6en+n4RG+Nc//79n3rqKfmrq6urdoHF LL2kpKTICbpkDxcXFzmPVxdeLJuh21Tdttmy4pYtW+rWrSszJZ8sXbrUljhntp3ZBW+2lB3Jui1a tAgPD793757xI0pMTPTw8HB2do6IiJg3b561OKf7oHQfhanU1FRHR0ctmfTr1096Xvtrenp606ZN TX+KYODAgZavB0m2MTEx1tpge8N0u0V3ZqFxzqA/tX6TlCjbbNeuneQ9a02y9ooNCQlp27YtYyMn jgCoyvKPc3zeFyDOFW0cyMrKunbtmtlMOXc3Pfu/deuWOle2nXbxRDalLqcYkLyhu32zZug2Vbdt ha4oGcByU7b3ldbVdwrY+Ihyc3Nt7EbdB6X78G0hAWbkyJGPupZuG2xsmG63WOsrW1h7hTzSqxpV DadGAFVpT3EOAHGuQuFXniuOyZMnb9q0iX4AAJSB7JuZlfsBEucA4lyVsHr1assfvAYAAJXbpw6d d/w6JvWrA8Q5AMQ5AAAAO4tzMq2r1mVD3cDkyQsr38U64hxAnAMAAKjMcU6b1lULqGQX6/gqFIA4 V1oYB+hqANQpUKHinOnFuh0BoyvBxTp+qAAgzpXpAMrExMTExMTEVHGmS+t3EeeIcwBxjnGArgZA nQIV/T+Xt/pG7R80/au2Qze3GiR3uTrHmAUQ5xgH6GoA1ClQoePcBpeee/u9uLd/7Gf1g5KGvHxt 58H8nFx+RpwxCyDOMQ7Q1QCoU6BCl552Oe7k/DWml+OIc0b4vC9AnGMcoKsBUKdAucc57XJcpaxK fqgAIM4BAABUTpXvh+aIcwBxDgAAAMQ5AMQ5AAAAEOcAyg8AAAAo/zjH530B4hzjAF0NgDoFqEq7 jHN8Gy9AnGMcoKsBUKcAVUmcA4hzjJKgqwHqFABVSZwDiHOMknQ1AOoUoCqJc4xZAHGOcYCuBkCd AlRlZYtzfN4XIM4xDtDVAKhTgKq0yzgHgDgHAAAA4hxAnAMAAACIcwBxDgAAAMQ5AMQ5AAAAVLY4 x+d9AeIc40BJyc/Pf/jwIV0NMCQCoCrLKM7xbbwAcc5gHNi4cePKAjt37nzw4AEvBmMbNmxo0KAB Qy5QWYdEAFQlcQ4gztnTKNm5c+d27dpFRkZ6eXm5uLjs37/fYDuXL1++ePFiBXyARW7Yo65InAM4 cQRAVRLnAOJcBYpz06dPV7efeeaZYcOGGWxnwIABU6ZMqYAPsMgNe9QViXMAJ44AqEriHECcq4hx TrLNwIED1e0bN24MGjRIoouPj09CQoLMmTt3bu3atWVOmzZtvvzyS5kTHh6+du1atfyaNWuee+45 dTs6Onrx4sXjxo2ThW/fvi134+Li3njjDS8vr27duh08eNCyGbLMkiVLXnzxRTc3t1atWm3cuFF3 U+np6TJHlnF3d4+JicnIyNBtmGXjhaw7evRoDw+POnXqdOjQwfYVb968KQ+tYcOGstbUqVN145zW ztoO1aWduttJSkoKCQmRmdIP169f11pl+Yhs71vLB2XtUQDg1AigKu0yzvF5X4A4ZzAOqDgnAUDC Q40aNT7//HM1Pzg4eMyYMRIYli9f7ufnJ3OysrL69Okzfvx4WTg7O1vm+Pr6Ll26VC2/aNGi9u3b q9uBgYGurq4LFixISUnJy8uTu02bNp04ceKJEyckZkRERFg2Q5Zp1qzZwoULjx07JvmkUaNGubm5 lpuSBgQFBZ0s0Lt37379+uk2zLLxaqa3t/eWLVsePHjw/fff275i3759Q0NDL168eOXKFUlZunFO a+fmiX+WdupuR6KsJLH8/PwLFy5oH1PUfUS2963lg7L2KABwagRQlXYZ5wAQ5wxInHN2dnZ0dJQe 2LFjh5p57tw5uRsfHy8ZIzk52cnJKS0t7SeLtyYaRI6xY8eaRp2oqCh1e9WqVZ6enrpx6OWXX1a3 09PTZe8HDhww29T58+dlvrqM9lPBl7jI3R9++MGsYbqNVzOlkWb7LXTFS5cuyUzJS2oZa2+2NG2n td7r0aOHioXaWgaPyJa+1X1Q1vYOAACIcwBxrhLGudjY2OvXr7do0WLChAlqZkJCgnRI165dn/3F vn37HinOSZeaRh3t7tq1a5s1a6Ybh0xXadKkyZIlS8zmq1alpqaqu1euXJG7e/bsMWuYbuPVzKNH jxrEOd0Vd+/ebbpTgzhn1k7L3pMgFxISUr169WnTpt2/f9/4EdnSt7oPytreAQAAcQ4gzlXCOKc+ Oye5pVq1aps3b5bbZ8+elQ7Zvn27QfhRkWPx4sXq9syZM0sqzt28eVP2LsHJbP6pU6dk/tdff63u btu2Te6eOXPGrGG6jVczV6xYYfCIdFdMS0tzdHRUlwptjHPWek+RtObq6rps2TLjR2RL3+o+KOO9 AwAA4hxAnKuEcU5MnjxZkoZ6b15QUFCvXr3UOwPv3r17584duREbGysztXUHDx4cFRWVnZ29Zs2a evXqFTPOBQcHZ2Zm5ubmzp8/v1GjRmqPpuvm5eV17Nhx+PDh8idZMjIyslOnTvn5+ZYN0228zPHz 8zty5IjcPn36tGzNxhVlp9HR0RkZGYcPH/b39y80zlnbzt69e3NycqTBAQEBcXFxxo/Ixr7VfVC6 e5fUJx1LsQMAYGdxjs/7AsS5Qr8KRd2+d+9emzZt+vTpI4lCQl1YWJiTk5O3t7ebm5t6B+Dx48db t27t5eWlPmWXmJjo4eHh7OwcERExb968Ysa5/v37P/XUU/JXiZTaBSuzTaWkpEjgkXjj4uLSpUsX dSHLsmG6jb969apsTZ7ohg0benp6qu8+sWXFLVu21K1bV2ZKcFq6dKlxnFNdrbsd2ZGs26JFi/Dw cOlq40dkY9/qPijdvYeEhLRt25ZiBzg1AqhKO4tzfBsvQJwrdBzIvpmpOz8rK+vatWtmMyVCqKtA Ijc3NzMzs/gtVClFYqRsXF2eMpCenq67U9OGWWv8rVu3LNctdMWcnBzLTRXa1ZbbuVPAxkdke9/q Pijdhw+AUyOAqiTOAcS5SjJK5mTdOzZjebxraLkPFGYXnTggAaBOAaqSOMeYBRDn9MeB64lHdnUf u86pq/xJTeXbwtWrV1eOH7xmyAWoUwDEOeIcQJwrlVHS9HKc2cTLgAMSQJ0CoCorXJzj874AcU7G AcvLccS5UupqOgGgTgFUwarkhwoA4lxpSd16wFqKY2JiYmJiYmKqCBNxDgBxzqrsm5mnF/1tS5vn 45uEftFsAFfnAAAAiHMAcc7OXE9MPjjy9fW1um9uNWh9ze7EOQAAAOIcQJyzJ5YX63gZAAAAVLg4 x+d9AeKcwTigLtYR58qgqwFQpwAqcVXyQwUAca60FDoOZN/M5GVQNl0NgDoFUCmrkjgHEOcYJelq ANQpQFUS5xizAOIc4wBdDYA6BahK4hxAnGOUBF0NUKcAqMpyiHN83hcoVExMjJRfYGDg7EpqfM8B s0FXA6BOAaqy1PTs2VPOJ0eOHFnCcQ5AoVT5AQAAAMURGBhInAPK2pIlS6T2Ro4cOQcAAAB4dHIm KeeTclZJnAMAAAAAu0ecAwAAAICqGuf4KhQAjAN0NQDqFKAq7TLO8W28ABgH6GoA1ClAVRLnADBK gq4GqFMAVCVxDgCjJF0NgDoFqEriHGMWAMYBuhoAdQpQlZUtzvF5XwCMA3Q1AOoUoCrtMs4BAAAA AIhzAAAAAADiHAAAAAAQ5wAAAAAAlS3O8XlfoPg+dejMVO4TT1DJdhrA6Ee9gxJmKu1aI84BFWU0 zM8/ylSOU6Fxji561E4DGP2od1DCTKVda7zZEmA0ZCLOcXoHRj8m6h2UcGWJc59++ul3332n3b10 6dLf/vY3XqwAoyFxjonTOzD6Ue8AJVzR41zLli3nz5+v3d2yZcuTTz7JixVgNCTOMXF6B0Y/6h2g hIlzABgNiXOc3gEUF/UOSpipbONcUlJSSEhIgwYNvLy8rl+/rmbeuHFj0KBBMtPHxychIUHNjI6O Xrx48bhx42T+7du3ea0DjIbEOQ45AMVFvYMSZirPONetWzcJafn5+RcuXHjw4IGaGRwcPGbMGMls y5cv9/PzUzMDAwNdXV0XLFiQkpKSl5fHax1gNCTOccgBKC7qHZQwU3nGuR49eoSGhl68eFH767lz 5xwcHOLj40+ePJmcnOzk5JSWlqbi3NixY3mJA4yGxDkOOQDFRb2DEmYquzjXpk2b1157Tbu7adMm CXjqtgS5kJCQ6tWrT5s27f79+zInISFB4lzXrl2f/cW+fftUnJs9ezYvcaCCj4Z5eckPHhwyWODh w8O5uUcYPUv8CaocHcvpHSry6Fd1hi/qHcQ54tz/07t37379+ml3V69eLSHNdIE9e/a4urouW7ZM bp89e1bi3Pbt2802QpwDSmo0lDOSLVuWTpoUNX/+pISElSU7ZKxf/2aDBnUNFggM/PXs2X8opQEr Pn7he+/9Saa//vWNfftW37iRULTtbNq05MiRT8olzq1Z8/rZs5vUbQnG8ljOn9+sPXErV74q/xa5 Y1X/fPDBnG+//VSCN6d3qILngqmpO6UK0tJ2FuH1Wczhq0QGlhLZSGkfCKh3lFIJa0f5HTtWZGcf tJc0Ve7lVgJxbt68eS4uLocPH5bbaWlpvXr1euWVV9Sf9u7dm5OTk5+fHxAQEBcXp2YGBQXJMuod mHfv3r1z5w5xDijB0bB//+4BAb5vvhn7u9+FDxkSrGZeurT1woUt9h7nOnf29fVtNWrUQHmMbdu2 cHausWTJtCJsZ9iw0IULp5ZLnOvR45lXXhmtbiclrXFwcJg7d4K6u3fv6jZtnixOx0r/tGvXul+/ Z+U5euIJ19u39xHnUNXi3IwZ/yllNWvWWFtekGYDYzGHr6INLGZtKJHRydqBgHpHBS9hdRSLjAzx 8nJ3cam1b99qu4hz5V5uJRDn7t27FxkZKaNny5Ytq1evHhwcnJGRof7UunXrBg0atGjRIjw8XBZT MyXyhYWFOTk5eXt7u7m57dmzhzgHlNRomJLyRbVq1a5e3WE2f8CAHlOmjKgEcW7q1N9pd5cvnyEj z8cfz7WjN1tK58ijULcXLJgsT5YcBtTdmTP/c+LEYcWMc9Onj5QbV65sf/zxImZdTu9gv+eCDx8e btq0cZs2T3p6utnytkmzgbFUhy8b21Aik7UDAfWOih/n1FFMpmee8Rk2LLTiZ7mKUG4lEOeU9PT0 5OTk1NRUs/l3Clgun5WVde3aNV7TQMmOhpcubXV0dFy1arbpzD//+Y+1a9eUGCZnOV98sVjmyIl+ 9+4dGjeuHxwc8M03H6nFoqP7y/zXX3/By8u9Wzd/bf6NGwnPPRfYsGG9Dh18JE1pcU53I6bnQzdv Jso23dwaubs3iokZcOvWbuMdXb++a9Cg3rJ9H5/mu3a9V2ick2ngwJ7t2rW2tvro0c+99dYUbeE/ /jFSEqBqQFzcdK2RspiHR5M6dWrLA7SxJUWOc3v2fODkVO3HH3++bhYe3n3IkGDpWPXGSDl0bd4c Z23v0rGzZo198cXfSn+2auUZH7/Q4ECYkbHHxaWWeq7lwS5aNHXcuCGyQdmv7pMSEdFr7do/q428 8ELkb37TS2ut+o/G/fs/DAnpIluQp+zata8Neslsd5zeoSzPBT///O0mTRoePLjWwcHhq6+WafOl 1j766P9e4R9++JoMaLoDoxq+LIcmg6HM9NWuDSySKmWbppMaFS3HTMs2mI1OjzSEGh8IbKnZESP6 646ZRSh26h3FjHMDBvSQQ7zBS1f3wGStanQHAd1D5KOeElSEciuxOAeggoyGr7wyWkaWkSMHah8t u3Nnf58+XcePf17GiPv3v5E5Gza89e23n8rt4cPDhg7towWGpk0bT5w47Pjx9TKUyCm+mt+3b7fQ 0K4XLmy5fHmbDIhanLO2ES3OyU6Dgjp///1nMvXu3alfv2eNdySnOGPGRMg49c47r/j5tbIlzi1c OLVGjcdyco7orv7BB3NatPBQYUl6o2ZNZ/WmJtNGylre3s0kR2VnHzxxYoONLSlynJO91Kr1uJy3 SaskyB069LGcd0r/yKFImnf37gFre5c2N2vm9vbb//XPf/5dDjaNGtVTj9qsf+S5kIOKHOEk+Kkv rZEVXV0bzJ8/6fTpjbm5R3SfFDl8qggnzZMtS+BUh0B5zcgpo9yQU0Y5kEibz5/frH2ewVo7TXfH 6R3KcvQLC/sPdS7YqdPTgwcHafN9fVtpGUkGjfbtn9IdGK0NTQZDmemr3XRgkW2qacWKmTJGqY/T WI6Zum0o8hBqfCCwpWZXrZqlO2YWodipdxQ5zkk5SPSSwvnss7cNXrq6ByZrVaM7CFi+jIt2SlDu 5UacAyrbaKg+TOzu3sjDo4n2vnNr7+dZvnyGjCbaYBEV1Vfdfv/9WZ6ebnLjhx+2St5QV42svdnS bCPqXOTcuU2yovr/ZtUkuXvx4lfWdnT27M/Lf/752zIEHznyiSSK1NSdhcY5CWzVqlWT0yDd1eVU qXbtmomJ78uSb701RXKpWSPVWmafVLGlJcX5ZkuVtSSV/epXLeWuPE3SCX/96xsy32Dv0uaXXx6l /e+jLJOUtMayf/z923Tp4ieD/ocfvqYOErLi2LGD1ALWnhTpojp1akv827r1HTn4yUbkiZYDhryK Tp78XH3kT0X6QnvJdHec3qEsRz95JcvrMCXlC7n93nt/euyx6tp/2Fs7k7N8s6Xl0GQ8lJm+2i3f q3no0Me1aj2+evUcgzHT2hs+H3UILfRAYEvN6o6ZRSt26h1Fi3POzjUkGhV8b+Jy48ON5YHJoGoM 4pz2Mi7OKUH5llvZxbmcrHupWw+cevPj47NXyr+X1u+SObymgdKIczLdurW7f//uNWs6y3hhecaw ceOigADfZ57xkal58ycsz0U++ujPzZr9fIogA42MLNqbwk3jnPFGdu16z3TFy5e3yd3du1dZ25Fa vmvXds8+215Ne/euLjTOvfrq79VZkbXVf/e78JiYAXLDx6f5hg1v6TYyOfn/fY+cLS0pTpybN2+i n1+rZcteHjduiNx9/vmQUaMG/va3/d58M9Zg72Znik2aNFy8+CVrb1ORo5fEszlzxpmtaO1Jefjw cL16LvLX8eOfX7Fi5ksvxfzhD4P37Png6ae91ZJyvJS0Wb2607RpMffufWN7Ozm9Q5mNfvLCq1+/ zsSJw2SSmpLX51/+8uKjxjlrQ1OhQ5nlXSlDOb2bOfM/jQdea2141CG00AOBjTVrOWYWrdipdxQt zsXGDr927Ws5sk+YMNT4oGztwKRbNQZxzuwQWbRTgvItt7KIc9k3MyXCbXDpITsznTa49Pxu6hL5 K69soMTjnDqZ0D5AYnrGcPr0Rhn+1P97rV49xzjOpabudHR01C4EaXGu0I2cPPm57H3nznfV/K1b 35G76j/OdXd05syXssC2be/Y/lUoDx4ckhF/8uTfGqwuI2Pt2jU3b46T8yrtNwC0Bqi11LvVtcmW lhQnzn3zzUfSpUFBndWXuCxaNLV1a6/GjesfP77eYO+mnXbjxs8/4CnPhcGnDuRAqMKY6YoGT8qQ IcHSt56ebnIglAVatvy5Y80OHnJQdHVtsHTpyza2k9M7lNnol5NzREaSSZOi3nnnFTWFhnaVMyQt zkmhad859EhxzsahzOzujz/uk50OHdpH+8kQa2OmtTY86hBa6IHAxpq1HDOLVuzUO4oW59RRLDHx /WrVqm3atKTQg7LpgcmgaqwNAqYv4+KcEpRvuZV6nLuemPxlszCV377yGZg8Ydrx2a9/N3XmtvaD 11XvIjPjG/dJ3XqAFzdQIqPh999/JoOg+tDUBx/MkbMH9StnsbHDe/XqpH16WOafO7dJotqIEWHa 1TZrpwgdO7aNju5/69buQ4c+9vdvo5YvdCO5uUdkxeHDw27f3peRsScyMqRTp6e1t//p7kgSjjRS vXEiKyvJ8nv2tTj3P//zjyNHPpHTNYlzmZl7DVaXPT75ZNMmTRpqPw9g1gBZxc+v1eHD/y23//Wv ePWW9EJbUpw4J+eddevWlvH60qWt6u1Yctv0hEx379Lm4OAA6UlZfd68iY0a1dPtHzkQyiFBXgZt 27ZQ35Np+mANnhR5tdSr59Kli5/cvn//m1q1Hpe7x479XftOFNmsLBkQ4Kt9Yaa1dhLnUPajn5z2 NW5c3/SHqtQXoqj/2B48OCgqqq+8sD/88DV5YWtncqYDo7WhycahzPSuFIuMTl27tlNXDIwHXmtt KMIQWuiBwJaa1R0zi1Ds1DuKE+dkmjz5t5LT1FsNdV+Blgcmg6qxNgiYvYyLcEpQEcqtdOOcZDl1 UU7CW8bRL8z2/ePJr3Z2GSp/XVe969VN+3h9A8UfDePjF8qJeJ06tVu39pJh8b//e56aL+flMsfL y13933BERK/HH6/xxBOuK1e+KsFAfSjf2inC5s1xEj+cnKrJGBcXN107Cyl0I6dPb5SRVMZNF5da khPU/5AZ7EhG7bCw/5AdeXs3c3NrpN4gYTbQy/mZo6NjzZrOEiynTBlhOqpaW/3VV38vq2g/3m3W gCtXtstd2WzDhvU8Pd3UtxEU2pLixDn1//Ha/83L0UiesjFjIowfiDRy2LDQp55qLt0lRzjtfx8t +0e0auX5wguRly9vszwGWHtSrl7dIb0kQVHd7dfvWdmXtpa8eOR5l/AcHt5dsrRxO4lzKPvRb+DA nmbvxJZJRgn1RqaEhJUeHk2cnWvIqDV37gTtTM5sYLQ2NNkylJne/cc/PpIylLquX7+OmlQzdMdM gzY86hBa6IHAxpq1HDOLUOzUO4oZ5+RY06bNk336dJXMo/sK1D0wWasaa4OA2cu4CKcEFaHcSjHO Zd/M3OgeKjs4+uLLeQ+t/vyL/FVdo7ufls5LHCj+aJibe+TMmS91fwJFxintC5Fu3kxUt7OykmQy fv+ARI60NJ3P/tqyEVkmI2OP7T+fcufOft19lerq6ek6jTTeVHHiXBEeyI8/7svOPihHNXkStbdv FXl61CdFJknOulcpH6nDOb1DqY5+BlNOzhFrr3nTgbFkq8b2MdOgDUXbr8GBoMhj7KOuSL2jZI+P lq9Aawcm3aoxGASKeUpQ7uVWinHu2J9WqOtyOfcOGTdix68jZcnvpi7hJQ6U9mjIVL4/I06nUbxg 9KPeQQkzVcSfETeTk3VPvc3S8j2WltOPJ79aV73rBpeeDzPv8CoHGA2JcxxyAIqLegclzFSece7q pn2y6a2+ETa2Y8evf/4Q3aX1u3iVA4yGxDkOOQDFRb2DEmYqzzh36s2PZdPJE6bZ2I7vps6U5WUt XuUAoyFxjkMOQHFR76CEmcozzh2fvVI2fXz26za2Q5YsWH4lr3KA0ZA4xyEHoLiod1DCTPZ1de5P XJ0DGA2JcxxyAEY/6h2UMJM9fnZuGJ+dAxgNiXMccgBGP+odlDAT32wJMBoyEec4vQOjHxP1DkqY WitSnPvp59+de1f97pzBb4iraWeX3/K7c8CjjoZM5T7xBJVspwGMftQ7KGGm0q61R4hz2TczN7r3 kx0cffFlg0R39MUZskx84z7309J5iQMAAABAKXF4pKWvJyZvcOmprtFZvuvyx5Nf7ewSJX9dV73r 1U376FwAAAAAqChxTiW6+MZ91HXArb4R+4eM29VzxD+GvrDj10PXP/6sui5HlgMAAACAChfnfip4 1+WxP72rLtOZTjLnu6lLeI8lAAAAAFTQOKfkZN27umlfYshECXK7+0y8tH4X32MJAAAAAHYQ55Tj s1dKnDsx5326EgAAAACIcwAAAAAA4hwAAAAAEOeIcwAAAABAnAMAAAAAlEKcu56YLFGt0GlXz3ES 5xICx9my8I3dyfQ4AAAAAJRunFOX3Up24iIeAAAAAJR6nLuxO1nSV6FTQqC6OjfeloW5OgcAAAAA pR7nbMRn5wAAAACAOAcAAAAAIM4BAAAAAHGOOAcAAAAAxDkAAAAAAHEOAAAAAIhzxDkAAAAAIM4B AAAAAIhzAAAAAADiHAAAAAAQ54hzAAAAAECcAwAAAAAQ5wAAAACAOEecAwAAAADiHAAAAACAOAcA AAAAxLmiO/zCXyTOHfnjm3QlAAAAANhNnMu9l72+Zg+Jc/Kv3KY3AQAAAMAO4lx+Xt7+iGmS5T6t 1kX+ldsyhw4FAAAAgIoe576NXSQp7vMGQVe37Jd/5bbMoUMBAAAAoELHuZSlf5f89vcaz97YnSx3 5V+5LXNkPn0KAAAAABU0zl39cu+6gjdYXvx4qzbz4tqvZM46py7yV7oVAAAAACpcnMs4cmpD7Z6S 3L5/4wOzP514fZXMl7/KMvQsAAAAAFSgOHf3YtpG936S2Q6Oel13gYMjX5e/yjL/80ManQsAAAAA FSLOPfwxa+vTwyStJQZPyHuYo7uMzE8M+qMsI0vK8vQvAAAAAJRznLM9p/079QX90VrqAwAAAACU UZxT76L8ommYLe+ilGX+7z2ZI1+niwEAAACg3OJcEb7jRPvGFFmXXgYAAACAcohz//4Fgk37HmnT P/+egVPB7xms/YqOBgAAAIAyjXPXE3/5ffBl64uwdbNfGwcAAAAAlEWcu33qwucNgiSPfRu7qMg7 kHVlC7Id2RrdDQAAAAClHufuX8/Y1OI3ksT2D5qen5dX5B3Iuvsjpsl2ZGuyTXocAAAAAEo3ziVF zpAMtjNgVO697GLuQ7awo/Mo2Zpskx4HAAAAgNKNc/evZ0j6KqnraSW7NQAAAACAA10AAAAAAMQ5 AAAAAEAZ+V+/oSf1RBDk+gAAAABJRU5ErkJggg== --00c09fa21bcdfaf6a3048cdd0a05 Content-Type: image/png; name="device-w-input.png" Content-Disposition: attachment; filename="device-w-input.png" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gcdrtcqy6 iVBORw0KGgoAAAANSUhEUgAABLYAAANgCAIAAAC+xHZ+AAAANXRFWHRjb3B5bGVmdABHZW5lcmF0 ZWQgYnkgaHR0cDovL3BsYW50dW1sLnNvdXJjZWZvcmdlLm5ldDpnVRsAAAI2elRYdHBsYW50dW1s AAB4nJVTXW/aQBB8969Y5SmRYmLTAKpVVSWUqolCE9lAqrxUx3kRp9h37nkNIr++e7YJ0NJKfbJ8 OzM7+/WpJGGpyjNPSDIWZiVar+AnJVUhNMFZQkKnIjMa4TOulcQzECXEo2PUEy7gxpoN0+v4bHgc H1a0Mla9ClJGQ4J23QJd4PkYG2NpKivxEBYnHinKdh7gSdEKbnVREUyQpVPPOQf/IzuLYCpesASu yCWjlSCw+LNSFpt8b0a8eOQojhrBI4eR85cqLzjRLL5/02wBq22ppMiyLeRmjUAGBEiTswmGbZwj ARtuxKJpRGfPH0YwV6WiRnXo3urCI3goUO9eP/i7150X9/vtGZTmDEshsVFknFP8N6hNuwNJiyl/ lci4MToFwST3LwXhsaO3PlSLXBFhCktjc0gFCVhakzc7UoMPWHO0armtpUteJGxcwVUT/519slhx tCPSpHgJKQ9NElSuIu53M/2TXfhPdrsptzqtW1DPMUNXbbM2l1D8VbhdmxOz2uNGLW5fZoxUWQ1D KbEsYWpeUHuZMUWrFicRfEGSK05siG2zFbu7hM3VIa3TCjtKq/onp+OhTj3vMeObmk3ugS+pdMZ6 QX9wnvBJ3FUZhAMIr6NeEHVDGI2TKXSDMLjw7sRanE8nF5CMIa54S3KEsV4ra3TOpdZx+GooKQzV uP61f8Pb3RwszCde2Ol3gh/dwF8EXb87eO+HweRd0O95EyHhIYHvvwCY5X7KXjWWUwAAgABJREFU eNrs3Ql8TWf+x/FstW9BxJJEkxC0ougQy9izjLW1NKSo1qhBqxqjFC2tjmWm04owmFBM081YYgmK NiQaf1taU1vFWioR0oTERCKL/2887Zk7dzm5iUS2z/t1Xl7nnnvuc8753fs893yde29s7gMAAAAA 8IANJQAAAAAAEBEBAAAAAEREAAAAAAAREQAAAABARAQAAAAAEBEBAAAAAEREAAAAAAAREQAAAABA RAQAAAAAEBEBAKXNl19+uX79+uzs7BLc0NSpU4cNG5aRkVHuq/2QRxoZGSkP3759O69bAAAREQDw i9atW9v8qlq1at7e3jNnzkxLS3uY1gr9cNGnTx9p4erVq+pm27ZtbW1tU1JS1M1mzZq98847+huy ch/UahcvXiyRgterV+/evXvawieeeEIWjhkz5lFWe/HixfLwDz74gF4AACAiAgD+J2bs3LnzyJEj mzdv7tu3r9yUhZmZmYVo7fLly2fPns3NzS30/ixYsEB2YN26dTIvydDOzk5uqitdFy5ckPmDBw8a bSgoKKhKlSrnzp0rPRHRaJfMZvKtW7eqJUePHlVL8o2IhTtSIiIAgIgIAChYRNSSUl5eXvPmzWVJ aGio3Lx69eqQIUPq1q3buHHjN954Q32wc86cOS1atNi0aZN6iAS5J598cv/+/TI/cOBAuevOnTsy n5SU9Pvf/97Nza1atWqtWrX69ttvLTVo6NChQ7L1UaNGybyEqEqVKsnN6dOny83ly5fXqVMnJyfH cEMhISHSvqzj4eGhVlNH9N133/Xq1atBgwZTpkzJ98BVa//6179MH6Luio2N7dy5c+3atWXntUua 3bp1k0bUvOyGrKZSn+kuGW23TZs2En2fe+45teTVV1+VAhpGRLNVKtCRJiYmjh49Wh4u+9yjRw+V q1XM7t27d82aNTt16vTCCy8QEQEAREQAgF5EFJMnT5YlY8eOvXfvnkS7WrVqbdiwITg4WBZ+9NFH skJ0dLTM9+zZU60vYdLZ2Vl9bFK7riWppl27djIfGBgowUlySHx8vKUGDUkClBUaNWok87LOsGHD 5KbEM7n5zDPPSHAy3G3Z0JkzZyRxyfzKlStVClV3eXl5vfbaa5KmZP7w4cP6B67zEHWXbGLatGnN mjWT+T/96U/qLtnJxx57TM2/9dZbcld4eLjMm+6S0Xb79esn1atSpcqtW7eysrLq1au3cOFCLSJa qpL1RyrFf+qppySFSpj/5JNPZD8rV64sD8/NzVWfaJ06dao04urqSkQEABARAQD5RMSwsDBZItls 586dMvPss88mJCQcP35c5gcMGKDWkVhia2srqU/mvb29tWtlWnLbvXu3zHh6ehpuS6dBQwMHDpS7 Tp8+3b59+2XLlvn7+1eqVOn27ds1a9aUYGO0ofu/fn3R6OOXe/fulXmJczIfEhJiTUQ0+xB114kT J2Q+Li5O5rt06aIfEU13yTQiqiKvXr1606ZNTk5OEvm0iKhTJSuPVBVfqqdWk6AoN1999dUDBw6o SKmW80FTAAAREQCQf0RUaWfmzJnLly+XmcqVK9f+VY8ePdQ6ixYtUp//PHz4sMycPXvWKLmpx770 0kuG29Jp0JDkHFlt3rx5dnZ2//rXv9599125qf7V9jPfiKjuUilI/rUmIpp9iOFdmZmZMi+xMC8v 7yEj4s8//yyPlcMfNGjQ5MmTv//+ey0i6lTJyiNVLYwbN06ttmXLFrkpG/34449lJigoiIgIACAi AgCsioh37txxcXGRJQcOHNixY4fhRTNDiYmJDg4ODRo0kFTTvXt3o9YktGzbtk1mWrRoYfgonQYN nThxQlZzfCA3N3fv3r1yU5JSs2bNTDekBaczZ84Ud0RUVxHd3NzUXRIR7e3t1RcFJXeZRkRtl0wj 4v0HF0ttbW2ljEeOHDGMiDpVsvJIVfG7du2qVvvLX/4iN8ePH6/2v2PHjmr53LlziYgAACIiAMBM UlqxYsU///nPP//5z56ennLzD3/4g9yVkZGhfrpm1qxZki6++uorw68OPvPMM+p3OLVcZBhaJGo2 bdpU5oODg0+dOiUx79KlS/oNGpLwqX3AMj09XZKY3Jw0aZLZiCityfzs2bMluBZTRHzllVe+++47 9QnYGTNmqLv8/f3l5pw5c37/+99Xr15d5j/++GN1l9EumY2In332mZaiDSOiTpWsPFJV/EqVKsn+ HDt2zNvbW7JobGxsXl6exFoJpdOnT583b56kbiIiAICICAAwk5SUunXr/va3v/3HP/6h3RsfH9+r Vy8JGHJvlSpV+vfvr921fft2WVinTh3DP91uGFpOnDjRsWNH7S8u7t69W79BQyNGjJAVJLKqm23b tpWbW7ZsMbuhc+fOyYakTdn5YoqII0eOtH3g2Weflciq7tq5c2fjxo0lvsreSugyTMtGu2Q2Iv77 3/9et26d+q1Rw4ioUyXrj1SK36FDB1X8hg0bShxVy+XJlQbVNUb12V0iIgCAiAgAKBgJgVeuXCnc Xzu8ffv2tWvX1Jf3iqRBS27evFm4v+VoTYROeyA1NdXo3uzs7Fu3bhXTLlmqkvXNyr5dv37daGFW VtaNGzd4VQMAiIgAABQ+IlIKAAAREQCAim7ZsmVz5szJysqiFAAAIiIAAAAAgIgIAAAAACAiAgAA AACIiAAAAAAAIiIAAAAAgIhICQAAAAAAREQAAAAAQBFFxOz0jIRdB8+8/8mJuWHy75UNX8sSCgoA AAAAFSsiZt5MlVi4sUb3L2w6Gk4ba/Q4Pm2J3EtZAQAAAKBCRMSkfXHbXPqpTLiz5aC4V6efmDvv +LTZX7Ydut6hkyyMqO+fsOsglQUAAACAch4RJR+qi4cSCFO+3ZqX963hdOv0zr2dhsu96x06X9t+ gOICAAAAQLmNiJk3U7c0DJAE+O3rb+beO2aUD7VJ7lXXEu8mJlNfAAAAACifEfH7t1ao64fZGUcs 5UM17flNoKx5fNoS6gsAAAAA5TAiZqdnqI+Ymn6+1HS6dXrneofOG2v0uJeaRokBAAAAoLxFxGvb D0g+3NV6cL758NcLif/5UuKVDV9TYgAAAAAobxHxzPufSOSLe3W6lRHx+LTZsr48ihIDAAAAQHmL iCfmhknkOzF3npURUdZ8sH4YJQYAAACA8hYRC34V8S2uIgIAAABA+YyIBf8u4gi+iwgAAAAA5TMi 8oumAAAAAEBE/K/v31qp/i5i7r1j+hFxb6fn+buIAAAAAFCeI2LmzdQtDftK9vv29Td1UuK3r8+S dSLq+99NTKa+AAAAAFA+I6JI2he3sUYPdS3R9BOnt07v3NspSO5d79D52vYDFBcAAAAAynNEVCkx or6/5ED16zXfDJvwdY9R/zd80p7fDN9Qpau6fkg+BAAAAIAKERHvP/jE6fdvrVSXEw0nWXJ82hI+ XwoAAAAAFSgiKtnpGde2H9jnN1nC4X7/yVc2fM3vlwIAAABABY2Iyom5YRIRT76zilICAAAAABGR iAgAAAAAREQiIgAAAAAQEYmIAAAAAEBEJCICAAAAQIWMiEn74iT+5Tt93WOCRMSonhOsWfnG/jgq DgAAAABlLyKqy4NFO3GxEQAAAADKZES8sT9OEl2+U1RPdRVxojUrcxURAAAAAMpkRLQS30UEAAAA ACIiEREAAAAAiIhERAAAAAAgIhIRAQAAAICISEQEAAAAACIiEREAAAAAiIhERAAAAAAgIhIRAQAA AICISEQEAAAAACIiEREAAAAAQEQEAAAAABARAQAAAABERAAAAAAAEREAAAAAQEQEAAAAABARAQAA AACPOiIenfQXiYjHXnmfUgIAAABAhY6IORmZG6p2l4go/8o81QQAAACAChoR83Jzvxk8XfLhF3ad 5F+ZlyUUFAAAAAAqYkT8LnixJMPNjn2u7fhG/pV5WUJBAQAAAKDCRcT4pf+UTPjPSl1v7I+Tm/Kv zMsSWU5NgUfpP1fymUp64gkq2qIBDIwMBaALM5VgXytMRLy2LWb9gw+XXv5kl7bwcvhOWbLevpPc yysbeJTDaF7et0wlOOUbESlRQYsGMDAyFIAuzFSCfa3AETHl2JmN1XvIZk6995HRXSfnrZblcq+s w4sbYBhl2OUJ4rwQDIxMDAWgC5fziHjncuKWhn1lG4dfmmd2hcMvzpN7ZZ1//5jI6xtgGGXY5Qni vBAMjEwMBaALl9uIeO9W+q4nR8gG9vm+mnsv2+w6snxfn1dkHVlT1uclDjCMEhEpEeeFYGBkYigA XbgcRkTrs99/k2SfVywlSQAMo0REigYwMDIU8HIFXbgMR0T1CdKtjfpZ8wlSWeeXz6O+OI9XOcAw SkRk4rwQDIxMDAWgC5eriFiI36HRftVGHssLHWAYJSIycV4IBkYmhgLQhctJRPzvX7PYfqBATf/n b2PYP/jbGOE7ea0DDKNERCbOC8HAyMRQALpwmY+ISfvi/lmpqzQav2xDIZ7g+KX/lMdKCzf2x/Fy B8rTMJqbG5eVdURnhXv3jubkHGPYLfInqHwUlvNClNGBseKMbAwFICISEc27febSZsc+0uJ3wYsL /RzLY6UFaUda4xUPPMphVE5lduxY+tprQQsXvhYVFVa0Y82GDe87OtbSWaFnz9/MnfuHYhrpIiI+ /Pvf35LpH/9478CBNTduRBWune3blxw79lmJRMR16+adP79dzUvYlmO5eDFSe+LCwt6WfwtdWFWf jz5657vvvpAwz3khGBgNp4SEvdJBEhP3FuKl+5AjW5GMOUXSSHG/RzAUoJi6sHYCsGfPiszMw2Ul oZV4dyuyiHg3KWW7+7PS3DdDZuTl5hb6OZbHfjN4urQjrUmbvOiBRzaM9u/fzcen9fvvB7/wwoBh w3zVwitXdl26tKOsR8SOHVu3bt3spZcGyTG2auVeuXKlJUumF6KdESMCPvxwWolExO7d28+cOVbN x8aus7GxmT//VXUzJmaNl1fThyms1KdNm+Z9+3aV56hxY6fbtw8QEcHAqE2zZv1eetycOeOtea0a jZkPObIVbswx2ociGbgsvUcwFKCUd2H1BhcY6Ofm1rBGjWoHDqwpExGxxLtbkUXE2MBZ0tZen5dy MjIf8mmWFvZ0fElakzZ50QOPZhiNj99qZ2d37doeo+UDB3afOnVUOYiI06a9oN1cvnyWnPB98sn8 MvRBUymOHIWaX7RoijxZ8v6hbs6e/fvJk0c8ZEScMeNFmfnpp91VqhQyP3NeiHJ5fnnv3tFGjep7 eTV1dXW25iOjRmNmsY5sVu5DkUyW3iMYClD6I6J6g5OpffuWI0YElP58WBq6W1FeRZREV1TX/Yq2 NQD5DqNXruyytbVdvXqu4cI//emV6tWrSrST06OtW0NkiYSHbt3a1a9fx9fX59Chj9Vqo0f3l+Xz 5k1yc2vYpctT2vIbN6KeeaZn3bq127VrKQlNi4hmGzE8kbp5c5+06excr2HDemPGDPz55/36G0pK +nrIkN7SfsuWj3/99d/zjYgyDRrUo02b5pYePnbsM3/961Rt5VdeCZRUqXYgNHSGtpOyWpMmDWrW rC4HaOWeFDoiRkd/ZG9vd+vWf67vDRjQbdgwXyms+lCovOdFRoZa2roUds6c8a+//rzUs1kz14iI D3XeQVNSomvUqKaeaznYxYunTZgwTBqU7Zp9UgYP7hUe/ifVyKRJgc8+20vbW/W/nt98s9bPr5O0 IE/Z9etf6VTJaHOcF6KUnF9u3vxBgwZ1Dx8Ot7Gx2blzmbZcuuHHH//y4l+79l0Z68yOmWpkMx21 dEY5w46gjTmSVKVNw0kNmKbDqek+GA1cBRpd9d8jrOnOo0b1NzucFmIcYCjAQ0bEgQO7y7u/zkvX 7HuWpV5jdhAw++5Z0LOF0tDdiuvvIgIoc8PozJljZUh68cVB2lf10tK+8ffvPHHiczK43L17SJZs 3PjX7777QuZHjuw3fLi/FkIaNao/efKIEyc2yBgksUEt/93vugQEdL50acfVq1/KSKpFREuNaBFR NtqnT8dTpzbJ1Lt3h759u+pvSM6Nxo0bLAPc3/4209u7mTUR8cMPp1Wq9Fh29jGzD//oo3fc3Zuo ACbVqFq1svrUluFOyqM8PV0km2VmHj55cqOVe1LoiChbqVatipzwyV5JODxy5BM5YZX6yHuY7N6d OwctbV322cXF+YMP/vivf/1T3qXq1autjtqoPvJcyLuRvDVKmFQ/LCQPdHJyXLjwtbNnt+TkHDP7 pMj7roqFsnvSsoRY9d4prxk515QZOdeUdyDZ54sXI7UvgVjaT8PNcV6IUjIw9uv3W3V+2aHDk0OH 9tGWt27dTMtdMp60bdvC7JhpadTSGeUMO4LhmCNtqmnFitkyfKmvJ5kOp2b3odCjq/57hDXdefXq OWaH00KMAwwFKHRElO4gcU46zqZNH+i8dM2+Z1nqNWYHAdOXceHOFkq8uxERAYbR//lWd8OG9Zo0 aaB9WN/SB5aWL58lw5A2ygQF/U7Nr1o1x9XVWWZ+/HGXZBh1dcvSB02NGlEnMRcubJcHqv/8Vrsk Ny9f3mlpQ+fP/2f9zZs/kLH72LHPJKUkJOzNNyJKCLSzs5PzJ7MPl3Os6tWr7tu3Stb861+nStY1 2kn1KKOv91izJw/zi6Yqv0nSe+IJD7kpT5MU4R//eE+W62xd9vnNN1/S/itU1omNXWdan6ee8urU yVveLdaufVe9u8gDx48folaw9KRIiWrWrC6Rcteuv8m7pjQiT7S808ir6PTpzeorlOq/CfKtkuHm OC9EKRkY5UUuL9H4+K0y//e/v/XYYw7ahQVLZ4emHzQ1HbX0RznDjmD6OdUjRz6pVq3KmjXv6Ayn lj7sWtDRNd/3CGu6s9nhtHDjAEMBChcRK1euJHFLXnK7dy/Xfycyfc/S6TU6EVF7GT/M2ULJdjci IsAw+j/Tzz/v79+/W9WqlWWgMT3V2LJlsY9P6/btW8r0+OONTU9iPv74Ty4u/zm3kBFKhiTtk/SG EVG/ka+//rvhA69e/VJu7t+/2tKG1PqdO7fp2rWtmmJi1uQbEd9++2V1OmXp4S+8MGDMmIEy07Ll 4xs3/tXsTsbF/c+PBFqzJw8TERcsmOzt3WzZsjcnTBgmN597zu+llwY9/3zf998P1tm60SlmgwZ1 Q0LesPQ5HHnbk8j3zjsTjB5o6Um5d+9o7do15N6JE59bsWL2G2+M+cMfhkZHf/Tkk55qTXmjlQTr 4GA/ffqYjIxD1u8n54UoDQOjvCbr1Kk5efIImaS7yUv3L395vaAR0dKole8oZ3pTeqicMs6e/Xv9 MdnSPhR0dM33PcLK7mw6nBZuHGAoQOEiYnDwyOvXv5I3/VdfHa7/fm3pPctsr9GJiEbvnoU7WyjZ 7lYEEfGLL744fvy4dvPKlSuff/45L1agjEZEdRaifevG8FTj7NktMm6q/4Rbs+Yd/YiYkLDX1tZW u2ClRcR8Gzl9erNsfe/elWr5rl1/k5vqf/HNbujcuW2ywpdf/s36n6vJyjoibxVTpjyv83AZUqtX rxoZGSonZNrfk9B2QD1KfcRfm6zZk4eJiIcOfSwl7dOno/qhncWLpzVv7la/fp0TJzbobN2waDdu RMk68lzofFVD3kFVwDN8oM6TMmyYr9TW1dVZ3kFlBQ+P/xTW6F1H3k2dnByXLn3Tyv3kvBClYWDM zj4mg8xrrwX97W8z1RQQ0FnOurSIKH1Q+8moAkVEK0c5o5u3bh2QjQ4f7q/9ZRpLw6mlfSjo6Jrv e4SV3dl0OC3cOMBQgMJFRPUGt2/fKjs7u+3bl+T7fm34nqXTaywNAoYv44c5WyjZ7lYEEdHDw2Ph woXazR07djRt2pQXK1C2htFTpzbJ6Km+hPbRR+/IaYf6K3zBwSN79eqgfY1bll+4sF3i36hR/bSr gpbOLZ5+utXo0f1//nn/kSOfPPWUl1o/30Zyco7JA0eO7Hf79oGUlOjAQL8OHZ7UPvpodkOSmmQn 1SdD0tNjTf9mgxYR//3v/zt27DM5z5OImJoao/Nw2WLTpo0aNKir/akJox2Qh3h7Nzt69FOZ/+GH CPU5/nz35GEiopyw1qpVXQb6K1d2qc+bybzhmZzZrcs++/r6SCXl4QsWTK5Xr7bZ+sg7qLyXyMug VSt39fuohger86TIq6V27RqdOnnL/N27h6pVqyI3v//+n9rv1kizsqaPT2vth1It7ScREaVqYJRT yfr16xj+ITX1ozXqP+CHDu0TFPQ7ec2vXfuuvOa1s0PDMdPSqGXlKGd4U/qRDFydO7dRVzb0x2RL +1CI0TXf9whrurPZ4bQQ4wBDAR4mIso0Zcrzkv3UxyzNvgJN37N0eo2lQcDoZVyIs4XS0N2IiADD 6C8feZeT+5o1qzdv7ibj6aefLlDL5Vxflri5NVT/UT14cK8qVSo1buwUFva2hA316wiWzi0iI0Ml 0tjb28ngGBo6Qzt9ybeRs2e3yBAsA26NGtUke6j/rtPZkAz3/fr9Vjbk6eni7FxPfQLE6B1CTuxs bW2rVq0sYXXq1FGGw7Glh7/99svyEO0P1hvtwE8/7Zab0mzdurVdXZ3Vz0LkuycPExHVxQHtQoG8 jclTNm7cYP0DkZ0cMSKgRYvHpVzy1qj9V6hpfUSzZq6TJgVevfql6ZuHpSfl2rU9UiUJn+pm375d ZVvao+TFI8+7BPIBA7pJPtffTyIiStXAOGhQD6MPqMskA4j6EFdUVFiTJg0qV64kA9r8+a9qZ4dG Y6alUcuaUc7w5v/938fSQ6XL16lTU01qN8wOpzr7UNDRNd/3CCu7s+lwWohxgKEADxkR5W3Iy6up v39nyVFmX4Fm37Ms9RpLg4DRy7gQZwulobsVb0SMjY318/NzdHSUgSopKUktvHHjxpAhQ2Rhy5Yt o6Ki1MLRo0eHhIRMmDBBlt++fZvXOvDoh9GcnGPnzm0z+3d4ZIDTfu3q5s19aj49PVYm/Q9ISIxJ TDTzJWxrGpF1UlKirf8bPmlp35jdVrE+PDnZzE7qN/UwEbEQB3Lr1oHMzMPydihPovb5tEJPBX1S ZJI0bvZqaoEKznkhSmpg1Jmys49Z6g6GY2bRdijrh1OdfSjcdnXeIwo9/Bb0gQwFKNq3TtNXoKX3 LLO9RmcQeMizhRLvbsUbEbt06SLBLy8v79KlS1lZWWqhr6/vuHHjJAcuX77c29tbLezZs6eTk9Oi RYvi4+Nzc3N5rQOlbRhlejR/jpYniPNCMDAyMRSALly2+lrBImL37t0DAgIuX76s3XvhwgUbG5uI iIjTp0/HxcXZ29snJiaqiDh+/Hhe4gDDKBGREnFeCAZGJoYC0IXLdkT08vJ69913tZvbt2+X0Kjm JRz6+fk5ODhMnz797t27siQqKurB76527vqrAwcOqIg4d+5cXuIAwygRkRJxXggGRiaGAtCFy3ZE 7N27d9++fbWba9askeBnuEJ0dLSTk9OyZctk/vz58w/+cuVuo0aIiADDKMMuTxDnhWBgZGIoAF24 PETEBQsW1KhR4+jRozKfmJjYq1evmTNnqrtiYmKys7Pz8vJ8fHxCQ0PVwj59+sg66tOnd+7cSUtL IyICDKMMuzxBnBeCgZGJoQB04XISETMyMgIDA21sbDw8PBwcHHx9fVNSUtRdzZs3d3R0dHd3HzBg gKymFkqM7Nevn729vaenp7Ozc3R0NBERYBhl2OUJ4rwQDIxMDAWgC5eTiKgkJyfHxcUlJCQYLU97 wHT99PT069ev85oGGEYZdnmCOC8EAyMTQwHowuUwIgJgGGUiInJeCAZGJoYC0IWJiAV2Ym4YL2Wg BIdRphKfeIKKtmgAAyNDAejCTCXY12yK5FnkpQyAAYRSA6ALA/TKcoCICIDhlVIDoAsDoFcSEQEw vFJqAHRhAPRKIiIAhldKDYAuDIBeWVwRkZ+rAcAAQqkB0IUBeiUREQAAAABARAQAAAAAEBEBAAAA AEREAAAAAAAR0Qp8fxoAAwilBkAXBuiVRMRf8CvMABhAKDUAujBAryQiMmYBYACh1ADowgC9kojI mAWA4ZVSA6ALA/RKIiJjFgCGV0oNgC4MgIioh+9PA2AAodQA6MIAvZKICAAAAAAgIgIAAAAAiIgA AAAAACJiscvOzs7NzS2vVS7fR0e5AAAAACLif5n9puZnn30WZs6dO3fMNtKzZ8+5c+eWeDkiIyPj 4uKKvNlScnSP8pATExPl6b5+/fqjL1eRHFExlQVWDiCg1ADowgC9sgxHRLO/9zpt2rSxD7Ru3drJ yWnsr1JSUkpViLp69erly5e1myNGjFi8eHGRN1ugozN6bHErqkM2MmvWLBsbmzlz5hR3uYrqiIrp lYDCDSCg1ADowgC9srxFRM3UqVM7deqUbyMlFREHDhwoe1jczRbo6Ipplx6l7OzsRo0aeXl5ubq6 WvOR0YcpVyl/JYCTHkoNgC4M0CuJiPlExNDQ0G7dutWvX9/X1/fw4cNGqeDWrVsyv379erX8xo0b Q4YMcXR0bNmyZVRUlFoYGxvr5+cnC93c3JKSkkw3anYTycnJY8eObdKkSc2aNdu1aydL5s+fX716 dWlHwsy2bdtkyejRo5cuXaqtLzednZ0bNmw4ZswY7fqnLJT233vvPdl6ly5dtPY1ps2qozN9iOl+ mj7WkGw6JCRkwoQJssLt27fNFufmzZvPPPNM3bp15RjfeeedDh06qOUDBgwIDw9X8+vWrZN1tDa1 Q7am/XyLLyIiIho0aHDkyBEbG5tdu3Zpy83ug/Xl0nlGDHdbOyJJql7/SwpiZdmL5JUATnooNQC6 MECvJCLmHxE3bdp0/PjxzMzMkSNHDh8+3DAiZmVl9e7de+LEidrKchI/btw4Oe9fvny5t7e3Wiin 4xIJ8vLyLl26JA8x3ajZTUhTnp6eO3bskIecOnVKlqSnp/v7+8vmJAvJyvf/9/qV3NWnT5/TD8he 9e3bV9vVRo0aTZ48+eTJk5KgBg8ebLR1s82afYjpfpo+1pC04+TktGjRovj4+NzcXLPF+d3vfhcQ EHD58uWffvpJIpnEHrW8devWWuZZvHhx27ZtjcK5le3nW3zRr1+/GTNmyIwE1KFDh2rLze6D9eXS eUYMd9vwiG78auXKlZUqVdq3b5+VZS+SVwI46aHUAOjCAL2yIkZE/W9q6nzQdMWKFe7u7trZ9pw5 c0aNGtW/f/+cnBy18MKFCzY2NhEREXJqHhcXZ29vn5iYKMu7d++uUlC++6ZtQjVl+u0ySx9xvHjx oqyvXcfbsmWL3Pzxxx/VOkFBQWr56tWrXV1dTbdr2qz+QwxLofOJR2ln/PjxOsW5cuWKLJQYrNbZ uHFjQSOifvvWFF+qJCufO3dO5sPCwh577DHtYqOlfbCmXPrPiLbb9819TvXo0aPVqlVbu3at9WUv qlcCHnIAAaUGQBcG6JVlLyLqM42IW7du9fHxaf/A448/rp2Ry2py8h0bG6utGRUVJUs6d+7c9VcH DhyQ5ZJP/Pz8HBwcpk+ffvfuXdONmm5CNfXtt99aGRHV+gkJCWr5Tz/9JDejo6ONEkh4eLiLi4s1 EdHsQ8yWQj8iau2YLc7+/fsNd7sQEVG/fWuKLy3UqVNn8gMvvfSSNPL+++8XNCKalsvKZ8T0psS5 hg0bzp49W/8VWEyvBAAAAICIqBcR4+PjJV3s2bNH5teuXWsYEeVse8qUKXI2f/78ebVQZuR0fPfu 3WZbltN0JyenZcuWGS03uwnV1IoVK6zMcmfOnJH1v/rqK7X8yy+/lJvqylhRRURLpbAyIpotTmJi oq2t7cGDB81GxJCQEDUveSnfiFi44ufk5MjRvfbaa8t/FRAQ0LJlS/19sKZcVj4jRjdv374tGx0+ fHheXp7+K7CYXgkAAAAAEVEvIsbGxsoJ+sWLFyXMjBo1Sgsw6mxbzuNHjx7t4eGhPtMo+vTp06tX L/Wxxjt37qSlpclMTExMdna2rOzj4xMaGmq0RUubkHa8vb2PHTsm82fPnlW/tBkcHCzLTYOB3Pv0 00+PHDlStpiamhoYGNihQwcVM6wJBpaaNXyIpf00eqyliGipOLLbUsOUlJSjR48+9dRTWrNDhw4N CgrKzMxct25d7dq1842IhSt+ZGRk/fr1Db+jqH60Rl2BtLQP1pTLymfE8KbspwTUzp07G17ttLLs RfVKAAAAAIiIehFRDB48uEqVKo0bN161alW9evXU74UYntYPGDCgTZs2cjp+/8FlsX79+tnb23t6 ejo7O6sP+DVv3lzO7N3d3WXNjIwM042a3cS1a9dkKxJX6tat6+rqqn6V5MSJE9Kam5ubuqxkeNIf Hx8vYUCSTI0aNeQQ1IUjK4OBTrOGDzG7n0aP1YmIZouzY8eOWrVqyULJw0uXLtUi0L59+5o0aVK5 cmXZ6IIFC6yJiIUo/qBBg6ZNm2a0UJLqmDFjdPbBynJZ84wY3jx06JA83dWqVavzK7Ub1pS9qF4J AAAAQIWLiIX4pmZycrK6iHfngXzXT09Pv379uuGStAcKsYmff/5ZhU9Dkh4t/fk+acd0fSvpNJvv flrzWEvFkZitlhh+0PT+g0+BFuJYClF8HTr7YOUhP8wz8jBlL5LtVliZN1OLcADBIxurAdCFAVTA Xlnsf/QCJcgoIgIlRUaJPb8Zk7DzIANIyT4LFAGgCwOgVxIRK7RTp04tXLiQOqA0jKEyrbfrtLFW z7gpHxpeVGQA4Z0MAF0YoFcSEQFUxIioTevtfLSLigwgvJMBoAsD9EoiIoAKHRENLyrKjM43FcE7 GQC6MECvLJMRkYmJielhpisbvuadprjxWxcAXRgAvfIRRUQAKNB/JO1qHfTNkBk7Ww2PbDbk9MJ1 XEUEAAAgIgKocBFxY40eMX1fj+kfvKlOn9hhb17fezgvO4fiAAAAEBEBVLiIyGVDAAAAIiIA/BIR uWwIAABQUSIi358GoE/nsiEDyCNDqQG6MAB65SOKiPwKMwAGEEoNgC4M0CuJiIxZABhAKDUAujBA ryQiMmYBYHil1ADowgC9kojImAWA4ZVSA6ALAyAi6uH70wAYQCg1ALowQK8kIgIAAAAAiIgAAAAA ACIiAAAAAICICAAAAAAgIlqB708DYACh1ADowgC9koj4C36FGQADCKUGQBcG6JVERMYsAAwglBoA XRigVxIRGbMAMLxSagB0YYBeSURkzNKXnZ2dm5tLHQAGEEoNgC4M0CsrbkS09E3NLVu2hIWFrVq1 atOmTRcvXizNVYiMjIyLi3v4dnr27Dl37lxrX1VffHH8+HHt5pUrVz7//HPD0om9e/dmZWUZlvTQ oUN0SJQn/AADpQZAFwboleUtIlrSsWPHNm3aBAYGenh42NnZRUREPLKjunr16uXLl61ff8SIEYsX L37EEVHKsnDhQu3mjh07mjZtalQ6Nze3GjVqfPPNN9ryadOm0SEBAAAAlMmIOGPGDDXfu3fvgICA R3ZUAwcOnDp16qOvZhFGRK107du3lwRLRAQAAABQfiLipEmT3NzcZGb06NEhISETJkxwdHS8ffv2 jRs3hgwZIvMtW7aMiopSK8fGxvr5+clCeUhSUpJaaHZNaS00NPS9996TNbt06XL48GFZOH/+/OrV q8uaXl5e27ZtM9ors41LO0uXLjVsc/bs2Y0bN3766afj4+PDw8ObN2/+xBNPREZGaussWbLk9ddf d3Z2btas2ZYtW0wjotkdLkRElLg7aNAgIiIAAACAchIRz507V6tWrZdfflmFKCcnp0WLFkn0ys3N 9fX1HTdunGTF5cuXe3t7qwdK2JMYmZeXd+nSJe2beGbXlNYaNWo0efLkkydPSh4bPHiwLExPT/f3 9584caKEtMzMTKO9Mtu4YbST+YYNG86bN09W6Nq1qyTA559//ocffnjllVfkiLR1XFxcPvzww++/ /37s2LH16tXLyckxasfsDhcoIsr+SzqtVKnS5s2biYgAAAAAykZEtPRNTckzkoJatWpla2s7dOjQ tLQ0FaLGjx+vVrhw4YKNjU1ERMTp06fj4uLs7e0TExNleffu3QMCAgy/TGhpTWktKChIrbN69WpX V1c1r/NBU9PGTSPipEmT1Pybb77Zrl079SOl27dvr1q1qraO3KXmk5OTZd8OHjxo2I6lHbY+Ilau XFnqJo3s2bPHsKRERJQz/AADpQZAFwboleUtIlr6vVfJM8OGDYuJiUlISDAbxqKioiQCde7cueuv Dhw4IMslv/n5+Tk4OEyfPv3u3bs6axq2Fh4e7uLikm9ENG3cNCJq87NmzerTp4+aj4yMNIyIht85 bNCgwZIlSwyXW9phQ15eXu+++652UyKohEatdMHBwUlJSe7u7q+++ioREeUYP+NOqQHQhQF6ZQWK iNoX6sxGxPPnz0uO2r17t9mHR0dHOzk5LVu2TGfNQkRE08YfMiLevHlT9m3jxo2Gy/UPTendu3ff vn21m2vWrJEkaVS6/fv329nZad+BJCKC4RWUGqALA6BXltuIKCSA9erVS33s886dO+rDqDExMdnZ 2Xl5eT4+PqGhoTprWoqIwcHBsrLZvTLbeCEioq+vb2pqak5OzsKFC+vVq2e6P2Z32NCCBQtq1Khx 9OhRmU9MTJSVZ86caVq6KVOmSJpVn1MlIoLhFZQaoAsDoFeW54goyadfv3729vaenp7Ozs7R0dGy sHnz5o6Oju7u7gMGDMjIyNBZ01JEPHHihDTi5uZm+EU+xWzjhYiI/fv3b9GihWxR8ttXX31l+liz O2xIth4YGGhjY+Ph4eHg4CCZMyUlxbR0spqXl5e/v7/EWlku69v+SrvqCDC8glIDdGEA9MrSEhH1 v6mZeTM13xbS09OvX79uuCTtAWvW1HHt2jX1SzNGLDVuPRUFJbPJJuTfAh2akeTk5Li4OMOvawIV Cj/AQKkB0IUBemV5i4hmZadnfD9reYRTQLmM10bXQgEAAACAiGhe0r5jX3cbv96+s4RDNZW/qq1Z syYqKopXDwAAAAAionmGlw2NJqoMAAAAABUlIppeNiQiAgAAAEBFjIgJuw5aSoZMTExMVk6MxY8A v3UB0IUB0CsfRUS8/+D3Xs8u/nyH13MRDQK2ugzk5A9AgQYQikCpAdCFAXpleYuIaiZpX9zhF+dt qNYtstmQDVW7EREBcNJDqQHQhQF6ZcWNiErmzVSji4q8gABw0kOpAdCFAXplBY2IGnVRkRENACc9 lBoAXRigV1agiKj/Tc3Mm6m8gAAUbgABpQZAFwbolWUvIgIAAAAAiIgAAAAAACIiAAAAAICICAAA AAAgIurh+9MAGEAoNQC6MECvJCL+gl9hBsAAQqkB0IUBeiURkTELAAMIpQZAFwbolURExiwADK+U GgBdGKBXEhEZswAwvFJqAHRhAEREPXx/GgADCKUGQBcG6JVERAAAAAAAEREAAAAAQEQEAAAAABAR i0x2dnZubu6jP07D7ZbUPqBkn/fStl1ehwAAACifEdHSNzW3bNkSFha2atWqTZs2Xbx4US3s2bPn 3LlzH2ZzkZGRcXFxBX2U4XYffh9Qqui8JErqubZmu7wO9QcQUGoAdGGAXllWI6Kl33vt2LFjmzZt AgMDPTw87OzsIiIiiuS0eMSIEYsXLy7HEfHq1auXL18uZ6+zYj0ow5eE0YaIiKUfP+NOqQHQhQF6 ZQWKiDNmzFDzvXv3DggIKCWn7KX81HzgwIFTp04tZ6+zR3ZQRhsiIjK8glIDdGEA9MrSGBEnTZrk 5uamnRa/9957crNLly6HDx+WhS+++OKsWbO0B77xxht//vOfZSY2NtbPz8/R0VFWTkpKUveOHj16 6dKlaj45OXns2LFNmjSpWbNmu3bt1MLQ0NBu3brVr1/f19dXtW8pIlrariHZnDQ4e/bsxo0bP/30 0/Hx8eHh4c2bN3/iiSciIyO13ZDVnJ2dGzZsOGbMmJSUFFkoO/bBBx9o7bzyyisrVqyQmRs3bgwZ MkQOqmXLllFRUUabmz9/fvXq1eVeLy+vbdu2WWrciNlDNmS2UJZatuaQZZ0lS5a8/vrr8vBmzZpt 2bJFLR8wYICsrObXrVv3zDPPmD0os0WQNkNCQiZMmCDLb9++re384MGDP/nkE+2F9Oyzz6r5mJiY YcOGGb4kTDdk9vVWoOrlu3WzxyLbnTNnjml9jCKi2XWM6mD2acp3r8z2nQKVneGVdzIAdGEARMTi iojnzp2rVavWyy+/rE6LGzVqNHny5JMnT8rZqpzpqixRp06du3fvyvytW7fkLP/EiRMyL+f0cvKa l5d36dKlrKws07An5/Senp47duyQe0+dOqUWbtq06fjx45mZmSNHjhw+fLhORLS0XaPzeDk1nzdv nuxD165d5VT++eef/+GHHyTyyQGqdfz9/fv06XP6gd69e/ft21cWrlmzxt3dXXZe5m/evFm1alX1 AUjZ53Hjxsm5+PLly729vY02l56eLq1NnDhRzublECw1bsTsIRsyWyhLLVtzyLKOi4vLhx9++P33 30v4rFevXk5Ojixv3bq1FuAXL17ctm1bswdltgjSppOT06JFiySUGv6Oi7yKVASSnZcN2dvbq5gk DUr2M3xCTTdk9vVWoOrlu3VLx2K2PkYvLbPrGNXB7NOU716Z7TsFKjvDK+9kAOjCAIiIhWTpm5oS Jzw8PFq1amVrazt06NC0tDR1PhoUFKRWWL16taurq8z8+9//lgz56aefyrwEDDm7VSt07949ICDA 6DtsWh64cOGCjY2NzvcSV6xYISFNJyJa2q7R5iZNmqTm33zzzXbt2qnT6O3bt0vqk5mLFy/Kbqhr Vvcf/EiP3Pzxxx8lrkjm3L9/vyz84IMPfve732n7HBERIaf7cXFxcmafmJhotEXDj0paatyaQ9aY LZROy/keslpH7lLzycnJ8tiDBw9aiohGB2WpCNLm+PHjTQ9KalizZs179+59+eWXEpCeeuqpjRs3 yi5Jjj1z5ozRk2v6QVPT11uBqqe/dZ1jMVsfo5eW2XUM62Dpacq3JqZ9p6Blf2T4AQZKDYAuDNAr y1tEtEQi4rBhw2JiYhISEkwDnggPD3dxcVHzf/jDH/r06SMzTzzxxD/+8Q+1UE5w/fz8HBwcpk+f rq71GbYQFRUlp7zffvut0Xa3bt3q4+PT/oHHH39cJyJa2q7ZRCpmzZqlVr7/4Fc0VV5Su6Ed408/ /SQ3o6OjZf6FF14YM2aMzLRs2XLTpk3ayp07d+76qwMHDuhERJ3G8z1kjdlC6bSc7yHfN/keXYMG DZYsWWJlRLRUBEvfzcvOzq5du7Y8auLEiStXrnzjjTfkWZPX1ZNPPmm6MzrfRTR8vVlfPf2tW3ks Wn0svbQM1zFcbulpyrcmpn2noGUHAABAxVS8EVH7LmK+p+xHjx61tbWVkObo6KilQUVOiJ2cnJYt W2bUwvnz5+WUV33BTxMfHy+nxXv27JH5tWvX5hsRdbZrZUQ8c+aM7MZXX32lln/55Zdy89y5c+qk vHr16jt27GjYsKGc02v7vHv3bp26GYYcncbzPWSN2ULptFzQiHjz5k157MaNG1VEDAkJUctnz55t NiJaKoJOVhk2bNi0adNcXV0lLMk+e3h4TJkyxewTWtCImG/19LduzbEY1seadQyX6zxN+jUx7TuF KDsAAACIiCUWEUWbNm0kgchprrYkJiZGklVeXp6Pj09oaKhpC7169fL29j527JjMnz17Njc3NzY2 Vs74L168mJiYOGrUKAl++hHR7HYLFBFlo08//fTIkSPT0tJSU1MDAwM7dOigvoIo/zZt2rRBgwYz Z87UGpQWZLfVJwDv3LmjPn9rKDg4WFZQ8zqNaywdsiHTQum0bGVE9PX1lQfm5OQsXLiwXr166kCG Dh0aFBSUmZm5bt262rVraxHR8KAsFUEnq6xZs0Za69Spk8xL49WqVZOb2hdHDR9otKF8I6I11dPf uqVjMVsfo5eW2XUM91nnadLfK7N9x5qyr1ixQnaGkREAAICIWPIRUU5kbWxsTp8+rS1p3ry5nLK7 u7sPGDAgIyPDtIVr167JTXlU3bp1XV1d1S+UDB48uEqVKo0bN161apWcdqsfINGJiKbbLVBEvP/g SpScuMsJeo0aNeSU3fAq39tvv21ra3vhwgVtiUSRfv362dvbe3p6Ojs7m35qVM7y5cDd3NzUpS2d xjVmD9mQ2UJZatnKiNi/f/8WLVrIM+jk5KRd5tq3b1+TJk0qV64su7RgwQItIhodlNki6ETEhIQE KaMWXfr27SubNvscGW3Img+a5ls9/a1bOpYRI0aY1sfopWV2HaM6WHqa9PfKbN+xpux+fn6tWrVi ZAQAACAiFl5RfVPz/fff79atm9HCtAf0H/jzzz+npqYaLklOTla/sHLngUJstxBko0a7oSM9Pf36 9es6K0ioM/x5yXwbt+aQTQtV0N02SmV5eXmyn0ZXNXNyciw1aHRQ+Rah0Iw2ZM1zZ/0Lxpon9Pbt 21lZWWbrU6B1HuZpstR3iq/sJTuAgFIDdGEA9MrSEhGL5Pdes7OzXV1dtT/19siU1HbLOr7AhqLC z7hTagB0YYBeSUQ048cff5wzZ476AOSjVFLbLevWrFmj/e11gOGVUgOgCwP0SiIiYxYAhldKDYAu DNAriYiMWQAYXik1ALowQK8kIlrC96cBMIBQagB0YYBeSUT8b4AuJROvVAAAAAAo4YhYShARAQAA AICISEQEAAAAACIiEREAAAAASltELCXf1CQiAmURP8BAqQHQhQF6ZXmLiKUkmxERgbKInkupAdCF AXolEZEnCQA9l1IDoAsD9EoiIk8SAHoupQZAFwbolRU5ImbeTOVJAkDPpdQA6MIAvbKiRESz39TM Ts/4ftbyCKeAR1Y7hk6gLOIHGCg1ALowQK8sbxHRSNK+Y193G7/evrNkNjUREQEAAACgYkVEw8uG RhMREQAAAAAqSkQ0vWxIRAQAAACAihgRE3YdtJQMH/3E0wkAAAAAJRkRxXdvhJ5d/PkOr+ciGgRs dRlIcgNgPX6AgVIDoAsD9MryFhG1EJi0L+7wi/M2VOsW2WzIhqrdiIgArB9AQKkB0IUBemV5i4hK 5s1Uo4uKvIAAcNJDqQHQhQF6ZQWNiBp1UZERDQAnPZQaAF0YoFcSEX+ReTOVFxAATnooNQC6MECv rCgRke9PA2AAodQA6MIAvZKICAAAAAAgIgIAAAAAiIgAAAAAACIiAAAAAICIaAW+Pw2AAYRSA6AL A/RKIuIv+BVmAAwglBoAXRigVxIRGbMAMIBQagB0YYBeSURkzALA8EqpAdCFAXolEZExCwDDK6UG QBcGQETUw/enATCAUGoAdGGAXklEBAAAAAAQEQEAAAAAREQAAAAAABGxwHbv3r1v3z6jhREREfHx 8ZGRkXFxcTqPzXcF5Ysvvjh+/Lh288qVK59//rma37JlS9gDe/fuzcrK0taR5YcOHeJZBwAAAIDi iohmv6kZEhLi4uKSm5urLUlOTq5cufLly5dHjBixePFinQYNV7h69ao8xOxqHh4eCxcu1G7u2LGj adOmar5jx45t2rQJDAx0c3OrUaPGN998oy2fNm0azzpQevADDJQaAF0YoFeWt4ho9vdeb968+dhj j+3evVtb8re//a179+4FbXzgwIFTp04tREScMWOGmm/fvr1kTiIiUDrxM+6UGgBdGKBXVoiIKIYM GaJlM9GpU6dVq1bJzOjRo5cuXaoWxsbG+vn5OTo6urm5JSUlqYXaCvPnz69evbrc6+XltW3btsJF RAmZgwYNIiICDK+UmiIAdGEA9MqSjIjbt2+vUqVKamqqzMfHx8v8rVu3ZL5nz55z585V63Tp0iUk JCQvL+/SpUvalwa1FdLT0/39/SdOnHjjxo3MzMyCRkR5VHh4eKVKlTZv3kxEBBheKTVFAOjCAOiV JRkRs7OznZ2dV6xYIfNvv/32c889Z5QARffu3QMCAoy+bWi4QqE/aFq5cmVbW1sbG5s9e/Zo6xAR AYZXSg2ALgyAXlm8EVHnm5qSxySV5eXlubu7a58UNUyAEg79/PwcHBymT59+9+7dAkVELy+vd999 V7u5fft2CY1aFAwODk5KSpLtvvrqq0REoNTiBxgoNQC6MECvLG8RUcfJkydtbGz+/ve/169f/969 e6YJUImOjnZyclq2bFmBImLv3r379u2r3VyzZk3Xrl21KKi+i7h//347O7vIyEgiIgAAAACUcEQU HTp0qFq1quGlPMMEGBMTk52dnZeX5+PjExoaarpCcHBwr169zLa8YMGCGjVqHD16VOYTExNltZkz ZxpFRDFlyhTJn7ICEREAAAAASjgiLl++3MbGxvAP1hsmwObNmzs6Orq7uw8YMCAjI8N0hRMnTsg6 bm5uhl8pVGT9wMBAadzDw8PBwcHX1zclJcU0IspqXl5e/v7+EkRluaxv+yvtqiMAAAAA4FFExHyl PaC/zrVr13Jzc83elZycHBcXl5CQwHMJAJk3UykCAAAo4YjI96cBMICUEl/YdNzzmzEJOw9SaoDR EgC9ssQiIr/CDIABpPTUU6b1dp021uoZN+VDw4uKlBpgtARAryQiAmB4rYgRUZvW2/loFxUpNcBo CYBeSUQEwPBaoSOi4UVFmeGbigCjJQB65SOKiExMTExMZWK6suFr3tQBTkYB0CuLNyLy/WkADCCl 5+3KcNrVOuibITN2thoe2WzIvj6vcBURYLQEQK98FBERAFCqIuLGGj1i+r4e0z94U50+scPevL73 cF52DsUBAABERACocBFRu2x4euE6LhsCAAAiIgBU6IjIZUMAAEBEBAD8B5cNAQBAyUdEvj8NgAGE UgOgCwP0SiLiL/gVZgAMIJQaAF0YoFcSERmzADCAUGoAdGGAXklEZMwCwPBKqQHQhQF6JRGRMQsA wyulBkAXBkBE1MP3pwEwgFBqAHRhgF5JRAQAAAAAEBEBAAAAAEREAAAAAAAREQAAAABARLQC358G wABCqQHQhQF6JRHxF/wKMwAGEEoNgC4M0CuJiIxZABhAKDUAujBAryQiMmYBYHil1ADowgC9kojI mAWA4bVcljovL2/z5s0zZ86cNm3aZ599du/evWLcky++OH78uHbzypUrn3/+uZrfsmVL2AN79+7N ysrS1pHlhw4d4kkEXRgAvbJsRES+Pw2AAaRMlzolJcXX19fLy2vevHkLFy5s167db37zm6tXrxbT nnh4eMhWtJs7duxo2rSpmu/YsWObNm0CAwPd3Nxq1KjxzTffaMslu/Ikgi4MgF5ZNiIiAKBMe+WV Vx5//PFbt26pm3fv3pWI+Oyzz5ZIRJwxY4aab9++/YgRI4iIAAAQEQEAj05qaqqDg8PkyZMNFy5a tMjGxuaHH36Q+dGjRy9ZsuT11193dnZu1qzZli1b1Do3btwYMmSIo6Njy5Yto6Ki1EJZOTQ09L33 3nNzc+vSpcvhw4cLHREHDhw4aNAgIiIAAEREAMCjc+jQIUmD27dvN1z43XffycJNmzbJfM+ePV1c XD788MPvv/9+7Nix9erVy8nJkeW+vr7jxo27ffv28uXLvb291QNl5UaNGkngPHnypATIwYMHFyIi SvgMDw+vVKnS5s2biYgAABARAQCPjoRD7YKhJjs729bWduXKlSr1vfnmm2p5cnKyrHzw4MELFy7I TERExOnTp+Pi4uzt7RMTE9XKQUFBauXVq1e7uroWNCJWrlxZNi2N79mzR1uHiAgAQFmKiHx/GgAD SNkt9alTpySPhYX9z71Xr17VQpqkvrlz52p3NWjQYMmSJVFRUbJC586du/7qwIEDRiuHh4e7uLiY btHLy+vdd981zKgSGrUoGBwcnJSU5O7u/uqrrxIRAUZLgF5ZJiMiv8IMgAGk7Jb63r17jRs3fu65 5wwXLlu2rEaNGsnJyUap7+bNm5IMN27ceP78eZnZvXu3UWvWRMTevXv37dtXu7lmzRpJmFoUVN9F 3L9/v52dXWRkJBERYLQE6JVERAAMr3ikpf7444+rVav25ZdfqpuHDh1ycnJasGCBlvp8fX1TU1Nz cnIWLlxYr169tLQ0Wd6nT59evXpdvnxZ5u/cuaMWWhMRpWXJn0ePHpX5xMREaWTmzJlGEVFMmTJF dkN9fpWICDBaAvRKIiIAhlc8ulJLnKtbt667u3uzZs1q1aq1ZMmSvLw8LSL279+/RYsWkvcks331 1VdquYS3fv362dvbe3p6Ojs7R0dHWxkRMzIyAgMDbWxsPDw8HBwcJH+mpKSYRkRZzcvLy9/fX/ZE lsv6tr/SrjoCdGEA9EoiIgCGVxRLqSWJnT9//ty5c7m5uYbLVeqTe69du6blRk16evr169cLsT/J yclxcXEJCQk8NYCSeTOV0RLgHKacRES+Pw2AAaQcl9ro52oAFN/p5p7fjEnYeZDREuAcpsxHRABA ObZmzZqoqCjqADyCiCjTertOG2v1jJvyof5FRQAgIgIAAJT/iKhN6+18dC4qAgAREQAAoAJFRC4q AiAiAgBK4ASUiYmprExXNnzNOAagbEREvj8NgAGEUgMo2v/E2dU66JshM3a2Gh7ZbMjpheu+eyOU EgG8sZaZiMivMANgAKHUAIokIm6s0SOm7+sx/YM31ekTO+zN63sP52Xn0IUB3liJiAAYXkGpgQrX SQ0vGxp9+ZAuDPDGSkQEwPAKSg1UrE5qeNmQLgzwxkpEBMDwCkoNVFz6v1lKFwZ4Yy1LEZGfQADA AEKpAdCFAXolEREAAAAAQEQEAAAAABARAQAAAABERAAAAAAAEdEKfH8aAAMIpQZAFwbolUTEX/Ar zAAYQCg1ALowQK8kIjJmAWAAodQA6MIAvZKIyJgFgOGVUgOgCwP0SiIiYxYAhldKDYAuDICIqIfv TwNgAKHUAOjCAL2SiAgAAAAAICICAAAAAIiIAACUFdnZ2bm5uWVut5OSklJSUnj6AABERABAydiy ZUtYWNiqVas2bdp08eLFUrVviYmJsm/Xr18vxGN79uw5d+5cs8cbFRVluCQyMvKHH36Qmbt374aZ SEhIMGpB1o+Liyvyg83KyvL39/f09HRxcTlz5gyvTABAWY2IfH8aAANImS51x44d27RpExgY6OHh YWdnFxER8cj26urVq5cvX9ZZYdasWTY2NnPmzClEa5Yiohxv1apVz58/ry3p0aOHJGSZSUtLG2ug ffv2snXTNDhixIjFixc/5KGZ2rNnT9OmTXmtgtESoFeW+YjIrzADYAAp06WWyDRjxgw137t374CA gEe2VwMHDpw6daqle7Ozsxs1auTl5eXq6mrNR0aNWtOJiPb29nJvXl6eUUQ0lJKS0qRJk1GjRhXH oZkle9urVy9eq2C0BOiVREQADK8oLRFx0qRJbm5uMjN69OiQkJAJEyY4Ojrevn37xo0bQ4YMkfmW LVtqn9KMjY318/OThfKQpKQktdDsmtJaaGjoe++9J2t26dLl8OHDsnD+/PnVq1eXNSUEbtu2zXTH IiIiGjRocOTIERsbm127dmnLBwwYEB4erubXrVv3zDPPmG1NRUSjjarj/eMf/+jg4LBy5UqdiBgU FCTRNDU11XTH5HCWLl1aoEOzVBatyB988EHdunWrVasmD1E7I81269atfv36vr6+2s4nJyePHTtW smvNmjXbtWunU3MwWgKgVxIRATC84qEi4rlz52rVqvXyyy+rfOXk5LRo0aL4+Pjc3FxJKePGjZOs uHz5cm9vb/VASUSScPLy8i5dupSVlaUWml1TWmvUqNHkyZNPnjwpYWbw4MGyMD093d/ff+LEiZJw MjMzTXesX79+asc6dOgwdOhQbXnr1q21hLZ48eK2bduabc3sRtXxfvrpp7NmzZKDvXr1qtmIuH79 eltb271795qtmOH1SSsPzVJZtCLLQ4KDg3/729/KQzIyMuTeTZs2HT9+XB4+cuTI4cOHa+X19PTc sWOHFPzUqVM6NQejJQB6JRERAMMrChkRPTw8WrVqJaFIklhaWppKL+PHj1crXLhwwcbGJiIi4vTp 03Fxcfb29omJibK8e/fuAQEBht+4s7SmtBYUFKTWWb16taurq5rX+TTmjz/+KA+X1CrzYWFhjz32 mHah0mxEvG/ug6ZmN6oiokSvJ554on///qYRMSEhoW7dupL6LFXMKCLme2g6ZdGKLN56663evXub bm7FihXu7u5aO0Zfg7TUOBgtAdArSywi8v1pAAwgZbrUEpmGDRsWExNj+NOdhikoKipKQkjnzp27 /urAgQOyXMKhn5+fg4PD9OnT7969q7OmYWvh4eEuLi75RkRZv06dOpMfeOmll6TZ999/v6AR0exG VUSUmUOHDtnZ2X3yySdGEbFv374tWrRQl/KsiYj5Hpo1ZTGNiFu3bvXx8Wn/wOOPP6618+233xru jKXGwWgJgF5ZYhERAFCmGX4X0WwKOn/+vISQ3bt3m314dHS0k5PTsmXLdNYsaETMycmRdV577bXl vwoICGjZsqUWEUNCQtT87NmzCx0Rhaxfv379J598UouIK1eulNB75MgRnYoVNCJaUxajiBgfHy+7 sWfPHplfu3atioiqnRUrVhg2ov/sAABARAQAFHFEFH369OnVq5f6TOmdO3fUh1FjYmKys7Pz8vJ8 fHxCQ0N11rSUo4KDg83+hmdkZKQkN+37jUL9aI26PjZ06NCgoKDMzMx169bVrl1bi4hGrVkTETMy Mpo1ayYtq4gocat69erSzi0DklcLERGNdibfshhFxNjYWImIFy9eTExMHDVqlKOjo1oujXh7ex87 dkzmz549q37o1WzjAAAQEQEAxRURJaj069fP3t7e09PT2dk5OjpaFjZv3lyii7u7+4ABA7SPZZpd 01KOOnHihDTi5uamLpdpBg0aNG3aNKNdeuqpp8aMGSMz+/bta9KkSeXKlQcPHrxgwQItIhq1Zk1E vP/gKqitra2KiGFhYTYm9u/fX4iIaLQz+ZblvskHTeXoqlSp0rhxY9m3evXqqV+suXbtmjxK9qpu 3bqurq7qt3DMNg4AABERAFC80tPTr1+/brgk7QFr1tQhsceaP3toKCcnx+yfoyhca8XHaGcKVJb7 D/7EhXr4nQe05T///LPp4Re0cQAAiisi8v1pAAwg5aDUmTdTqRLAaAmAXskfvQBQkhhASrzU2ekZ 389aHuEUwHMBMFoCoFcSEQEwvFbcUiftO/Z1t/Hr7TvLXWqiSgCjJQB6JRERAMNrxSq14WVDo4kq AYyWAOiVREQADK8VpdSmlw2JiACjJQB6ZdFHRL4/DYABpPQ7OHKOpWTIxMRUJibGMYBzmDITEQEA ZULmzdSziz/f4fVcRIOArS4DOQEFAABERADA/aR9cYdfnLehWrfIZkM2VO1GRAQAAEREAKjoTC8q UhMAAEBEBICKTl1UJCICAID7/FwNgJLFAFJ6Sp15M5UqAYyWAOiV/NELACWJAYRSA6ALA/RKIiIA MIBQagB0YYBeSUQEAAYQSg2ALgzQK4mIAMAAQqkB0IUBemWFiIh8fxoAAwilBkAXBuiVREQAAAAA ABERAAAAAEBEBAAAAAAQEQEAAAAAREQr8P1pAAwglBoAXRigVxIRf8GvMANgAKHUAOjCAL2SiMiY BYABhFIDoAsD9EoiYsUes7Kzs3Nzc8vcbiclJaWkpNCZwfBKqQHQhQHQK0smIm7ZsiUsLGzVqlWb Nm26ePFiqTrsxMRE2bfr168X4rE9e/acO3eu2eONiooyXBIZGfnDDz/IzN27d8NMJCQkGLUg68fF xRX5wWZlZfn7+3t6erq4uJw5c4b+DIZXSg2ALgyAXlmMEdHSNzU7duzYpk2bwMBADw8POzu7iIiI R3ZUV69evXz5ss4Ks2bNsrGxmTNnTiFasxQR5XirVq16/vx5bUmPHj0kIctMWlraWAPt27eXrZum wREjRixevPghD83Unj17mjZtSjdG6cQPMFBqAHRhgF5Z3iKiJRKZZsyYoeZ79+4dEBDwyI5q4MCB U6dOtXRvdnZ2o0aNvLy8XF1drfnIqFFrOhHR3t5e7s3LyzOKiIZSUlKaNGkyatSo4jg0s2Rve/Xq RTcGAAAAUFoi4qRJk9zc3GRm9OjRISEhEyZMcHR0vH379o0bN4YMGSLzLVu21D6lGRsb6+fnJwvl IUlJSWqh2TWltdDQ0Pfee0/W7NKly+HDh2Xh/Pnzq1evLmtKCNy2bZvpjkVERDRo0ODIkSM2Nja7 du3Slg8YMCA8PFzNr1u37plnnjHbmoqIRhtVx/vHP/7RwcFh5cqVOhExKChIomlqaqrpjsnhLF26 tECHZqksWpE/+OCDunXrVqtWTR6idkaa7datW/369X19fbWdT05OHjt2rGTXmjVrtmvXTqfmAAAA AIiIDxURz507V6tWrZdfflnlKycnp0WLFsXHx+fm5kpKGTdunGTF5cuXe3t7qwdKIpKEk5eXd+nS paysLLXQ7JrSWqNGjSZPnnzy5EkJM4MHD5aF6enp/v7+EydOlISTmZlpumP9+vVTO9ahQ4ehQ4dq y1u3bq0ltMWLF7dt29Zsa2Y3qo73008/nTVrlhzs1atXzUbE9evX29ra7t2712zFDK9PWnlolsqi FVkeEhwc/Nvf/lYekpGRIfdu2rTp+PHj8vCRI0cOHz5cK6+np+eOHTuk4KdOndKpOQAAAAAiYiEj ooeHR6tWrSQUSRJLS0tT6WX8+PFqhQsXLtjY2ERERJw+fTouLs7e3j4xMVGWd+/ePSAgwPAbd5bW lNaCgoLUOqtXr3Z1dVXzOp/G/PHHH+XhklplPiws7LHHHtMuVJqNiPfNfdDU7EZVRJTo9cQTT/Tv 3980IiYkJNStW1dSn6WKGUXEfA9NpyxakcVbb73Vu3dv082tWLHC3d1da8foa5CWGgcAAABARNSj 83M1w4YNi4mJMfzpTsMUFBUVJSGkc+fOXX914MABWS7h0M/Pz8HBYfr06Xfv3tVZ07C18PBwFxeX fCOirF+nTp3JD7z00kvS7Pvvv1/QiGh2oyoiysyhQ4fs7Ow++eQTo4jYt2/fFi1aqEt51kTEfA/N mrKYRsStW7f6+Pi0f+Dxxx/X2vn2228Nd8ZS40DR4gcYKDUAujBAryxvEdHS770afhfRbAo6f/68 hJDdu3ebfXh0dLSTk9OyZct01ixoRMzJyZF1XnvtteW/CggIaNmypRYRQ0JC1Pzs2bMLHRGFrF+/ fv0nn3xSi4grV66U0HvkyBGdShY0IlpTFqOIGB8fL7uxZ88emV+7dq2KiKqdFStWGDai/+wARYWf cafUAOjCAL2SiPjf9NKnT59evXqpz5TeuXNHfRg1JiYmOzs7Ly/Px8cnNDRUZ01LOSo4ONjsb3hG RkZKctO+3yjUj9ao62NDhw4NCgrKzMxct25d7dq1tYho1Jo1ETEjI6NZs2bSsoqIEreqV68u7dwy IHm1EBHRaGfyLYtRRIyNjZWIePHixcTExFGjRjk6Oqrl0oi3t/exY8dk/uzZs+qHXs02DjC8UmoA dGEARMTiiogSVPr162dvb+/p6ens7BwdHS0LmzdvLtHF3d19wIAB2scyza5pKUedOHFCGnFzc1OX yzSDBg2aNm2a0S499dRTY8aMkZl9+/Y1adKkcuXKgwcPXrBggRYRjVqzJiLef3AV1NbWVkXEsLAw GxP79+8vREQ02pl8y3Lf5IOmcnRVqlRp3Lix7Fu9evXUL9Zcu3ZNHiV7VbduXVdXV/VbOGYbBxhe KTUAujAAImLxVic9Pf369euGS9IesGZNHRJ7rPmzh4ZycnLM/jmKwrVWfIx2pkBluf/gT1yoh995 QFv+888/mx5+QRsHGF4pNQC6MECvrNARUf+bmpk3U3kBASjcAAJKDYAuDNAry15ENCs7PeP7Wcsj nAL4Ty8AAAAAqLgRMWnfsa+7jV9v31nCoZqoMv6fvXuBquK89z4OYuI1GC8IyiUiSjQBL7GKl2pU RLxgPIhFKVISl/GoqU30WE201SQujT25QMBqqp7IKeklK3JAhUZtAorBFWPIa9XEiIqoKCoEolhF N+D7P0wyZ3fPhc1VkO9n7dU1+8nsZ555Zp6H+XX2HgEAAAC0rIhofdvQ5kUvAwAAAEBLiYja24ZE RAAAAABoiRHx8seHjJIhL168ePFqai/+7AHNFI+rARiVzSYi3qt63uupmL+k+f4suXvwTo9pXJEA qNEEQifQ1QAYwgCj8kGLiMrC1Yzsw8++/lH70al9ZnzUbjQREQAXPXQ1AIYwwKhsuRFRUVZYYnNT kRMIABc9dDUAhjDAqGyhEVGl3FRkRgPARQ9dDYAhDDAqW1BENP+lZllhCScQgNpNIKCrATCEAUZl 84uIAAAAAAAiIgAAAACAiAgAAAAAICICAAAAAIiIZvj9NAAmELoaAEMYYFQSEX/AU5gBMIHQ1QAY wgCjkojInAWACYSuBsAQBhiVRETmLABMr3Q1AIYwwKgkIjJnAWB6pasBMIQBEBHN8PtpAEwgdDUA hjDAqCQiAgAAAACIiAAAAAAAIiIAAAAAgIiIf1FZWXn37t1G2JDFYqmoqGiOu9M4LQcAAADQ5CKi 0S81U1JStmzZsnXr1qSkpNzc3Aep13bs2NG5c+e615OampqdnW2ywtixY9esWdNcdqehW15td6E5 4gEMdDUAhjDAqHzQIqLR816HDRs2YMCA8PDw3r17t2rVKjk5udH26uLFi3l5eU0wU9k0bPbs2TEx MQ9GRLTZtXppeU27676cDGigCQR0NQCGMMCofAAj4ooVK5Tl8ePHBwcHN9peTZs2benSpU0wU9W0 Yc0oItrsWr20vF6OY0OfDGB6pasBMIQBRiURscYRcdGiRV5eXrIQFRUVGxu7YMECySTXr1+/du3a jBkzZLlfv37p6enKyllZWUFBQVIoH7l69apSqLum1BYXF7d27VpZc+TIkYcPH5bCdevWdejQQdb0 9fXdtWuXTauKiormzp3r7u7+yCOPDB48WK2n2lYVFhZOnz69S5cu8qlly5apmaouDZPV4uPjlY/I +qNHj+7WrduECROU9W2Clm63WNOtQbclJrtTbYUhISGJiYnKckJCglSiu2tKy7Xbra/u0j2O2gZr K9FtAJhe6WoADGEAjMrGi4inT592dnZ+/vnnleTg4uKyYcOGnJyciooKuZSfN2+epLJNmzb5+/sr H5SQIIGtsrLy3Llzd+7cUQp115TaevTosXjx4hMnTsh1f2hoqBSWlpZOnDhx4cKFEgbKyspsWiX1 +Pj4pKWlSc1ff/21Wk+1rZo0aVJwcHBeXl5+fr7EJDVT1aVh1gkwKSnp6NGjUh4ZGTlr1ixtRNTt FmtGNWhbYrI71Vbo5+en5rSYmJhBgwYZ7Zruduuru3SPo7bB2kp0GwCmV7oaAEMYAKOy3iKi0S81 JSL27t27f//+jo6OYWFhN27cUK7y58+fr6xw9uxZBweH5OTkb775Jjs728nJqaCgQMrHjBmjpBe1 KqM1pbaIiAhlnW3btnl6eirLRt8tVOrR/p6t2lZduHBBCiWQKOuo38ysY8N0v425efNmb29v7Qra bjFiU4O2JUa7Y0+FuhFRd9e0262v7jI6jroNtq7EqAG4j3gAA10NgCEMMCoftIhoRCLizJkzMzMz L1++rBuK0tPT5Xp9xIgRo3508OBBKZcUFBQU1Lp16+XLl9++fdtkTevaEhMTPTw8zCOiUs9XX32l jYjmrdq/f78UqjuiZqo6Nsx6tZ07dwYEBDxVpVevXtoVtN1io9oa1JYY7Y49FdofEbXbra/uMjqO ug22rsSoAQAAAAAaIyKqv0XUTQ5nzpyR6/W9e/fqfvzAgQMuLi4bN240WbOmEVGpZ/PmzTVtVUFB gaOj46FDh2wyVR0bpq6Wk5Mj2W/fvn2yvH37dt2Ap+0Wa/bUoLbEaHfsqVAiYmxsrLK8atWqGkXE +uou3eNo1GDrSsxPOQAAAAD3MyKKwMDAcePGKV+evHnzpvJl1MzMTIvFUllZGRAQEBcXZ7KmUbRY smSJrKzbKin39/f/8ssvZfnUqVPKP+9uT6uGDBkSFRVVXFx85MiRgQMHqpmqLg1TV8vKypJ4k5ub K+Ftzpw5auXW9eh2i8qeGqxbYrQ71VYYFhYWERFRVlaWkJDQqVMnNSIa7ZrNduulu3SPo1GDbSrR bQAAAACAJhER5Wp+ypQpTk5OPj4+rq6uBw4ckMK+ffvK9b23t3dISMitW7dM1jSKFsePH5dKvLy8 lHtK1i5duiSfcnBw6NKli6enp/Y5KEbbSktLc3Z2lkJJJvHx8WoCqUvDrFcLDQ1t27Ztz549t27d 2rVrV+VpK9Yr6HaLtWprsG6J0e5UW2FGRoa7u3ubNm3kv65fv16NiCa7Zr3d+uou3eOo22CbSnQb AAAAAKDeImLdf6lZWlp65coV65IbVexZ04SkCOUmodZ3331XUlJS01ZZLBajrddLw4qKipTym1W0 Kxh1i/012Lk75hWWl5cb9Z5JnzfOcTTqAZtKatQANCgewFC/ygpL6GqA2RIAo/I+R0SewgyACaTp 9Oe+n0Rf/tshuhpgtgTAqCQiAmB6pT+HyevDVsN3OI/NfvEd65uKdDXAbAmAUUlEBMD02hIjovr6 sFWAelORrgaYLQEwKomIAJheW3REtL6pKAsmv1QEwGwJgFFZnxGRFy9evHg1i9eFjz7ljzrQHPG4 GoBR2ZwiIgCg6fw/mtavj/0iPpux4m/9Z6X2mfHNGwncRQQAAEREAGhxEXFHx6czJ7+UOXVJ0qOB WTNfvvL3w5WWcjoHAAAQEQGgxUVEbhsCAAAiIgDgh4jIbUMAAHCfIyK/nwbABNJEmNw2pKsBZksA jMpGiog8hRkAEwhdDYAhDDAqiYjMWQCYQOhqAAxhgFFJRGTOAsD0SlcDYAgDjEoiInMWAKZXuhoA QxgAEdEMv58GwARCVwNgCAOMSiIiAAAAAICICAAAAAAgIgIAAAAAiIgAAAAAACKiHfj9NAAmELoa AEMYYFQSEX/AU5gBMIHQ1QAYwgCjkojInAWACYSuBsAQBhiVRETmLABMr3Q1AIYwwKgkIjJnAWB6 paubIIvFUlFRcd+bUVlZeffuXaP/evXq1eLi4qbQklprzF0AsyXAqGzGEZHfTwNgAmnWXZ2SkrJl y5atW7cmJSXl5uY2x70bO3bsmjVravfZ1NTU7OzsemnGjh07OnfurC2/c+fOxIkTfXx8PDw8Tp48 2QgdYtSSWmucXfjrX/969OhR9e2FCxf+8pe/MHiZLQFGZfOLiACAZm3YsGEDBgwIDw/v3bt3q1at kpOTG23TFy9ezMvLu78Rcfbs2TExMbrtqWnzjILZvn37HnvsscY8ptVGxJruWuPsgpyBb7zxhvo2 LS2tkfsNAEBEBAD8b0RcsWKFsjx+/Pjg4OBG2/S0adOWLl16fyOiSXtq2jyjYCZtGzduXJOKiDXd tcbZBSIiABARAQBNKyIuWrTIy8tLFqKiomJjYxcsWCBJ4/r169euXZsxY4Ys9+vXLz09XVk5Kysr KChICuUjV69eVQp115Ta4uLi1q5dK2uOHDny8OHDUrhu3boOHTrImr6+vrt27bJplW7lISEhiYmJ ynJCQsL06dPViLh69eqXXnrJ1dW1T58+KSkp1ttdtWpVz549hwwZkpOTIx/v27fvE088kZqaqq4T Hx+vbY+2ebq7VlhYKM3o0qXL4MGDly1bpg1mv//97+W/tm/fXurZunWrlBQVFclGpalubm7R0dHq r/ts+tyexlszaolUMnr06G7duk2YMMGo57XrmO+CTVNN9qhGu2ASEWt0slm3jQEOAEREAEAtI+Lp 06ednZ2ff/55JXS5uLhs2LBBLusrKiokOcybN08uuDdt2uTv7698UMKeXItXVlaeO3fuzp07SqHu mlJbjx49Fi9efOLECbmmDw0NlcLS0tKJEycuXLhQLvTLyspsWqVbuZ+fnxLnRExMzKBBg9T6PTw8 3nnnnWPHjs2dO7dr167l5eVKuYSW119/XSoZNWqUpMef//zn33777QsvvCB7rX5WuQNp0x5t83R3 bdKkScHBwXl5efn5+ZJgtRHxn//855IlS376059KPbdu3ZISqTYwMPCbKuPHj588ebLaEus+t6fx 1oxakpSUdPToUdmFyMjIWbNm6fa8dh3zXbBpqske1WgXTCJijU4267YxwAHgPkREfj8NgAmkWXe1 XKzLpXn//v0dHR3DwsJu3LihXGfPnz9fWeHs2bMODg7JyckSALKzs52cnAoKCqR8zJgxSiZRqzJa U2qLiIhQ1tm2bZunp6eybPJ1R23l5hHx5ZdfVpaLioqkDYcOHVLKFy1apJTLCoMHD1Yyw+7du9u1 a2cTEe+ZftFUd9cuXLgghZJklHWMvt75m9/8RoKTspybmysfUe+apqSkyNvz58/b9LmdjVfZ05LN mzd7e3ub97z1Oka7YNNU8z2yfxfMI2KNTjbrbmS2BMCovA8RkacwA2ACadZdLRFx5syZmZmZly9f ts4AanBKT0+Xa/ERI0aM+tHBgwelXK7Xg4KCWrduvXz58tu3b5usaV1bYmKih4dHtRFRW7l5RLT+ LWL37t3fffddm/KVK1cGBgYqy6mpqTWNiLq7tn//filU+82eiKjUo34kPz9f3h44cEC7F/Y0XmXS kp07dwYEBDxVpVevXrp7qruOeUS0OT2q3aNqd0H4+vq+9tpr6ltJkhIajc4He042ZksAjEoiIgCm V9QmIqq/RdTNAGfOnJFr8b179+p+XMKAi4vLxo0bTdasRUTUVq5ExNjYWGV51apVuhGxsLBQ2iAZ qX4jou6uFRQUODo6Kncs7YyIJ0+elHo++eQT5e2ePXvk7enTp+sYEY1akpOTI7Fq3759srx9+3bd iGi0jp0R0c49siciWn9JVbz//vsS/OpysjFbAmBUEhEBML2i/iOikIv7cePGKV/zu3nzpvJl1MzM TIvFUllZGRAQEBcXZ7KmUURcsmSJ0XMydSsPCwuLiIgoKytLSEjo1KmTdUScMGFCSUlJeXn5G2+8 0bVrV+127YmINu2xeau7a0OGDImKiiouLj5y5MjAgQOrjYgVFRXykcjISPm4NDg8PHzo0KGym3WM iEYtycrKkviXm5srGXLOnDlq86x3zWgdOyOinXtkzy6sX7++Y8eO0n4l9EoLX3nlFZPzodqTjdkS AKOSiAiA6RUNEhHlen3KlClOTk4+Pj6urq7K1wj79u0rccLb2zskJER5ionRmkYR8fjx41KJl5eX cgvLmm7lGRkZ7u7ubdq0CQ0NlThhHRFnz579+OOPS80uLi7qHa2aRkSb9ti81d21tLQ0Z2dnKfT3 94+Pj7cnX+Xk5EiIkogrcWj48OHKDbe6R0SjlkhftW3btmfPnlu3bpXwrDyNxmbXdNexMyLauUf2 7IIcaEmYDg4OvXv3ltQqsV99OGrtTjZmSwCMyvsTEfn9NAAmkBbS1aWlpVeuXLEuuVHFnjVNXLp0 SffJk7qVl5eXl5SU2BRev379zp07lZWVUpVy/6oubNpj81a7axaLxf6dVRUVFWl3pI6MWiLbUnbh ZhXdXTNap/H3SOrJzs62/mVsPZ5szJYAGJWNEREBAABQR2WFJXQCACIiAAAA/tdfHYbt+0n05b8d oisAEBEBAACIiMPk9WGr4Tucx2a/+A43FQEQEQEAAFp6RFRfH7YK4KYigOYaEfn9NAAmELoaQP1G RJubiv/v13F0EcAf1mYTEXkKMwAmkGZ69cmLF69m9Lrw0adMZQDXMEREAEyvoKuBlvj/43zsF/HZ jBV/6z8rtc+Mb95IYAgD/GElIgJgegVdDbS4iLij49OZk1/KnLok6dHArJkvX/n74UpLOUMY4A8r EREA0yvoaqDFDVLr24Y2TzRlCAP8YW1OEZFHIABgAqGrAdT9ctP6tiFDGOAPazOOiAAAAKgj/iFE AEREAAAAAAAREQAAAABARAQAAAAAPOARkd9PA2ACoasBMIQBRiUR8Qc8hRkAEwhdDYAhDDAqiYjM WQCYQOhqAAxhgFFJRGTOAsD0SlcDYAgDjEoiInMWAKZXuhoAQxgAEdEMv58GwARCVwNgCAOMSiIi AAAAAICICAAAAAAgIgIAAAAAiIgAAAB4wF29erW4uLhBN1FZWXn37t3m3lEWi6WioqKFNLKBDlkj nGy4nxGR308DYAKhqwE0/hDeu3dvRkaGTWFycnJOTo49daampmZnZyvLd+7cmThxoo+Pj4eHx8mT JxtuR3bs2NG5c+em0KUFBQVbtmy5cuVKLT47duzYNWvWaMtTUlLS09NtOvnbb781qerYsWNffPFF ozXy9u3bWzQuX77cmIescU62v/71r0ePHlXfXrhw4S9/+Qt/WBsvIvIUZgBMIHQ1gMYfwrGxsXKR bX2nqKioqE2bNnl5efbUOXv27JiYGGV53759jz32WCPsSI3yxsWLF+3cl1pYuXKlg4PD6tWra9ES o4g4bNiwdu3anTlzRi15+umnt27dalJzeHh4UlJSozXyxo0bc6089dRTUr/6/xTU7pDV9DA1zsnW u3fvN954Q32blpZW7xvlH73gsgMAuYWuBtC0hnBhYeFDDz20d+9eteT3v//9mDFjalG/ZIlx48Y1 tYg4bdq0pUuXNkQzLBZLjx49fH19PT097fk2pk1LTCKik5OT/NfKykp7IuLdu3e7d+9eWlramI1U FRcXu7u7z5kzp46HrKaHqXFONiIiEREAuQV0NdASh/CMGTNmz56tvh0+fLgSSK5duyb/Sa7s+/Xr p371MSoqKjY2dsGCBVJ+/fp1eRsfH68Eyy5durRv317SiHz82WefXblypVrnr3/969/97nc2242L ixs9enS3bt0mTJhw+PBhtX4pX7t2rZeX18iRI9VyibLTp0+XTQwePHjZsmW6eSMrKysoKEj+k3z2 6tWrUrJu3boOHTpIibRq165d96rukcomXF1d3dzcoqOj1V+y2eyX7r7bSE5Olmz2xRdfODg4fPzx x2p5SEhIYmKispyQkCDN1m2Jkr60eyoR8T/+4z9at2793nvv2RMRP/3004kTJxr91wZqpCoiIkLC Z0lJie7/+6B7yLTHXbtd3XPD+v/FsD7ZtIfP5ChLzatWrerZs+eQIUNycnKkE/r27fvEE0+kpqbW KCJqTzY7hwwRkcsOAOQWuhpAUx/Cu3fvbtu2rXKVLxfNsvz999/Lslydz5s3Ty5qN23a5O/vr6ws mcHFxWXDhg2yZkVFhXqX6Z///OeSJUt++tOfylXyrVu3JHU8+uijt2/flv8ktUkAOH78uM12k5KS jh49WlZWFhkZOWvWLLX+Hj16LF68+MSJE3K1HRoaqpRPmjQpODg4Ly8vPz9f4o1uRJQMI9filZWV 586du3PnjpSUlpZKfFq4cKG0SjYkJfI2MDDwmyrjx4+fPHmy7n7p7ruNKVOmrFixQhaGDh0aFham lvv5+SmxWcTExAwaNEi3JUZ7KhHxT3/6kwRsZ2fnixcvVhsRX3rpJXVzjdZIxYcffujo6Pj3v/9d d9NGh0x73LXb1T03VDYnm/bwmRxlCY2vv/66nCGjRo3q06fPz3/+82+//faFF16Qbq9RRNSebHYO GSJiDfAIBABMIHQ1gPsyhC0Wi6ur6+bNm2X5t7/97c9+9jNZOHv2rIODQ3JyslxkZ2dnOzk5FRQU KNe78+fPVz9r/UXE3/zmN3I5rl7ES8KRqCPLEkXketqkYbJpb29vtcKIiAhledu2bZ6enveqHhMi jZELdKXc6FuLY8aMUTKJdaH1Nxhzc3OlHuU+1b2qB8PI2/Pnz9vsl9G+W5NPSfnp06dlecuWLQ89 9JB6K0k3fd3T+w6ndk/ViCjp6Iknnpg6dWq1EVFyjtGv+BqukeLy5ctdunSR9Ki7aXsOmfVxN/qi qfU61qxPNpvDZ36UFy1apJS//PLLgwcPVjLb7t2727VrV6OIqD3Z7BwyLecPK//oBQAAQDO2bNky SSaVlZVyOa5cW6enp8v17ogRI0b96ODBg/c0P04zioji3//93wMDA2VBos5///d/aze6c+fOgICA p6r06tVLW2FiYqKHh4cs7N+/XxqjPjPTKCLK9XpQUFDr1q2XL1+u3MC0yR7KTqn15Ofny9sDBw7Y bNdo363Jyo8++ujiKs8995ys/+abb9Y0fWn3VI2IsvD555+3atXqgw8+MImIkkaMbnI2aCPF5MmT H3/8ceUmnpbJIdM97jbb1V3HPCLaHL5qj/LKlSuV8/Ne1TNjdSOir6/va6+9pr6VJCmh0ehks3PI tBxERAAAgGbsxIkTcnX7hz/8oVu3bsq/X3fmzBkpsX6MjfZa3DwiHjlyxNHRUcKhZAM1sKlycnLk 8nrfvn2yvH37dvOIWFBQIFUdOnTIPCIqJAy4uLhs3LhRmz1OnjwpO/XJJ58ob/fs2SNvlZts1ts1 2ndVeXm5NOxXv/rVph8FBwf369dPTV+xsbHK8qpVq2odEYWsL0fkySefNIqI//mf/2n9m89Ga+R7 770nh8/8X9rQPWRGx916u0br2BkR7TzK9kRE6y+pivfff1+Cn9HJZueQISICAACgeRg6dKhcJf/y l79US+QCety4ccpX6W7evHnjxo0aRUQxYMAAqfPFF1/Ubi4rK0tiQG5urmSJOXPmqJHPKJMMGTIk KiqquLhYkufAgQN1I2JmZqbFYqmsrAwICIiLi1MKlyxZoj76sqKiQuqJjIyUfSkpKQkPD5e9Vh4c arNfuvuukkQhyU39BZpQngej3DUKCwuLiIgoKytLSEjo1KmTmr6sW2JnRLx161afPn2kZqOIOHr0 aDWG2Wi4RkoW6tChg6z5vRVJpDYN0D1kRsfdertG69gZEe08yvZExPXr13fs2FHar4ReaeErr7xi crLZM2SIiAAAAGgeNm3aJPnh888/V0vkmnjKlClOTk4+Pj6urq7ar+pVGxHl0lnq/Oabb3S3GBoa 2rZt2549e0r+6dq1q/JUEqPglJaW5uzsLI3x9/ePj4/XjQ19+/aVcm9v75CQEPULkMePH5dyLy8v 5a5UTk6OBAYJRXLpP3z4cOXmkna/dPdd9cwzzyxbtsxm65KCoqOjZSEjI8Pd3b1Nmzayg5Ix1PRl 0xJ7IuK9qvtUjo6OuhGxqKioR48eRv+URcM1csuWLQ4a+/fvt9mW0SHTPe4229Vdx86IaOdRtici ylkkCVP2rnfv3pJaJ0yYoD4cVfdks2fIEBFrgEcgAGACoasBNMEhXFpaeuXKldpt8c033xw9erTJ ChJylIRzs4p5bRaLpdqW3KiiLb906ZJ1lJLt6v47DfW17+Xl5Ub127SkLiSzPfvss7X+eCM00uiQ GR136+3W6NwwOrvsOcr21JOdna3+uLHak61Gpw2PqzHDg9QBMIHQ1QAepCEs8cDT0/ODDz6g5xvI iy++uHv3bvqBUUlEBAAmELoaQDMYwufPn1+9erXyz9wBICLSOwCYXulqAAxhAEREegcA0ytdDYAh DICIWEc8AgEAEwhdDYAhDDAqiYgAAABoDH91GNZEXhwL4IFHRAQAAIC9SZVOAIiIAAAAABERICIC AAAARESAiFhT/H4aABMIXQ2gJQxhIiLQEv6w8o9eAOBqg64GwBBmJgEYDkREAEyvdDUAhjAzCcBw ICICYHqlqwEwhJlJAIYDEREA0ytdDeABHMJlhSXMJAB/WJtQROQRCACYQOhqAI0/hC2lt46t3JTs Etxol6pERKAl/GHlH70AAABoZq5mfPnp6PkfOo2QzKa8iIgAiIgAAAAti/VtQ5sXEREAEREAAKCl 0N42JCICICICAAC0RJc/PmSUDBv/xeEAiIjV4xEIAJhA6GoADer//TruVMxf0nx/ltw9eKfHNJIb wB/WJh0RmZUAMIHQ1QAaZwhfzcg+/OzrH7UfndpnxkftRhMRAf6wEhEBML2CrgZa+hAuKyyxualI FwH8YSUiAmB6BV0NtPQhrNxUZIAD/GElIgJgegVdDTCEf1BWWEIXAfxhbUIRkUcgAGACoasBMIQB RiUREQAAAABARAQAAAAAEBEBAAAAAEREAAAAAAAR0Q78fhoAEwhdDYAhDDAqiYg/4EHqAJhA6GoA DGGAUUlEZM4CwARCVwNgCAOMSiIicxYAple6GgBDGGBUEhGZswAwvdLVABjCAIiIZvj9NAAmELoa AEMYYFQSEQEAAAAAREQAAAAAABERAICmz2KxVFRUtPBOqKysvHv3blOoBABARAQANCcpKSlbtmzZ unVrUlJSbm7uA7BHY8eOXbNmTa0/npqamp2dXcc21EsldbFjx47OnTvXYyX3fY/uy7gQf/zjHz/7 7LPCwsJmeiYAwH2IiPx+GgATSLPu6mHDhg0YMCA8PLx3796tWrVKTk5utFZdvHgxLy+v3uupY0Sc PXt2TExMHdtQu0qackSslz2qryPeCNuVceHn5/fcc89NnTq1f//+bdq0iYuLa7TTidkS4BqmeUdE nsIMgAmkWXe1XAqvWLFCWR4/fnxwcHCjtWratGlLly6t93rqGBHv77402YjYrHupFtuVcbFs2TL1 7ebNmx0cHP70pz8xWwJ44EclEREA0ysR8f8i4qJFi7y8vGQhKioqNjZ2wYIFkhCuX79+7dq1GTNm yHK/fv3S09OVlbOysoKCgqRQPnL16lWlUHdNqS0uLm7t2rWy5siRIw8fPiyF69at69Chg6zp6+u7 a9cum1bJ+qNHj+7WrduECROU9UVISEhiYqKynJCQMH36dN16lIhoszlRVFQkLXF1dXVzc4uOji4u LlabZ72z8jY+Pv5e1W8aff/Vq6++qts2bRvUSsy3q+0WG/LZuXPnuru7P/LII4MHDzavsLCwUPqk S5cusqbEGzXd6R4UI0aVWO+RPaeHtuXmR1z34Nb0NLNulVqzdrtGHWgSEcUzzzwzYMAAowbIzr79 9tvqyi+88IKkSu2ZoD2adh4dZkuAaxgiIgCmVzR2RDx9+rSzs/Pzzz+vpCwXF5cNGzbk5ORUVFRI Fpo3b55cdm/atMnf31/5oKQauSKvrKw8d+7cnTt3lELdNaW2Hj16LF68+MSJE3I1HBoaKoWlpaUT J05cuHChXCKXlZXZtCopKeno0aNSHhkZOWvWLKXQz89PvdqOiYkZNGiQbj26mxOyWmBg4DdVxo8f P3nyZLV51jtrfRPy2o/ee++9hx9+OCMjQ7dtum1QKzHZrm47rUl/+vj4pKWlSQ9//fXX5hVOmjQp ODg4Ly8vPz9fEpea7nQPihGjSqz3yJ7TQ9ty8yOue3BreppZt0qtWbtdow40j4jSKjkHysvLdRvw /vvve3t7SzuVmN2uXTvlq63W/aZ7NO08OsyWANcwREQATK9ovIjYu3fv/v37Ozo6hoWF3bhxQ7mu nT9/vrLC2bNnHRwckpOT5Xo6OzvbycmpoKBAyseMGaNkCbUqozWltoiICGWdbdu2eXp6Ksv2fP1v 8+bNcuVtniK0XzTVbi43N1fapt68SklJkbfnz5+32dl7et9TPXLkSPv27bdv327SNqMvu5pvV7db bPrT5pdsRhVeuHBBFiR+KOXqd0SNDoouo0q0EdH89NBtufkRNzq4NTrNrI+j0XZNjoh5RJQQ2KpV KwmZug2QINqhQ4f9+/fLmm+//bYkbZt+0+0T+48OsyXANUxzioj8fhoAE0iz7mq5FJ45c2ZmZubl y5d1Y1J6erpcxY4YMWLUjw4ePCjlctUeFBTUunXr5cuX375922RN69oSExM9PDyqDQw7d+4MCAh4 qkqvXr1qGhG1m1Papu5jfn6+vD1w4IA2E9q8lfDg5ua2atUq87YZtcHO7Vp3i0r57FdffaUt1FYo 4cS6XE13RgdFl1El2ohofnrotrx2EbF2p5nJdk2OiHlE/O1vf6v8PwJGDfjFL34RHR0tC/369UtK StI9E3SPpj1Hh9kS4BqmOUVEAECzZv1bRN2YdObMGbmK3bt3r+7H5draxcVl48aNJmvWNCLm5ORI JNi3b58sb9++3ToixsbGKsuS2WoUEU+ePClt++STT5TyPXv2yNvTp0+bR8Tr16/LRmfNmqV8gdCk bUZtsHO7uhFR6U/lJ20qowoLCgocHR0PHTpkk+7MD58No0pMIqJu/botrzYi6h7c2p1mJts1OSIm EfHu3buSD1988UWTBkje69ChQ1pampubm8VisWmVbp/U6OgAABERANAkIqIIDAwcN26c8mW/mzdv Kl9GzczMlOtgyU4BAQHqvwegu6ZRFlqyZImsrG1SVlaWxLDc3FxJLHPmzFFTSlhYWERERFlZWUJC QqdOndQUYVOP7uYqKiqGDBkSGRkpTSopKQkPDx86dKgS/IwiouxdcHDwiBEjlJtX5m0zaoOd29WN iELq9Pf3//LLL2X51KlTFVWMKpTyqKio4uLiI0eODBw4UG2b7kGRrPLGG29ot2hUiVFENKpf23KT I25ycGt3mtmw3q5JB+pGxFu3bmVnZ8uZIBHx+++/N2mAVPLYY4917979lVde0T0bdftEtyoAICIC AJp0RJQ4NGXKFCcnJx8fH1dXV+VbeX379pX8INfNISEhchltsqZRFjp+/LhU4uXlpdyUsxYaGtq2 bduePXtu3bq1a9euylNhMjIy3N3d27RpI/91/fr1aoqwqcdoczk5ORIGJH507Nhx+PDh6o0jo4j4 +eefOzg4tG/f/tEfKV8j1G2bSRvs2a5RRLx06ZKsJs3o0qWLp6en8rQVowrT0tKcnZ2l8yWHxMfH q+lO96AEBQU9+eST2i0aVWISEXXr1225yRE3Ori1O81s2GzXqANtxoU03tHRsV27dhKVly5dah3e dBtwr+rLqPKRs2fP6g4l3T4xqgoAiIgAgPuprLCk2nVKS0uvXLliXXKjij1rmpDrZuvnT6qKioqU 8ptVlMLy8vKSkpIa1aOt1qgG++m2zbwNddnud999p/2sboUWi8Wo520OyrFjx8LDw3XXNKmkRqeH UcuNesno4NbLaabdbt3PhJo2wKRPalcVADTRiMjvpwEwgTTfrraU3jq2clOySzDPS2xp3nrrLeXx m2C2BMCorOeIyFUFACaQ5tjVVzO+/HT0/A+dRsh/Ul70EsBsCYBRSUQEwPTasrra+rahzYteApgt ATAqiYgAmF5bSldrbxsSEQFmSwCMSiIiAKbXFtrVvHjxatYv5jGAa5hmExH5/TQAJpBm0dVlhSWn Yv6S5vuz5O7BOz2mcQEKMFsCYFQ2SEQEADQvVzOyDz/7+kftR6f2mfFRu9FERAAAQEQEgJZOe1OR PgEAAEREAGjplJuKREQAAEBEBAD8oKywhE4AAAA8rgbA/cQEQlcDYAgDjMoHLSLy3SQATCB0NQCG MMCoJCIyZwFgAqGrATCEAUYlEZE5CwDTK10NgCEMMCqJiMxZAJhe6WoADGEAREQz/H4aABMIXQ2A IQwwKomIAAAAAAAiIgAAAACAiAgAAAAAICICAAAAAIiIduD30wCYQOhqAAxhgFFJRPwBT2EGwARC VwNgCAOMSiIicxYAJhC6GgBDGGBUEhFb6pxlsVgqKipa+GCorKy8e/duU6gETK+gqwGGMABGZXOK iCkpKVu2bNm6dWtSUlJubu4D0Fljx45ds2ZNrT+empqanZ1dxzbUSyV1sWPHjs6dO9djJfd9jxqZ Mi7EH//4x88++6ywsLCZnglMr3Q1AIYwwKgkIuoz+qXmsGHDBgwYEB4e3rt371atWiUnJzfaXl28 eDEvL6/e66ljRJw9e3ZMTEwd21C7SppyRKyXPaqvI94I25Vx4efn99xzz02dOrV///5t2rSJi4tr tNOpCeIBDHQ1AIYwwKh80CKiyaXwihUrlOXx48cHBwc32l5NmzZt6dKl9V5PHSPi/d2XJhsRm3Uv 1WK7Mi6WLVumvt28ebODg8Of/vQn5lkAAAC0oIi4aNEiLy8vWYiKioqNjV2wYIEkhOvXr1+7dm3G jBmy3K9fv/T0dGXlrKysoKAgKZSPXL16VSnUXVNqi4uLW7t2raw5cuTIw4cPS+G6des6dOgga/r6 +u7atcumVbL+6NGju3XrNmHCBGV9ERISkpiYqCwnJCRMnz5dtx4lItpsThQVFUlLXF1d3dzcoqOj i4uL1eZZ76y8jY+Pv1f1m0bff/Xqq6/qtk3bBrUS8+1qu8WGfHbu3Lnu7u6PPPLI4MGDzSssLCyU PunSpYusKfFGTXe6B8WIUSXWe2TP6aFtufkR1z24NT3NrFul1qzdrlEHmkRE8cwzzwwYMMCoAbKz b7/9trryCy+8IKlSeyZoj2aNjg4AAADQeBHx9OnTzs7Ozz//vJKyXFxcNmzYkJOTU1FRIVlo3rx5 ctm9adMmf39/5YOSauSKvLKy8ty5c3fu3FEKddeU2nr06LF48eITJ07I1XBoaKgUlpaWTpw4ceHC hXKJXFZWZtOqpKSko0ePSnlkZOSsWbOUQj8/P/VqOyYmZtCgQbr16G5OyGqBgYHfVBk/fvzkyZPV 5lnvrPVNyGs/eu+99x5++OGMjAzdtum2Qa3EZLu67bQm/enj45OWliY9/PXXX5tXOGnSpODg4Ly8 vPz8fElcarrTPShGjCqx3iN7Tg9ty82PuO7BrelpZt0qtWbtdo060DwiSqvkHCgvL9dtwPvvv+/t 7S3tVGJ2u3btlK+2Wveb7tGs0dEBAAAAGiMi9u7du3///o6OjmFhYTdu3FCua+fPn6+scPbsWQcH h+TkZLmezs7OdnJyKigokPIxY8YoWUKtymhNqS0iIkJZZ9u2bZ6ensqyPV//27x5s1x5m6cI7RdN tZvLzc2Vtqk3r1JSUuTt+fPnbXb2nt73VI8cOdK+ffvt27ebtM3oy67m29XtFpv+tPklm1GFFy5c kAWJH0q5+h1Ro4Oiy6gSbUQ0Pz10W25+xI0Obo1OM+vjaLRdkyNiHhElBLZq1UpCpm4DJIh26NBh //79subbb78tSdum33T7pEZHBwAAAKjPiGjyuJqZM2dmZmZevnxZNyalp6fLVeyIESNG/ejgwYNS LlftQUFBrVu3Xr58+e3bt03WtK4tMTHRw8Oj2sCwc+fOgICAp6r06tWrphFRuzmlbeo+5ufny9sD Bw5oM6HNWwkPbm5uq1atMm+bURvs3K51t6iUz3711VfaQm2FEk6sy9V0Z3RQdBlVoo2I5qeHbstr FxFrd5qZbNfkiJhHxN/+9rfK/yNg1IBf/OIX0dHRstCvX7+kpCTdM0H3aNp5dO4vHsBAVwNgCAOM ygctIho979X6t4i6MenMmTNyFbt3717dj8u1tYuLy8aNG03WrGlEzMnJkUiwb98+Wd6+fbt1RIyN jVWWJbPVKCKePHlS2vbJJ58o5Xv27JG3p0+fNo+I169fl43OmjVL+QKhSduM2mDndnUjotKfyk/a VEYVFhQUODo6Hjp0yCbdmR8+G0aVmERE3fp1W15tRNQ9uLU7zUy2a3JETCLi3bt3JR+++OKLJg2Q vNehQ4e0tDQ3NzeLxWLTKt0+qdHRub94jDtdDYAhDDAqiYj/d7UdGBg4btw45ct+N2/eVL6MmpmZ KdfBkp0CAgLUfw9Ad02jLLRkyRJZWdukrKwsiWG5ubmSWObMmaOmlLCwsIiIiLKysoSe0AAsAABI K0lEQVSEhE6dOqkpwqYe3c1VVFQMGTIkMjJSmlRSUhIeHj506FAl+BlFRNm74ODgESNGKDevzNtm 1AY7t6sbEYXU6e/v/+WXX8ryqVOnKqoYVSjlUVFRxcXFR44cGThwoNo23YMiWeWNN97QbtGoEqOI aFS/tuUmR9zk4NbuNLNhvV2TDtSNiLdu3crOzpYzQSLi999/b9IAqeSxxx7r3r37K6+8ons26vaJ blVMr/wlA8AQBsCobNIRUeLQlClTnJycfHx8XF1dlW/l9e3bV/KDXDeHhITIZbTJmkZZ6Pjx41KJ l5eXclPOWmhoaNu2bXv27Ll169auXbsqT4XJyMhwd3dv06aN/Nf169erKcKmHqPN5eTkSBiQ+NGx Y8fhw4erN46MIuLnn3/u4ODQvn37R3+kfI1Qt20mbbBnu0YR8dKlS7KaNKNLly6enp7K01aMKkxL S3N2dpbOlxwSHx+vpjvdgxIUFPTkk09qt2hUiUlE1K1ft+UmR9zo4NbuNLNhs12jDrQZF9J4R0fH du3aSVReunSpdXjTbcC9qi+jykfOnj2rO5R0+8SoKqZX/pIBYAgDYFTen4hov9LS0itXrliX3Khi z5om5LrZ+vmTqqKiIqX8ZhWlsLy8vKSkpEb1aKs1qsF+um0zb0Ndtvvdd99pP6tbocViMep5m4Ny 7Nix8PBw3TVNKqnR6WHUcqNeMjq49XKaabdb9zOhpg0w6ZPaVcX0yl8yAAxhAETE2jP/pWZZYQkn UIvy1ltvKY/fBOo+gYCuBsAQBhiVzS8i6rKU3jq2clOySzD/pxcAAAAAtNyIeDXjy09Hz//QaYSE Q+VFLwMAAABAy4qI1rcNbV70MgAAAAC0lIiovW1IRAQAAACAlhgRL398yCgZ8uLFixevpvbizx7Q TPG4GoBR2Wwi4r2q572eivlLmu/PkrsH7/SYxhUJgBpNIHQCXQ2AIQwwKh+0iKgsXM3IPvzs6x+1 H53aZ8ZH7UYTEQFw0UNXA2AIA4zKlhsRFWWFJTY3FTmBAHDRQ1cDYAgDjMoWGhFVyk1FZjQAXPTQ 1QAYwgCjsgVFRPNfapYVlnACAajdBAK6GgBDGGBUNr+ICAAAAAAgIgIAAAAAiIgAAAAAACIiAAAA AICIaIbfTwNgAqGrATCEAUYlEfEHPIUZABMIXQ2AIQwwKomIzFkAmEDoagAMYYBRSURkzgLA9EpX A2AIA4xKIiJzFgCmV7oaAEMYABHRDL+fBsAEQlcDYAgDjEoiIgAAAACAiAgAAAAAICI2qMrKyrt3 7z6QvWyxWCoqKugrDuWDgdMPAACAiFgbycnJhw8ftn/9HTt2dO7cWVlOTU3Nzs5+YHp57Nixa9as qccKrfuqXjxgHd5kD2W99PN9P1j1fvoBAADggYqIRr/U/MlPfrJ8+fLaXXfOnj07Jiampi25ePFi Xl5ec8wVNW153a/RbbZYuw5vyurrZLCpp44RsV5O7Pt+sOo3IvIAhkZDVwMMYQCMykaKiEbPe61L RKydadOmLV26tDlGxJq2/AHuq/pSXztoU0+93xBujgerfiMij3FvNHQ1wBAGwKhsQhExKioqLi5u 7dq1Xl5eI0eOVL+AWlhYOH369C5dugwePHjZsmXqdaesHx8frywXFRXNnTvX3d39kUcekdWUQqlt 9OjR3bp1mzBhglLbunXrOnToIDX4+vru2rVLSq5duzZjxgwp6devX3p6uraFujVLoWzd1dXVzc0t Ojq6uLjYehdWrVrVs2fPIUOG5OTkJCYm9u3b94knnkhNTVXXeffdd1966SX5eJ8+fVJSUrS5Qtsq O1tu1FfWtN2iu5vaLdp0uEkPaA+iEaPekPLY2NgFCxZIA65fv667s1lZWUFBQVIo27p69apR1xm1 SruD1fZSSEiIHFBlOSEhQbpatx7lUGo7waTTrHdW7WeLxeL7r1599VU7T+z6Olg1Ov+NTr9qRxkX PfwlA8AQBhiVRESdiCgX1j169Fi8ePGJEyfkgjI0NFQpnzRpUnBwcF5eXn5+vlyjq9ed1plKrpV9 fHzS0tLu3Lnz9ddfK4VJSUlHjx4tKyuLjIycNWuWlJSWlk6cOHHhwoVyzSrlygfnzZsn1+WbNm3y 9/fXtlC3ZqkkMDDwmyrjx4+fPHmy2iS5aH799dfPnTs3atQoyTw///nPv/322xdeeGHYsGHqOh4e Hu+8886xY8fk4rtr167l5eXa3bFplZ0tN+ora9pu0d1N7RatW2jSA7oH0YhJb7i4uGzYsEFidkVF he7OSqqRZFVZWSm9Lc026jqjVml3sNpe8vPzU3NXTEzMoEGDjDpKtxNMOs16Z23+zwLFe++99/DD D2dkZNh5YtfXwarR+W90+lU7yrjo4S8ZAIYwwKgkIupHxIiICGV527Ztnp6esnDhwgUHBwe5QlXK rb+9pl4Enz17VtYx+eXV5s2bvb29lWXr7+MpH0xOTpYr3ezsbCcnp4KCAusP6tacm5srhep9p5SU FHl7/vx5pUmLFi1Syl9++eXBgwcrT7bcvXt3u3bt1GbLf1KWi4qK5LOHDh3S7o62VdW23KSvzLvF qAONvj9p3gPag2geEY16Y/78+eaHacyYMUogsTle2jWNWmXPlzOtTx7diKjbUdrNmXeaurP39L6n euTIkfbt22/fvt3OE7u+DlaNzn+j06/aUcZFD3/JADCEAUZlS4yI9jyuxvrKODEx0cPDQxb2798v 15eXL182iYjp6emyzldffWVT+c6dOwMCAp6q0qtXL+2VtPLBESNGjPrRwYMHrWvQrVkpVJuUn58v bw8cOGCzCytXrgwMDFSWU1NTrSOidQDo3r37u+++q90dbauqbblJX5l3i1EHGqUOO3tAPYjmEdG8 N0w6RMJhUFBQ69at5RS6ffu2yZpGrTKJiLonj/0RUbs5OztN+1bSl5ub26pVq+w/sevrYNXo/Dc6 /aodZXWZQFDv6GqAIQyAUdlIEdFItRGxoKDA0dFRubNkFBHPnDkj16CbN2+2rjknJ0fCw759+2R5 +/btulfSygf37t1r1Dzdmk+ePCmFn3zyifJ2z5498vb06dO1iIiFhYXyWdkp7e5oW1Vty036yrxb dHfTJHXY2QM1jYi6vVHtYZJw4uLisnHjRpM1axoRjU4eiYixsbHKsmS2GkVEOzvN5u3169dlo7Nm zaqsrLT/xK6vg1Wj89/o9Kt2lAEAAICIWIOIKIYMGRIVFVVcXHzkyJGBAwfq/hZx3Lhx/v7+X375 pSyfOnWqoqIiKytLrqRzc3PlynXOnDnqp5YsWSIrqw2QFCdvlS8r3rx588aNGzYt1NYspEmRkZGy cklJSXh4+NChQ5UreDsj4oQJE+SD5eXlb7zxRteuXZWNWn9Wt1X2tNyor1RG3aLdTe0W1Rba2QPW B1FihuysbkSstjeMdjYzM9Nisch2AwIC4uLiTNY0apXNDlbbS2FhYREREWVlZQkJCZ06dVIjolFH WW/Ozk6zfit7FxwcPGLECOUeqXnb6vFg1fr8Nzr9qh1lAAAAICLWICKmpaU5Ozs7OTnJpWp8fLxu RLx06ZK8dXBw6NKli6enp/LEjtDQ0LZt2/bs2XPr1q2SPZQHexw/frxv375eXl7KfRi5zp4yZYpU 7uPj4+rqqnwBz5puzTk5OXJZLCGhY8eOw4cPV+7J2B8Rp06d+vjjj8sOuri4qHdjrD+r2yp7Wm7U V9Z0u0V3N222aN1Ce3rA+iAGBQU9+eSTuhGx2t4w2llpm+ygt7d3SEjIrVu3TNY0apXNDlbbSxkZ Ge7u7m3atJH/un79ejUimnSU9ebs6TTrt59//rkckfbt2z/6o+joaDtP7LocrFqf/0anX7WjDAAA AETEmrFYLFeuXKl2te+++66kpMS6pKioSLkhdrOK9YWvUq4oLS01r19bs1K5trBaynV5ZWWltEH9 9qAu3VZV23J7+sqoW3R302aLteuBY8eOhYeH16U3dHf2RhU7u86I0Q7q9lJ5ebnRLpt0VN1PGzuP YL0crLqc/yanX40OCgAAAB7wiMjvp21CUUvb67feemv//v30BkyUFZYwgdx3dDXAEAbAqGykiMhT mFXvv/9+7f71cHoDDzaZJfb9JPry3w4xgdzfo0AnAAxhAIxKIiKAJjGHyuvDVsN3OI/NfvEd65uK TCD8JQPAEAYYlUREAC0xIqqvD1sFqDcVmUD4SwaAIQwwKomIAFp0RLS+qSgLJr9UBH/JADCEAUZl s4yIvHjx4lWX14WPPuUvTUPjWRcAQxgAo7KRIiIA1Oj/SPrYL+KzGSv+1n9Wap8Z37yRwF1EAAAA IiKAFhcRd3R8OnPyS5lTlyQ9Gpg18+Urfz9caSmncwAAAIiIAFpcROS2IQAAABERAH6IiNw2BAAA aCkRkd9PAzBnctuQCaTR0NUAQxgAo7KRIiJPYQbABEJXA2AIA4xKIiJzFgAmELoaAEMYYFQSEZmz ADC90tUAGMIAo5KIyJwFgOmVrgbAEAZARDTD76cBMIHQ1QAYwgCjkogIAAAAACAiAgAAAACIiAAA AAAAIiIAAAAAgIhoB34/DYAJhK4GwBAGGJVExB/wFGYATCB0NQCGMMCoJCIyZwFgAqGrATCEAUYl EZE5CwDTK10NgCEMMCqJiMxZAJhe68hisVRUVNDVorKy8u7du4wCgNkSYFQ+aBGR308DaIgJJCUl ZcuWLVu3bk1KSsrNzW1SzS4oKJC2XblypRafHTt27Jo1a2q96dTU1Ozs7Dp2da0r0Y15u3fvfu21 1xYuXPi73/1ODtb3339v52d37NjRuXNnRgHA5RbAqHzQIiIANIRhw4YNGDAgPDy8d+/erVq1Sk5O brRNX7x4MS8vz2SFlStXOjg4rF69uha11TEizp49OyYmpo57VLtKtIqKigIDAz08PF555ZXf//73 S5YsefLJJ9PT04mIAAAQEQGg/iPiihUrlOXx48cHBwc32qanTZu2dOlSo/9qsVh69Ojh6+vr6elp z1dGbWqrY0RsiD2qtfnz53t7e1+7ds26sLKykogIAAAREQAaMCIuWrTIy8tLFqKiomJjYxcsWCDR 4vr16xJOZsyYIcv9+vVTb15lZWUFBQVJoXzk6tWrSqHumlJbXFzc2rVrZc2RI0cePnxYCtetW9eh QwdZU0Lgrl27tA1LTk7u3r37F1984eDg8PHHH6vlISEhiYmJynJCQsL06dN1a1Mios1G71XdkZP2 uLq6urm5RUdHFxcXq4203mV5Gx8fryRV33/16quvSrns0ejRo7t16zZhwgSjPVIrMd+utnOsyZqt WrXaskX/azZG1RYWFkrPdOnSZfDgwcuWLVMjou4BAgAAREQAsI2Ip0+fdnZ2fv7555V85eLismHD hpycnIqKCklB8+bNk+C0adMmf39/5YOSZyRTVVZWnjt37s6dO0qh7ppSW48ePRYvXnzixAnJJ6Gh oVJYWlo6ceLEhQsXSmgpKyvTNmzKlClKw4YOHRoWFqaW+/n5qbkrJiZm0KBBurXpblTIaoGBgd9U GT9+/OTJk9VGWu+y9U3Iaz967733Hn744YyMDClMSko6evSobCsyMnLWrFlGbVArMdmubjtVn3/+ uYTkf/zjH7qHz6jaSZMmBQcH5+Xl5efnS6hWI6LuAQIAAM0yIvL7aQANMYFIROzdu3f//v0dHR0l id24cUPJLfPnz1dWOHv2rESU5ORkCSHZ2dlOTk4FBQVSPmbMGCWEqFUZrSm1RUREKOts27bN09NT WTb5Wub58+fl45JaZXnLli0PPfSQeqNSNyLe0/uiqXajubm50kL1pmVKSoq8lW3Z7PI9ve+pHjly pH379tu3b7dp6ubNm729vdU2/GJEkLYS8+3qdo5q9+7dsvLFixe1vWRU7YULF2QhLS1NKVe/aGp0 gABwuQUwKptlROQpzAAaYgKRiDhz5szMzMzLly/rBqT09HTJFSNGjBj1o4MHD0q5hMOgoKDWrVsv X7789u3bJmta15aYmOjh4VFtRJT1H3300cVVnnvuOan2zTffrGlE1G5UaaG6p/n5+fL2wIED2kxo 81Zyl5ub26pVq9SSnTt3BgQEPFWlV69eahumOrhpK7Fzu9ad839/Go8fl5WVnrRhVO3+/futy9WI aHSAAHC5BTAqiYgAmF7/LyKqv0XUDUhnzpyRXLF3717dj0sgcXFx2bhxo8maNY2I5eXlss6vfvWr TT8KDg7u16+fGhFjY2OVZclsNYqIJ0+elBZ+8sknSvmePXvkrXKv0iQiXr9+XTY6a9Ys9QkxOTk5 ko337dsny9u3b682Itq5Xd2IWFZW1rVrV+ULwDaMqi0oKHB0dDx06JBNRDQ/lAC43AIYlUREAEyv 1UdEERgYOG7cOOU7pTdv3lS+jJqZmWmxWCQ1BQQExMXFmaxplIKWLFkiK2ublJqa2q1bN/X3jUJ5 aI1yyyssLCwiIkKCU0JCQqdOndSIaFOb7kYrKiqGDBkSGRkpDSspKQkPDx86dKgS/IwiouyjBNQR I0Yod0oVWVlZEhFzc3MljM2ZM0f9pd///nMUDs7aSuzcrm5EvFf1XVYnJ6e3335bwrNS2+7du0+d OmVSrZRHRUUVFxcfOXJk4MCBagt1DxAALrcARiUREQDTaw0iogShKVOmSErx8fFxdXVVviHZt29f CR7e3t4hISG3bt0yWdMoBR0/flwq8fLyUm7HqZ555plly5bZNElyTnR0tCxkZGS4u7u3adMmNDR0 /fr1akS0qc1oozk5OZKjJFt27Nhx+PDhyq08k4ioPC2mffv2j/5IaYZsvW3btj179ty6dWvXrl2V J9ZIG9wc2uq2wZ7tGkVE8V//9V+ylXbt2j3++OOyjvS5RESTatPS0pydneVA+Pv7x8fHqxFR9wAB 4HILYFQ2y4jI76cB3N8JpLS09MqVK9YlN6rYs6aJS5cu2fPPHlorLy8vKSmpS21FRUVGNdhPKlG2 dbOK2tUmbajjdi9evPjNN99o/0VE3WotFovRUajRAQIeMGWFJVxuAS3tGuaBjYgAAACoo786DNv3 k+jLfztEVwAgIgIAABARh8nrw1bDdziPzX7xHfObigBARAQAAHjwI6L6+rBVADcVARARAQAAiIjW QZGbigCaYUTk99MA6jKB6F4V8eLFixcvm9eFjz7lrwbQpK5hiIhm/6cXpwgAJhC6GkAdB6n162O/ iM9mrPhb/1mpfWZ880YCQxjgDysREQDTK+hqoMVFxB0dn86c/FLm1CVJjwZmzXz5yt8PV1rKGcIA f1iJiACYXkFXAy1ukFrfNrT58SFDGOAPKxERANMr6GqgZQ1S69uGDGGAP6zNOCLyuBoATCB0NYA6 Mn9mKUMY4A9rc4qIAAAAAAAiIgAAAACAiAgAAAAAICICAAAAAIiIZvj9NAAmELoaAEMYYFQSEX/A U5gBMIHQ1QAYwgCjkojInAWACYSuBsAQBhiVRETmLABMr3Q1AIYwwKgkIjJnAWB6pasBMIQBEBHN 8PtpAEwgdDUAhjDAqCQiAgAAAACIiAAAAAAAIiIAAAAAgIgIAGiWLBZLRUUF/QAAABovIvL7aQAN MYGkpKRsqfL3v//9zp0797edBQUF0pIrV67c32b8+c9/3qLn5s2bRh8ZO3bsmjVrmKuBB3i2BMCo bHIRkacwA2iICWTYsGEDBgwIDw/38vLq2LHjZ599ZlLPxYsX8/LyGq6dK1eudHBwWL169f3trmXL ls2t4ufn5+LiMvdHxcXF1UZE5mrgQZ0tATAqiYgAWkpEXLFihbL81FNPzZ4926SeadOmLV26tIEa abFYevTo4evr6+np2US+tCk7O3z4cHvWJCICXIwCYFQSEQE8aBFREuAzzzyjLF+7dm3GjBmdO3fu 169fenq6lKxbt65Dhw5SIilu165dUhISEpKYmKisn5CQMH36dGU5KioqNjZ2wYIFsvL169flbVxc 3Nq1a728vEaOHHn48GHdliQnJ3fv3v2LL75wcHD4+OOP1fKioqK5c+e6u7s/8sgjgwcPNinUtllk ZWUFBQVJoWz96tWrJoX2RETZruyOq6urm5tbdHS0el9RjYjvOwyR5Q8//NCkSXZ2CAAuRgEQEZmz ANyfiChJRsLeww8//D//8z9K+YQJE+bNmycBb9OmTf7+/lJSWlo6ceLEhQsXysplZWVS4ufnFx8f r6wfExMzaNAgNS+5uLhs2LAhJyenoqJC3vbo0WPx4sUnTpyQvBQaGqrbkilTpihhdejQoWFhYWq5 tMTHxyctLe3OnTtff/21eaFNm4VkMMmrlZWV586dU39sqVtoT0SUHggMDPymyvjx4ydPnmwdEaWq Jx2cpYusG69tkp0dAoCLUQBERDP8fhpAQ0wgEhHbtGnj6Ojo4OCwb98+pfDs2bPyNjk5WYJQdna2 k5NTQUHBPc0XTU0i4vz589XV5G1ERISyvG3bNk9PT20zzp8/L1s5ffq0LG/ZsuWhhx5Sbu4pLZHK rVc2KdS2ecyYMcHBwTY/odQtrDYi5ubmyiaUO6j3qp70I2+l5co+rl69es6cOWP6+peXl5s3yZ4O AdDUZksAjMomFxEBoCFIRFyyZInkMW9v71/+8pdKYXp6umSbESNGjPrRwYMHaxQRlW9dat8mJiZ6 eHhomyErPProo4urPPfcc7L1N998U23JV199Zb2ySaG2zZIDg4KCWrduvXz58tu3bysr6xZWGxGV TVy+fFl5m5+fL28PHDig7KOsKW+zsrKqbZI9HQIAAB5sREQATTciKl/v3L9/f6tWrVJTU2X5zJkz km327t1rs7I2IsbGxirLq1atqnVELC8vl8Jf/epXm34UHBzcr18/tSWbN2+2Xt+kUNtmhQQ5FxeX jRs3VltoEhFPnjwpm/jkk0+Ut3v27JG3yp1PZR9ffPFFNzc3aYl5k4iIAACAiAigqUdEIQlHIpPy ZcjAwMBx48YpX8W8efPmjRs3ZGHJkiVSqH42LCwsIiKirKwsISGhU6dOtY6Ikku7detm/ZtA5aE1 yj032aK/v/+XX34py6dOnVIedqpbqNvmzMxMi8VSWVkZEBAQFxen1K9bWG1ElK0MGTIkMjJSai4p KQkPDx86dKhUou6jLEdFRfXu3VvpQ6MmEREBAAAREUAziIi3bt3y9fWdOHGiRB0JOVOmTHFycvLx 8XF1dVW+Tnn8+PG+fft6eXkpv1rMyMhwd3dv06ZNaGjo+vXrax0Rn3nmmWXLltkUDhw4MDo6WhYu XbokNUhi7NKli6enp/KkHN1C3TZLgzt37uzt7R0SEiI7qFSuW1htRBQ5OTkSCyUPd+zYUf6TcgvR eh8leUqdAwYMkAxp1CQiIgAA4HE1AO6naieQssIS3fLS0tIrV67YFEo8U//dwvLyciULNbTvvvtO uyHdQm2bb1SxWU230E5FRUVGe63b1brdCKA5zpYAGJVNKCLyFGYA9T6BWEpvHVu5KdklmBmmobsa AEMYAKOSiAig6U6vVzO+/HT0/A+dRsh/Ul70En/JADCEAUYlERFAy5perW8b2rzoJf6SAWAIA4xK IiKAljK9am8bEhH5SwaAIQwwKptxROT30wBq7VDkaqNkyIsXL168+P/LgCaLx9UAQEMpKyw5FfOX NN+fJXcP3ukxjasiAAAAIiIA3LuakX342dc/aj86tc+Mj9qNJiICAAAQEQG0dNqbivQJAAAAERFA S6fcVCQiAgAANLOIyONqADTcBFJWWEIvNU5XA2AIA2BU3uMfvQBwfzGB0NUAGMIAo5KICABMIHQ1 AIYwwKgkIgIAEwhdDYAhDDAqiYgAwARCVwNgCAOMyhYREfn9NAAmELoaAEMYYFQSEQEAAAAAREQA AAAAABERAAAAAEBEBAAAAAAQEe3A76cBMIHQ1QAYwgCjkoj4A57CDDScmJiYpx9oTzg8Eh0dvQYN b6aDO50AMIQBMCqtyWWYXI+9++67RESg2Rg4cKADAAAA0GAGDRpERASaDRmxytD96YNI2bWxY8e+ ioY308GdTgAYwgAYldZ69epFRASamaefflrJh8UPohUrVsjerVmzhgPdCJirAYYwAEal7qXm2LFj 6zki8vtpgIhIRGz6mKsBhjAARmUjRUQATS0iLlq06Jlnnrl8+TIREQAAAEREoKVHxP79+8unLly4 QEQEAAAAEREgIjaPiLhw4UIiIgAAABERQONFxG+//XbWrFlubm7Ozs6jRo3au3evso5R+aRJk/r0 6bNnz56hQ4fKf5o2bVpubm5D5MOjR48qTzQlIgIAADxQEZHfTwNNNiJeu3bNz8+vVatWy5cv/8Mf /uDq6tqmTZvDhw8blaufffLJJ3/5y1/27t1blletWlXv+fDEiROPPfaYVO7q3PncuXMc6EbAXA0w hAEwKhspIvIUZqDJRsSkpCRZGDhwoFIugVDePv/880bl6mezsrJkOSMjQ5aHDRvWQPmwV69e8Q4D OcqNg7kaYAgDYFQSEYGWHhHfeustWYiKilLKP/jgA3kbFBRkVG7zJdWCggJZfuihh7777rt6/H6p mg9Pnz7NBMJfMgAMYYBRSUQE0EgR8c9//rMsBAQEKOWvvfaavI2OjjYqt4mIyl1EDw+PesyHPj4+ aj5kAuEvGQCGMMCoJCICaLyImJ+f7+np+fDDD2/evDk9Pf2JJ55wdHTcs2ePUbn62Xnz5h04cGDS pEmy/OKLL9ZvPpTMqf7+kAmEv2QAGMIAo/JBi4j8fhposhFRlrOysgYPHqw8O7R79+5bt25V1jEq Vz77s5/9zLHK1KlTL168WI+/P7TOh0wgjYmuBhjCABiVjRQRATS1iKiVl5d36tQpe8rVeCkky9X7 82l4fikAAAAREcB9joi1uwPZEM+n4ZgCAAAQEQHU0sCBA5Xvgq5oLEFBQaNGjVq2bFm91LZw4UKl /eRDAAAAIiKAulLuvzV3Nr8/BAAAwIMcEfn9NNBwlLuIvXr1WtOcmeRDJpBGQ1cDDGEAjMpGiog8 hRlo5HH7IGECoasBMIQBRiUREQARkQmErgbAEAYYlUREAEREJhC6GgBDGGBUEhEBEBGZQOhqAAxh gFHZIiIiv58GiIhMIHQ1AIYwwKgkIgIgIgIAAICICICICAAAACIiACIiAAAAiIgAiIgAAAAgItqB 308DREQmELoaAEMYYFQSEX/AU5gBIiITCF0NgCEMMCqJiMxZQIN79tlnZdzK/zK9gq4GGMIAGJWN cKlJRASatDVr1si4ffXVV5leQVcDDGEAjMpGuNQkIgJExBYxvVosloqKigej0yorK+/evctc3ew8 SCchuBgFQEQ0w++nASJiQ0wgKSkpW6z84x//qMuGxo4dK535YHTajh07Onfu3ELm6mPHjn3xxRfW JQUFBXI+XLly5f427M9//vMWPTdv3mwJJyGa1GwJgFHZ5CIiACJiQxg2bJifn9/cH3388cdGa168 eDEvL+++R0R7mlEvH6xdRGymwsPDk5KSrEtWrlwpg2L16tX3t2HLli1Tzkw5S11cXNQTtbi4mIgI ACAiAiAiNkhElKtwe9acNm3a0qVL73tEtKcZ9fLBlhMR7969271799LSUrXEYrH06NHD19fX09Oz iXxpU47d8OHD7VmTiAgAICICICLWc0S8du3ajBkzJCD169cvPT1dStatW9ehQwcpkdiwa9cuKSkq Kpo7d667u/sjjzwyePBg66vztWvXenl5jRw58vDhw9otRkVFvfvuuy+99JKrq2ufPn1SUlLU8tjY 2AULFshWrl+/LvVLiazj5uYWHR2t3DXSNkPbVN222fnBwsLC6dOnd+nSRT4l3aIbEW3aqVtPVlZW UFCQFEo/XL16VW2Vdo9ESEhIYmKispyQkCANMOoQbYfrbl0VGhr6wQcfKMuLFi36t3/7N2U5MzNz 5syZ6mqffvrpxIkTrT+YnJwsofGLL76QcWF9Y1m3DfY3TLdbdAvtiYhG/alGxO+//16WP/zwQ5Mm SQ1xcXHmZywAAEREgHHbsiJiZGTk51XUHyJOmDBh3rx5Eks2bdrk7+8vJaWlpZIiFi5cKNfZZWVl yjo+Pj5paWl37tz5+uuv1avzHj16LF68+MSJE3I5LhFFu0VZx8PD45133jl27JhEi65du5aXlyvl Li4uGzZsyMnJqaiokM0FBgZ+U2X8+PGTJ082aoZNU3XbZucHJ02aFBwcnJeXl5+fL8lNNyLatFO3 Hgkbku4qKyvPnTsnbVAKdfdI+Pn5xcfHK8sxMTGDBg0y2pC2w3W3rlqxYoUSC+Uj0s9OTk5KjpJ+ kFCkriZxXW2AYsqUKfJZWRg6dGhYWJhabtQGOxum2y26hfZERKP+VCKiVCWFsqfWjdc2yZ4zFgCA JhoR+f00QERsiAlEIqK7u/voKlFRUVJy9uxZ6Y3k5GS58s7OzpZcUVBQcO9fv6iprCN5RhufIiIi lOVt27Z5enrqRqyXX35ZWS4qKpJ6Dh06pJTPnz9fKc/NzZVy5Xbfvapn6sjb8+fP6zbDpqlGbav2 gxcuXJBCiTrKOkZfNLVup7aejP94S8rHjBmjRE31UyZ7ZBIRbTZks1NGR0q1f//+Rx555O7du3v2 7JEENXDgQNkpSZtubm4nT55UV+vTp491U6VVUtXp06dlecuWLQ899JByc8+kDXY2TNstRoXVRkST /pR+W7169Zw5c6ZOnar8vw8mTbLnjEWLwuUWwKhsThGRpzADRMSGmEC0XzRNT0+X3hgxYsSoHx08 eNAmYinrfPXVV9r4pP4MLDEx0cPDQzdiWf9UrHv37u+++65NuVL/5cuXlbf5+fny9sCBA7rNsGmq Uduq/aAEKuuNmkREm3b+//buBayqMt/juAgjqXgX0RTKG+okWpkielQUkEC0QQ01M7XxmJY3POa1 0qy0J8sLmpYpOdnMZJpYiNcEFW1SoTpZeiRN8wIiCCoOolw6f32bNXv2Xnux2UDcvp9nPT57L9bl 3e9e73+tn/tmup0F1TrIfAk8AQEBTk5OM2fOvHXrlvEjMoiIZjsye1DWnilNbm5uvXr1ZLGJEye+ 9957L7744nPPPXfw4MGHHnpIW0Yik9nLj7LT+vXrT75n7NixsoslS5YYt8HGhll2i7WZhUZEg/6U fpMl5e7hw4cLbZItRyyqFC63AEYlEREAEdE8Ip4+fVp6Y/fu3QYRSy2zZs2aYkbEtLQ02Y6EMbP5 J0+elPlffvmlurtr1y65q17XsmyGWVOtta3QFVNSUhwcHNRLmjZGRMvtmHa1JBZXV9dVq1YZPyKJ iMuXL1fz582bpxsRdR+UtWfK1NChQ+X5dXd3lzQle2/VqtXUqVNNI/pbb701d+5c7W5eXp48a1Om TFn9L4GBge3btzduQ5EaZtotxjMNIqJBf6p+k4fZtGlTaYlxk4iI4HILYFQSEQEQEQuJiMLPz69v 377qvX83b968ceOG3AgPD5eZ2jJy28vLKyEhQW6fOnVKfe+ljRHR398/MzNT0sjixYsbNWqktm+6 rmytS5cuI0eOlD/JkmFhYV27di0oKLBshm5Tddtmy4qy01GjRmVkZBw7dqxz586FRkTL7XxYrcuv 974PJjc3Vxrs7e0dERFh/IiGDBkyYsSInJycDRs21KtXTzciWntQuo/CVGRkpGxThSvZRa1ateTu 8ePHtQV69eqlpWKxffv2xo0bm34mUH1pjXrNTbcNtjfMsluszSw0Ihr0p+o3uS1PpURi7c23uk2y dsRK6JWDk9rIxSgARiURESAiEhHvkqvq4OBgR0fH1q1bu7m5qffvSa5o27ath4fHnj175O6lS5fk 8lr6rWHDhu7u7uo7YGyMiAMGDGjXrp381dXVVXshyCwRJSUlyUW/5BkXFxfJBuoFIstm6DZVt222 rBgTE1O3bl2ZKZln5cqVtkREs+3Mv/dGU9mRrNuyZcuQkJDs7GzjRxQXF9e8eXNnZ+fQ0NBFixZZ i4i6D0r3UZhKTk52cHDQ0k5QUJD0vPbX9PT0Zs2amf6sxaBBgyyPB0nLo0ePttYG2xum2y26MwuN iAb9qfWbJE/ZZqdOnSRDWmuStSM2ICCgQ4cO1EYuRgEwKst1ROTz0wAR8XcuIFlZWZcvXzabKXnA NFFcvXpVXX/bTnuRRzalXvYxIBlGd/tmzdBtqm7bCl1RcoXlpmzvK62rb9xj4yPKy8uzsRt1H5Tu w7eFhKIxY8YUdS3dNtjYMN1usdZXtrB2hBTpqAa43ALKVk5aZuUelfzoBUBEROERkX4oD6ZOnRod HU0/AADK1ifVuu15bHTyjq+q1KUmEREgIuI3kZGRlj/yDgAAqnJElGlT9e5b6vomTl1q8KIiEREA EREAAKBKRERt2lTdu5K9qEhEBIiIAAAAsDMiVr4XFfm6GoCIWO5IAdEtvkxMTExMTExM5X86v3kf EVE/W3MdDxARKSB0NQCGMFD5hp7ptLPjiEODZ+3oMGx7m8Fyl1cRqVkAEZGLHroaAEMYqHIRcYtL n4NB0w4OCP+svt/hobMv7z1SkJvH7yJSswAiIhc9dDUAhjBQ5Yae9rLhicUbTF82JCJSswAiIhc9 dDUAhjBQ5Yae9rJhpRyVfF0NQEQsdyggdDUAhjBQbhl82rByjEp+9AIgIgIAAABERICICAAAABAR ASIiAAAAQEQEiIgAAABAWUREPj8NEBEpIHQ1AIYwwKgkIv6Gb2EGiIgUELoaAEMYYFQSEalZABGR AkJXA2AIA4xKIiI1CyAiUl7pagAMYYBRSUSkZgFERMorXQ2AIQyAiGiEz08DREQKCF0NgCEMMCqJ iACIiAAAACAiAiAiAgAAgIgIgIgIAAAAIiIAIiLKtYKCgjt37tAPAACg7CMin58GiIilUUC2bdu2 9p69e/fevn2bg8HYli1bGjRoQK0GqmC1BMCoLHcRkW9hBoiIpVFAunXr1qlTp7CwMA8PDxcXl0OH Dhls58KFC+fOnSuHD9DuhhV1xUIjIrUaqKzVEgCjkogIEBGrSkScNWuWuv3oo48OHz7cYDsDBw6c Pn16OXyAdjesqCsSEQEuRgEwKomIABGxqkREyUuDBg1St69cuTJ48GCJQ+3bt4+NjZU5b7zxRu3a tWWOp6fnF198IXNCQkI2btyolt+wYcMTTzyhbo8aNWr58uUTJkyQha9fvy53IyIiXnvtNQ8Pjx49 ehw5csSyGbLMihUrpk2b5ubm1qZNm23btuluKj09XebIMk2bNh09enRGRoZuwywbL2TdZ599tnnz 5nXq1HnkkUdsXzEtLU0eWsOGDWWtGTNm6EZErZ21qzlJO3W3c/jw4YCAAJkp/ZCamqq1yvIR2d63 lg/K2qMAwOUWwKgkIgIgItoaESVUSCCpUaPG1q1b1Xx/f/9x48ZJCFm9erWXl5fMycrK6t+//8SJ E2XhnJwcmdOxY8eVK1eq5ZctW/bwww+r276+vq6urm+++WZSUlJ+fr7cbdas2eTJk3/44QeJLqGh oZbNkGVatGixdOnS77//XjJPo0aN8vLyLDclDfDz8ztxT79+/YKCgnQbZtl4NbN169YxMTG3b9/+ 8ccfbV/x8ccfDwwMPHfu3MWLFyW56UZErZ3Lq3WSdupuR+KxpLuCgoKzZ89qH/vUfUS2963lg7L2 KABwuQUwKitbROTz0wARsTQKiEREZ2dnBwcH6YE9e/aomWfOnJG7UVFRklsSExMdHR1TUlJ+tXhb pkGMGT9+vGl8GjFihLq9bt06d3d33Yg1e/ZsdTs9PV32/tVXX5lt6ueff5b56uW+X+990Y7c/eWX X8waptt4NVMaabbfQlc8f/68zJQMppax9kZTrZ3S1dZ6r3fv3ipqamsZPCJb+lb3QVnbOwAutwBG ZWWLiACIiKVBImJ4eHhqamrLli0nTZqkZsbGxkqH+Pj49PyX+Pj4IkVE6VLT+KTd3bhxY4sWLXQj lukqTZo0WbFihdl81ark5GR19+LFi3L3wIEDZg3Tbbya+c033xhERN0V9+/fb7pTg4ho1k7L3pNw GBAQ4OTkNHPmzFu3bhk/Ilv6VvdBWds7AAAgIgIgItoUEdVnESULVa9effv27XL79OnT0iG7d+82 CFQqxixfvlzdnjdvXklFxLS0NNm7hDGz+SdPnpT5X375pbq7a9cuufvTTz+ZNUy38WrmmjVrDB6R 7oopKSkODg7qJU0bI6K13lMkAbq6uq5atcr4EdnSt7oPynjvAACAiAiAiGhTRBRTp06V9KLel+jn 59e3b1/1rsibN2/euHFDboSHh8tMbd0hQ4aMGDEiJydnw4YN9erVK2ZE9Pf3z8zMzMvLW7x4caNG jdQeTdfNz8/v0qXLyJEj5U+yZFhYWNeuXQsKCiwbptt4mePl5ZWQkCC3T506JVuzcUXZ6ahRozIy Mo4dO9a5c+dCI6K17Rw8eDA3N1ca7O3tHRERYfyIbOxb3Qelu3dJktKxDHYAAIiIAIiItkbE7Oxs T0/P/v37S0qRoBgcHOzo6Ni6dWs3Nzf17sfjx4+3bdvWw8NDfWoxLi6uefPmzs7OoaGhixYtKmZE HDBgQLt27eSvElO1F9bMNpWUlCQhSiKTi4tL9+7d1Qtulg3TbfylS5dka/JEN2zY0N3dXX0/jS0r xsTE1K1bV2ZKGFu5cqUtEVF3O7IjWbdly5YhISHS1caPyMa+1X1QunsPCAjo0KEDgx0AgMoTEfn8 NEBELL0CkpOWqTs/Kyvr8uXLZjMllqhXq0ReXl5mZmbxW6iSj0RT2bh6Gc1Aenq67k5NG2at8Vev XrVct9AVc3NzLTdVaFdbbufGPTY+Itv7VvdB6T58AFxuAYzKyhMR+RZmgIhY4gUkNyv7+7mro1wD y7zCmL04Vvm6GgBDGECVHZVERICIWAHKa2pcwr5e4zc5+sif1FS2LYyMjKwcP/JOrQYYwgAYlURE gIhYYcqr6cuGZhOHAWcyAAxhgFFJRARQVSKi5cuGRETOZAAYwgCjsgJHRD4/DRAR7fbVyFesJUMm JiYmJiYmpnI+EREBEBFLXk5a5qllf4/xfDKqSeDnLQbyKiIAAAAREUDVjYia1LjEI2MWbq7Va3ub wZtr9iIiAgAAEBEBVN2IqFi+qMhhAAAAQEQEUEUjoka9qEhEBAAAqGARka+rAYiIpVdActIyOQx+ n64GwBAGUNVGJT96ARARyx0KCF0NgCEMMCqJiACIiBQQuhoAQxhgVBIRARARKSB0NQCGMMCoJCIC ICJSQOhqAAxhgFFZJSIin58GSs/o0aNl3Pr6+s6vpCb2GTgfdDUAhjDAqCwLffr0kUvNMWPGlHBE BFB61LgFAAAASomvry8REagwVqxYIYN2zJgxCwAAAIASJReZcqkpF5xERAAAAACADiIiAAAAAKDk IiJfVwOAAkJXA2AIA4xKIuJv+BZmABQQuhoAQxhgVBIRqVkAKCB0NQCGMMCoJCJSswBQXulqAAxh gFFJRKRmAaC80tUAGMIAiIhG+Pw0AAoIXQ2AIQwwKomIAAAAAAAiIgAAAACAiAgAAAAAICICAAAA AIiINuDz00AZ+qRaN6Yyn3iCSrbTAAojpQAMYaYyHGtERKDCl9GCgm+YynAqNCLSRUXtNIDCSCkA Q5ipDMcabzQFKKNMRESuC0FhZKIUgCHMWLMeET/55JPvvvtOu3v+/Pm///3vHKwAZZSJiMh1ISiM TJQCMISrYkRs1arV4sWLtbsxMTEPPPAABytAGWUiInJdCAojE6UADGEiIhERoIwyERG5LgSFkYlS AIYwEVEvIh4+fDggIKBBgwYeHh6pqalq5pUrVwYPHiwz27dvHxsbq2aOGjVq+fLlEyZMkPnXr1/n WAcoo0REJq4LQWFkohSAIVzZImKPHj0k+BUUFJw9e/b27dtqpr+//7hx4yQHrl692svLS8309fV1 dXV98803k5KS8vPzOdYByigRkYnrQlAYmSgFYAhXtojYu3fvwMDAc+fOaX89c+ZMtWrVoqKiTpw4 kZiY6OjomJKSoiLi+PHjOcQByigRkS7iuhAURiZKARjCFTsienp6vvrqq9rd6OhoCY3qtoTDgIAA JyenmTNn3rp1S+bExsZKRPTx8en5L/Hx8Soizp8/n0McqKxlND8/8fbtowYL3LlzLC8vgbJb4k9Q 5ehYrgtRQQtj1alslAIQEYmI/6Ffv35BQUHa3cjISAl+pgscOHDA1dV11apVcvv06dMSEXfv3m22 ESIiUOZlVC5lYmJWTpkyYvHiKbGxa0u21mzevKRBg7oGC/j6PjZ//nOlVOmiopa+//5LMv3lL6/F x0deuRJr33aio1ckJPytTCLihg0LT5+OVrclbMtj+fnn7doTt3bty/Kv3R2r+mf9+gXffvuJhHmu C0FhNJ2Sk/fKAElJ2WvHoVvMylYiNadENlLa5whKAUppCGsXAHv2rMnJOVJRElqZD7cSiIiLFi1y cXE5duyY3E5JSenbt++cOXPUnw4ePJibm1tQUODt7R0REaFm+vn5yTLq3ac3b968ceMGEREoD2V0 wIBe3t4dlywJf+aZkKFD/dXM8+d3nj0bU9EjYrduHTt2bDN27CB5jB06tHR2rrFixUw7tjN8eODS pTPKJCL27v3onDnPqtuHD2+oVq3aG29MUncPHoz09HygOB0r/dOpU9ugoJ7yHN1/v+v16/FERFAY tWnu3D/LiHvllfG2HKtmNbOYlc2+mmPWhhIpXNbOEZQClPMhrE5wYWEBHh5NXVxqxcdHVoiIWObD rQQiYnZ2dlhYmFTPVq1aOTk5+fv7Z2RkqD+1bdu2QYMGLVu2DAkJkcXUTImRwcHBjo6OrVu3dnNz O3DgABERKPMympT0efXq1S9d2mM2f+DA3tOnP10JIuKMGc9od1evnisl6+OP36hAbzSVzpFHoW6/ +eZUebLk/KHuzpv358mThxczIs6aNUZuXLy4+7777MzPXBeiUl5f3rlzrFmzxp6eD7i7u9nyllGz mlmqlc3GNpTIZO0cQSlA+Y+I6gQn06OPth8+PLD858PyMNxKICIq6enpiYmJycnJZvNv3GO5fFZW 1uXLlzmmgXJSRs+f3+ng4LBu3XzTma+//kLt2jUl2snl0eefL5c5Eh569XqkceP6/v7eX3/9kVps 1KgBMn/hwuc9PJr26NFZm3/lSuwTT/g2bFjvkUfaS0LTIqLuRkwvpNLS4mSbbm6NmjZtNHr0wKtX 9xvvKDV13+DB/WT77ds/uG/f+4VGRJkGDerTqVNba6s/++wTb789XVv4hRfCJFWqBkREzNIaKYs1 b96kTp3a8gBtbIndEfHAgfWOjtWvXbv7+l5ISK+hQ/2lY9WbQuWct317hLW9S8e+8sr4adOekv5s 08Y9KmqpwRk0I+OAi0st9VzLg122bMaECUNlg7Jf3SclNLTvxo2vq408/3zYn/7UV2ut+l/PQ4c+ DAjoLluQp+zy5S8Neslsd1wXopxcX27d+k6TJg2PHNlYrVq1HTtWafNlGH700W8H/4cfviq1Trdm qspmWbUMqpzpQNBqjiRV2abppAqmZTm1bINZ4SpSdTU+R9gynJ9+eoBuObWjDlAKUMyIOHBgbzn7 Gxy6uucsa6NGtwjonj2LerVQHoZbiUVEABW9jM6Z86yUpDFjBmkf1btx41D//j4TJz4pxeXWra9l zpYtb3/77Sdye+TI4GHD+mshpFmzxpMnDz9+fLPUIIkNav7jj/cIDPQ5ezbmwoVdUkm1iGhtI1pE lJ36+XX78cfPZOrXr2tQUE/jHcm10bhxoVLg3n13jpdXG1si4tKlM2rU+ENuboLu6uvXL2jZsrkK YNIbNWs6q3dtmTZS1mrduoVks5ycIz/8sMXGltgdEWUvtWrdJxd80ioJh0ePfiwXrNI/cg6T5t28 +ZW1vUubW7Rwe+ed//nf//1UzlKNGtVTj9qsf+S5kLORnBolTKovFpIVXV0bLF485dSpbXl5CbpP ipx3VSyU5smWJcSqc6ccM3KtKTfkWlPOQNLmn3/ern0IxFo7TXfHdSHKSWEMDv4vdX3ZtetDQ4b4 afM7dmyj5S6pJw8/3E63ZlqrWgZVznQgmNYc2aaa1qyZJ+VLfTzJspzqtsHu6mp8jrBlOK9b94pu ObWjDlAKYHdElOEgcU4GzmefvWNw6Oqes6yNGt0iYHkY23e1UObDjYgIUEb/41PdTZs2at68ifZm fWtvWFq9eq6UIa3KjBjxuLr9wQevuLu7yY1fftkpGUa9umXtjaZmG1EXMWfORMuK6j+/VZPk7rlz O6zt6PTpu8tv3fqO1O6EhL9JSklO3ltoRJQQWL16dbl+0l1drrFq164ZF/eBLPn229Ml65o1Uq1l 9vEeW1pSnG80VflNkt4f/9hK7srTJJ3wl7+8JvMN9i5tnj17rPZfobLM4cMbLPunc2fP7t295Gzx 4YevqrOLrDh+/GC1gLUnRbqoTp3aEil37nxXzpqyEXmi5UwjR9GJE1vVRyjVfxMU2kumu+O6EOWk MMpBLodoUtLncvv991/6wx+ctBcWrF0dWr7R1LJqGVc504Fg+T7Vo0c/rlXrvsjIBQbl1NqbXYta XQs9R9gynHXLqX11gFIA+yKis3MNiVv3vi9ztfGZyPKcZTBqDCKidhgX52qhbIfb7xcRc7Oyk3d+ dXLJx8fnr5V/z2/eJ3M4poFyFRFlunp1/4ABvWrWdJZCY3mpsW3bMm/vjo8+2l6mBx+83/Ii5qOP Xm/R4u61hVQoKUnaO+lNI6LxRvbte990xQsXdsnd/fvXWduRWt7Hp1PPng+r6eDByEIj4ssv/7e6 nLK2+jPPhIwePVButG//4JYtb+s2MjHxP74k0JaWFCciLlo02curzapVsydMGCp3n3wyYOzYQU89 FbRkSbjB3s0uMZs0abh8+YvW3ocjpz2JfAsWTDBb0dqTcufOsXr1XOSvEyc+uWbNvBdfHP3cc0MO HFj/0EOt1ZJyopUE6+TkOHPm6Ozsr21vJ9eFKA+FUY7J+vXrTJ48XCYZbnLovvXWtKJGRGtVq9Aq Z3lXRqhcMs6b92fjmmytDUWtroWeI2wczpbl1L46QCmAfRExPHzk5ctfykl/0qRhxudra+cs3VFj EBHNzp72XS2U7XD7PSJiTlqmxMItLr1lZ6bTFpc+381YIX/lyAbKT0RUVyHap25MLzVOndomdVP9 J1xk5ALjiJicvNfBwUF7wUqLiIVu5MSJrbL3vXvfU/N37nxX7qr/xdfd0U8/fSEL7Nr1ru1fV3P7 9lE5VUyd+pTB6lJSa9euuX17hFyQab8noTVAraXe4q9NtrSkOBHx668/ki718+umvmhn2bIZbdt6 NG5c//jxzQZ7N+20K1fu/jKtPBcGH9WQM6gKeKYrGjwpQ4f6S9+6u7vJGVQWaNXqbseanXXkbOrq 2mDlytk2tpPrQpSHwpibmyBFZsqUEe++O0dNgYE+ctWlRUQZg9pXRhUpItpY5czuXrsWLzsdNqy/ 9ss01sqptTYUtboWeo6wcThbllP76gClAPZFRHWCi4v7oHr16tHRKwo9X5ueswxGjbUiYHoYF+dq oWyHW6lHxNS4xC9aBKtMuKP9oMRJM4/PX/jdjHm7Hh6yyam7zIxq3D9551cc3EDZltEff/xMqqf6 ENr69QvkskP9Cl94+Mi+fbtqH+OW+WfOREv8e/rpYO1VQWvXFl26dBg1asDVq/uPHv24c2dPtXyh G8nLS5AVR44Mvn49PiPjQFhYQNeuD2lvfdTdkaQmaaR6Z0hW1mHL32zQIuI///mPhIS/yXWeRMTM zIMGq8seH3igWZMmDbWfmjBrgKzi5dXm2LG/yu3/+78o9T7+QltSnIgoF6x169aWQn/+/E71fjO5 bXolp7t3abO/v7f0pKy+aNHkRo3q6faPnEHlXCKHQYcOLdX3o5o+WIMnRY6WevVcunf3ktu3bn1d q9Z9cvf77z/VvrdGNitLent31L4o1Vo7iYgoV4VRLiUbN65v+kNq6ktr1H/ADxniN2LE43LMf/jh q3LMa1eHpjXTWtWyscqZ3pVxJIXLx6eTemXDuCZba4Md1bXQc4Qtw1m3nNpRBygFKE5ElGnq1Kck +6m3WeoegZbnLINRY60ImB3GdlwtlIfhVroRUfKhevFQAmHGN5+b7fvaiR17uw+Tv25y8rkUHc/x DZRhGY2KWioX93Xq1G7b1kPq6V//ukjNl2t9mePh0VT9R3VoaN/77qtx//2ua9e+LGFDfTuCtWuL 7dsjJNI4OlaX4hgRMUu7fCl0I6dObZMSLAXXxaWWZA/133UGO5JyHxz8X7Kj1q1buLk1Uu8AMTtD yIWdg4NDzZrOElanT3/atBxbW/3ll/9bVtF+sN6sARcv7pa7stmGDeu5u7upr4UotCXFiYjqxQHt hQI5jclTNm5cqPEDkUYOHx7Yrt2D0l1yatT+K9Syf0SbNu7PPx924cIuy5OHtSfl0qU90ksSPtXd oKCesi9tLTl45HmXQB4S0kvyuXE7iYgoV4Vx0KA+Zm9Ql0kKiHoTV2zs2ubNmzg715CC9sYbk7Sr Q7Oaaa1q2VLlTO/+4x8fyQiVIV+/fh01qWbollODNhS1uhZ6jrBxOFuWUzvqAKUAxYyIchry9Hyg f38fyVG6R6DuOcvaqLFWBMwOYzuuFsrDcCvFiJiTlrmtaaDs4Jtps/PvWP0pIfmrei3xVko6hzhQ hmU0Ly/hp5++0P0dHilw2rddpaXFqdtZWYdlMn6DhMSYlBSdD2HbshFZJiPjgO2/4XPjxiHdfZXq 6unpOo003lRxIqIdD+TatficnCNyOpQnUXt/mt1TUZ8UmSSN676aWqQO57oQZVUYDabc3ARrw8G0 ZpbsgLK9nBq0wb79Gpwj7C6/RV2RUoCSPXVaHoHWzlm6o8agCBTzaqHMh1spRsTvX1qjXj/MzT5q 3Ig9j4XJkt/NWMEhDpTbMsr0+/wcLU8Q14WgMDJRCsAQrlhjzdaImJuVrd5iavn+Usvp2okdm5x8 trj0uZN5g6McoIwSEZm4LgSFkYlSAIZwZYuIl6LjZdM7O4ba2I49j939UOL5zfs4ygHKKBGRietC UBiZKAVgCFe2iHhyycey6cRJM21sx3cz5snyshZHOUAZJSIycV0ICiMTpQAM4coWEY/PXyubPj5/ oY3tkCXvLb+WoxygjBIRmbguBIWRiVIAhjCvIr7Eq4gAZZSyyxPEdSEojEyUAjCE+Syi+izicD6L CFBGKbs8QVwXgsLIRCkAQ5hvNOUbTQHKKGWXJ4jrQlAYmSgFYAhX6oj4693fRXxP/S5i/p1Cfj12 b/en+F1E4Hcro0xlPvEElWynARRGSgEYwkxlONaKEBFz0jK3NQ2SHXwzbbZBSvxm2lxZJqpx/1sp 6RziAAAAAFCBVCvS0qlxiVtc+qjXEi3fcXrtxI693UfIXzc5+VyKjqdzAQAAAKAyR0SVEqMa91ev V+7sGHpo6IR9fZ7+x7Dn9zw2bPN9PdXrh+RDAAAAAKgSEfHXe+84/f6l99TLiaaTzPluxgreXwoA AAAAVSgiKrlZ2Zei4+MCJks43N9/8vnN+/j+UgAAAACoohFROT5/rUTEHxZ8QFcCAAAAABGRiAgA AAAAREQiIgAAAAAQEYmIAAAAAEBEJCICAAAAQJWMiKlxiRL/Cp329ZkgETHWd4ItC1/Zn0iPAwAA AEDFi4jq5cGSnXixEQAAAAAqZES8sj9REl2hU6yvehVxoi0L8yoiAAAAAFTIiGgjPosIAAAAAERE IiIAAAAAEBGJiAAAAABARCQiAgAAAAARkYgIAAAAAEREIiIAAAAAEBGJiAAAAABARCQiAgAAAAAR kYgIAAAAAEREIiIAAAAAgIgIAAAAACAiAgAAAACIiAAAAAAAIiIAAAAAgIgIAAAAACAiAgAAAAB+ 74h47Pm3JCImvLCErgQAAACAKh0R87JzNtfsLRFR/pXb9CYAAAAAVNGIWJCffyh0puTDT6p3l3/l tsyhQwEAAACgKkbEb8OXSTLc2sDvUswh+Vduyxw6FAAAAACqXERMWvmpZMJPa/S8sj9R7sq/clvm yHz6FAAAAACqUES89MXBTffeXHru453azHMbd8icTY7d5a90KwAAAABUiYiYkXByS+0+kgZ/fG29 2Z9+WLhO5stfZRl6FgAAAAAqeUS8eS5lW9MgyYFHxi7UXeDImIXyV1nmn7+k0LkAAAAAUGkj4p1r WTsfGi4JMM5/Uv6dXN1lZH6c3wuyjCwpy9O/AAAAAFAJI6Lt2e/fSdLvBWtJEgAAAABQgSOiegfp 582CbXkHqSzz2/tRxyykiwEAAACgUkVEO76HRvtWG1mXXgYAAACAShIR//1rFtHxRdr03d/GcLz3 2xgbd9DRAAAAAFDhI2JqXOKnNXpKzEtatdmOrSet/FTWlS1c2Z9IXwMAAABABY6I10+e3drATzLe t+HL7N6BrCtbkO3I1uhuAAAAAKiQEfFWakZ0yz9Jujs0eFZBfr7dO5B1D4XOlO3I1mSb9DgAAAAA VLyIeDhsruS6vd5j87JzirkP2cKebmNla7JNehwAAAAAKl5EvJWaIYmupF73K9mtAQAAAAB+14gI AAAAAKhq/h+31euQZsEb2QAAAABJRU5ErkJggg== --00c09fa21bcdfaf6a3048cdd0a05-- From eran@hueniverse.com Mon Aug 2 13:32:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C89E3A681A for ; Mon, 2 Aug 2010 13:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXCivqyD4+KE for ; Mon, 2 Aug 2010 13:32:43 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3C9493A6784 for ; Mon, 2 Aug 2010 13:32:43 -0700 (PDT) Received: (qmail 3366 invoked from network); 2 Aug 2010 20:33:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 2 Aug 2010 20:33:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 2 Aug 2010 13:33:09 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Mon, 2 Aug 2010 13:33:13 -0700 Thread-Topic: [OAUTH-WG] Extensibility: new endpoints Thread-Index: AcsygCLZe4JiQHj6SbifDN4bd/Jv2QAAblOQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> In-Reply-To: <4C57287C.1090105@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:32:44 -0000 General discussions on the list and during the interim meeting. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, August 02, 2010 1:20 PM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Extensibility: new endpoints >=20 > What consensus do you refer to? The WG charter? >=20 > regards, > Torsten. >=20 > Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: > > No according to WG consensus. We took it all out because too many peopl= e > considered it experimental, so while it may be a WG item, it is not part = of the > core spes. > > > > EHL > > > > > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >> Sent: Monday, August 02, 2010 1:07 PM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints > >> > >> and discovery does not belong into the core? > >> > >> regards, > >> Torsten. > >> > >> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: > >> > >>> This doesn't belong in core. A registry is used to avoid name > >>> collisions, not > >>> > >> to provide an inventory. > >> > >>> Maybe in discovery. > >>> > >>> EHL > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf Of Torsten Lodderstedt > >>>> Sent: Monday, August 02, 2010 12:54 PM > >>>> To: OAuth WG (oauth@ietf.org) > >>>> Subject: [OAUTH-WG] Extensibility: new endpoints > >>>> > >>>> the existing authorization server endpoints (end-user authorization > >>>> and tokens endpoint) have a relatively clearly semantics and scope. > >>>> Adding distinct new functions to an authorization server will (in > >>>> my > >>>> opionion) require the definition of new endpoints. For example, I'm > >>>> working on an I-D for token revocation. Such a function does not > >>>> fit into the tokens endpoint since it has become a "token issuance > >>>> endpoint" rather than a general purpose client2server endpoint. > >>>> > >>>> I therefore would propose to include the option to define and > >>>> register new endpoints into the Extensibility section of the spec. > >>>> This would also facilitate the incorporation of additional > >>>> endpoints (with well-defined names) into OAuth discovery. > >>>> > >>>> Any thoughts? > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> > > From mscurtescu@google.com Mon Aug 2 13:47:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4463A6C32 for ; Mon, 2 Aug 2010 13:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.666 X-Spam-Level: X-Spam-Status: No, score=-105.666 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i2dAH4JVr9R for ; Mon, 2 Aug 2010 13:47:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id F3B2B3A69DC for ; Mon, 2 Aug 2010 13:47:07 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o72KlYbK000997 for ; Mon, 2 Aug 2010 13:47:35 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280782055; bh=MEDfwC3xG8lKb1HNE/+cI9vTV2g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hYH0u3KBiPYCnH8f1YawxWbGW2kALbVkdB1mVKoKjjF+IjMIw8QR1cVXX59sFd1Ab bafJsHziEQxJnvwtvpl2A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=Kqga366beWFyvOJIOX8MUD1F+hJkQvotfTzALuwXntbhe0TQ3yDZ8VueUnb5dWOj+ baOfoWXuTR6asO36pQhzg== Received: from yxn35 (yxn35.prod.google.com [10.190.4.99]) by hpaq7.eem.corp.google.com with ESMTP id o72KlD75031362 for ; Mon, 2 Aug 2010 13:47:33 -0700 Received: by yxn35 with SMTP id 35so1715966yxn.23 for ; Mon, 02 Aug 2010 13:47:33 -0700 (PDT) Received: by 10.100.154.15 with SMTP id b15mr6797038ane.20.1280782053181; Mon, 02 Aug 2010 13:47:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.119.15 with HTTP; Mon, 2 Aug 2010 13:47:13 -0700 (PDT) In-Reply-To: <4C572883.7020302@lodderstedt.net> References: <4C572883.7020302@lodderstedt.net> From: Marius Scurtescu Date: Mon, 2 Aug 2010 13:47:13 -0700 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:47:11 -0000 Does anyone see value in client discovery? A client starts a transaction with an authz server without doing any registration beforehand. Based on the client id (which can be a URL or a domain name) the authz server can discover information about the client, information that normally is provided during registration: client name, description, logo, redirect URI. The client can self assert all this information as well, but with discovery the authz server at least is confident the client controls the domain where the redirect URI is. There is no client secret issued in this case, that could be a separate call, but the discovery info could include a public key to be used with signatures. Marius On Mon, Aug 2, 2010 at 1:20 PM, Torsten Lodderstedt wrote: > In the WG meeting at Maastricht, I have been asked to write down my > requirements regarding Discovery. And here they are: > > Assumptions: Discovery allows a compliant client to automatically obtain all > deployment specific data required to securely access a particular resource > servers as well as its respective authorization server for the purpose of > obtaining access tokens. > > Starting point of the discovery process is a resource URL. This URL can be > hard-coded into the client, bundled with the applications resources or > manually configured by the end-user at runtime. > > 1) Client -> Resource > The client uses the resource URL to obtain resource-specific data, such as > a) one URI refering to its authorization server > b) a definition of all scopes of the resource > c) additional data, e.g. supported signature methods and algorithms > > I do not make any assumption about how many requests are processed in order > to gather this information and whether there will be any levels of > indirections (e.g. from resource to resource server). > > 2) Client -> Authz Server > The authz server URI obtained in step 1 is used to gather the following data > from the authz server: > a) endpoint URLs (end-user authorization, tokens, ...) > b) information about the server's capabilities, e.g. the supported response > (end-user authorization endpoint) and grant types (tokens endpoint) > > The client stores the authz server's discovery URL along with the token(s) > it obtains for further use. > > And that's it from my point of view. I would very much appreciate if we > could have a discussion towards a consensus about discovery requirements. > > regards, > Torsten. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From wmills@yahoo-inc.com Mon Aug 2 14:14:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519E13A6C6D for ; Mon, 2 Aug 2010 14:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB1b3nZu6K8o for ; Mon, 2 Aug 2010 14:14:26 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 4E9653A6BC9 for ; Mon, 2 Aug 2010 14:14:26 -0700 (PDT) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o72LEfrd092502; Mon, 2 Aug 2010 14:14:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:from:to:cc:date:subject:thread-topic: thread-index:message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; b=BsTBXFN9kYD4eHq8b6T+X1XMh+h1ndQqJP2WNzUQ5zhgNLFIDpmXKd02Q0QSUB6u Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Mon, 2 Aug 2010 14:14:41 -0700 From: William Mills To: Marius Scurtescu , Torsten Lodderstedt Date: Mon, 2 Aug 2010 14:14:40 -0700 Thread-Topic: [OAUTH-WG] OAuth Discovery Requirements Thread-Index: Acsyg/+t5hF1HoBTT36+uI+yG9rSeAAA4UJA Message-ID: References: <4C572883.7020302@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 21:14:28 -0000 Client discovery can be useful for presenting a nicer user experience in to= ken management for example, displaying a favicon for example to help identi= fy the tokens listed for revocation. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Marius Scurtescu > Sent: Monday, August 02, 2010 1:47 PM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements >=20 > Does anyone see value in client discovery? >=20 > A client starts a transaction with an authz server without=20 > doing any registration beforehand. Based on the client id=20 > (which can be a URL or a domain name) the authz server can=20 > discover information about the client, information that=20 > normally is provided during registration: > client name, description, logo, redirect URI. >=20 > The client can self assert all this information as well, but=20 > with discovery the authz server at least is confident the=20 > client controls the domain where the redirect URI is. >=20 > There is no client secret issued in this case, that could be=20 > a separate call, but the discovery info could include a=20 > public key to be used with signatures. >=20 > Marius >=20 >=20 >=20 > On Mon, Aug 2, 2010 at 1:20 PM, Torsten Lodderstedt=20 > wrote: > > In the WG meeting at Maastricht, I have been asked to write down my=20 > > requirements regarding Discovery. And here they are: > > > > Assumptions: Discovery allows a compliant client to automatically=20 > > obtain all deployment specific data required to securely access a=20 > > particular resource servers as well as its respective authorization=20 > > server for the purpose of obtaining access tokens. > > > > Starting point of the discovery process is a resource URL. This URL=20 > > can be hard-coded into the client, bundled with the applications=20 > > resources or manually configured by the end-user at runtime. > > > > 1) Client -> Resource > > The client uses the resource URL to obtain resource-specific data,=20 > > such as > > a) one URI refering to its authorization server > > b) a definition of all scopes of the resource > > c) additional data, e.g. supported signature methods and algorithms > > > > I do not make any assumption about how many requests are=20 > processed in=20 > > order to gather this information and whether there will be=20 > any levels=20 > > of indirections (e.g. from resource to resource server). > > > > 2) Client -> Authz Server > > The authz server URI obtained in step 1 is used to gather the=20 > > following data from the authz server: > > a) endpoint URLs (end-user authorization, tokens, ...) > > b) information about the server's capabilities, e.g. the supported=20 > > response (end-user authorization endpoint) and grant types (tokens=20 > > endpoint) > > > > The client stores the authz server's discovery URL along with the=20 > > token(s) it obtains for further use. > > > > And that's it from my point of view. I would very much=20 > appreciate if=20 > > we could have a discussion towards a consensus about=20 > discovery requirements. > > > > regards, > > Torsten. > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > = From tonynad@microsoft.com Mon Aug 2 14:20:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C97F3A689F for ; Mon, 2 Aug 2010 14:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 661atkLKQxXr for ; Mon, 2 Aug 2010 14:20:27 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4AE1E3A67DA for ; Mon, 2 Aug 2010 14:20:27 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 2 Aug 2010 14:20:54 -0700 Received: from TK5EX14MBXC103.redmond.corp.microsoft.com ([169.254.3.64]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi id 14.01.0180.004; Mon, 2 Aug 2010 14:20:54 -0700 From: Anthony Nadalin To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft Thread-Index: AQHLJF9rSVp55J5Ts06rNhaRHOhU75LOx+iQ Date: Mon, 2 Aug 2010 21:20:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 21:20:28 -0000 There are many cases where we need to have more than 1 SAML assertion be us= ed to represent the authorization token, so would want a provision for mult= iple SAML tokens and not sure it makes sense to have a separate profile for= that or add it as an option here. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Thursday, July 15, 2010 1:50 PM To: oauth Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft I'm gong to join the growing list of people attaching a potential I-D to an= email due to he cut off time for the I-D submissions. Attached is a draft= that aims to tightly define the particular format of a SAML 2.0 bearer assertion in requesting an access token using the assertion grant_type. I've been working with Chuck at Salesforce.com on this and the primary goal is to have some documentation or specification that is= sufficient to facilitate interoperability between independently developed implementations or products. This, of course, wouldn't preclude using SAML in other ways - it would only provide = one concrete definition to implement against. I intend to submit this as an I-D when the submission process reopens. Any feedback from this group would be appreciated as well as thoughts abo= ut this eventually becoming a working group draft. Thanks, Brian Campbell From recordond@gmail.com Mon Aug 2 14:35:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C653A69BB for ; Mon, 2 Aug 2010 14:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzkidYXNfN+b for ; Mon, 2 Aug 2010 14:35:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EC12E3A6877 for ; Mon, 2 Aug 2010 14:35:22 -0700 (PDT) Received: by iwn3 with SMTP id 3so422909iwn.31 for ; Mon, 02 Aug 2010 14:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=h9P+ccGTNjfLcrrvoxpE3Pg8tUTy/IzmKzXWmTgphXc=; b=j3tw9wk+ODsVRGAfHCCqnrz84TgCuUPpCEex3fyrm3zetSO4EZj+/JlSs6HazzDNGI 7KhgBoTGB735+278lpIqKjp72H5oDBBALB2QAhuOubvkuXkSgKeXLlzDEO5NWxEDPAW8 sBnwgH1CTyN942KtR9Ejws1VLmWphJycktsbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ktYvElrLs3jq8wEg0gG1A3wKseVQaH2RZc7kmJIeACaSgSkc0FSSpxHrctut02ZqQu Lzw79jOtttun5JwFRo80vrEaiTOHwQf1RtAxjJGTpSR8y9FHuJbcbDytBMQoJ7IKRsEa lqOCGgl5KUWmPswO6fWVIUZoPwJ6KQp3+OEsw= MIME-Version: 1.0 Received: by 10.231.190.10 with SMTP id dg10mr7584884ibb.46.1280784949901; Mon, 02 Aug 2010 14:35:49 -0700 (PDT) Received: by 10.231.174.2 with HTTP; Mon, 2 Aug 2010 14:35:49 -0700 (PDT) In-Reply-To: References: <4C572883.7020302@lodderstedt.net> Date: Mon, 2 Aug 2010 14:35:49 -0700 Message-ID: From: David Recordon To: William Mills Content-Type: multipart/alternative; boundary=0016367b6e8cf8f857048cddfb00 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 21:35:24 -0000 --0016367b6e8cf8f857048cddfb00 Content-Type: text/plain; charset=ISO-8859-1 Yes, all of these all seem like the right set of use cases. I'm not sure if I'll have much time to devote to them over the next few months though. --David On Mon, Aug 2, 2010 at 2:14 PM, William Mills wrote: > Client discovery can be useful for presenting a nicer user experience in > token management for example, displaying a favicon for example to help > identify the tokens listed for revocation. > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > > On Behalf Of Marius Scurtescu > > Sent: Monday, August 02, 2010 1:47 PM > > To: Torsten Lodderstedt > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements > > > > Does anyone see value in client discovery? > > > > A client starts a transaction with an authz server without > > doing any registration beforehand. Based on the client id > > (which can be a URL or a domain name) the authz server can > > discover information about the client, information that > > normally is provided during registration: > > client name, description, logo, redirect URI. > > > > The client can self assert all this information as well, but > > with discovery the authz server at least is confident the > > client controls the domain where the redirect URI is. > > > > There is no client secret issued in this case, that could be > > a separate call, but the discovery info could include a > > public key to be used with signatures. > > > > Marius > > > > > > > > On Mon, Aug 2, 2010 at 1:20 PM, Torsten Lodderstedt > > wrote: > > > In the WG meeting at Maastricht, I have been asked to write down my > > > requirements regarding Discovery. And here they are: > > > > > > Assumptions: Discovery allows a compliant client to automatically > > > obtain all deployment specific data required to securely access a > > > particular resource servers as well as its respective authorization > > > server for the purpose of obtaining access tokens. > > > > > > Starting point of the discovery process is a resource URL. This URL > > > can be hard-coded into the client, bundled with the applications > > > resources or manually configured by the end-user at runtime. > > > > > > 1) Client -> Resource > > > The client uses the resource URL to obtain resource-specific data, > > > such as > > > a) one URI refering to its authorization server > > > b) a definition of all scopes of the resource > > > c) additional data, e.g. supported signature methods and algorithms > > > > > > I do not make any assumption about how many requests are > > processed in > > > order to gather this information and whether there will be > > any levels > > > of indirections (e.g. from resource to resource server). > > > > > > 2) Client -> Authz Server > > > The authz server URI obtained in step 1 is used to gather the > > > following data from the authz server: > > > a) endpoint URLs (end-user authorization, tokens, ...) > > > b) information about the server's capabilities, e.g. the supported > > > response (end-user authorization endpoint) and grant types (tokens > > > endpoint) > > > > > > The client stores the authz server's discovery URL along with the > > > token(s) it obtains for further use. > > > > > > And that's it from my point of view. I would very much > > appreciate if > > > we could have a discussion towards a consensus about > > discovery requirements. > > > > > > regards, > > > Torsten. > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016367b6e8cf8f857048cddfb00 Content-Type: text/html; charset=ISO-8859-1 Yes, all of these all seem like the right set of use cases. I'm not sure if I'll have much time to devote to them over the next few months though.

--David


On Mon, Aug 2, 2010 at 2:14 PM, William Mills <wmills@yahoo-inc.com> wrote:
Client discovery can be useful for presenting a nicer user experience in token management for example, displaying a favicon for example to help identify the tokens listed for revocation.

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
> On Behalf Of Marius Scurtescu
> Sent: Monday, August 02, 2010 1:47 PM
> To: Torsten Lodderstedt
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] OAuth Discovery Requirements
>
> Does anyone see value in client discovery?
>
> A client starts a transaction with an authz server without
> doing any registration beforehand. Based on the client id
> (which can be a URL or a domain name) the authz server can
> discover information about the client, information that
> normally is provided during registration:
> client name, description, logo, redirect URI.
>
> The client can self assert all this information as well, but
> with discovery the authz server at least is confident the
> client controls the domain where the redirect URI is.
>
> There is no client secret issued in this case, that could be
> a separate call, but the discovery info could include a
> public key to be used with signatures.
>
> Marius
>
>
>
> On Mon, Aug 2, 2010 at 1:20 PM, Torsten Lodderstedt
> <torsten@lodderstedt.net> wrote:
> > In the WG meeting at Maastricht, I have been asked to write down my
> > requirements regarding Discovery. And here they are:
> >
> > Assumptions: Discovery allows a compliant client to automatically
> > obtain all deployment specific data required to securely access a
> > particular resource servers as well as its respective authorization
> > server for the purpose of obtaining access tokens.
> >
> > Starting point of the discovery process is a resource URL. This URL
> > can be hard-coded into the client, bundled with the applications
> > resources or manually configured by the end-user at runtime.
> >
> > 1) Client -> Resource
> > The client uses the resource URL to obtain resource-specific data,
> > such as
> > a) one URI refering to its authorization server
> > b) a definition of all scopes of the resource
> > c) additional data, e.g. supported signature methods and algorithms
> >
> > I do not make any assumption about how many requests are
> processed in
> > order to gather this information and whether there will be
> any levels
> > of indirections (e.g. from resource to resource server).
> >
> > 2) Client -> Authz Server
> > The authz server URI obtained in step 1 is used to gather the
> > following data from the authz server:
> > a) endpoint URLs (end-user authorization, tokens, ...)
> > b) information about the server's capabilities, e.g. the supported
> > response (end-user authorization endpoint) and grant types (tokens
> > endpoint)
> >
> > The client stores the authz server's discovery URL along with the
> > token(s) it obtains for further use.
> >
> > And that's it from my point of view. I would very much
> appreciate if
> > we could have a discussion towards a consensus about
> discovery requirements.
> >
> > regards,
> > Torsten.
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--0016367b6e8cf8f857048cddfb00-- From recordond@gmail.com Mon Aug 2 14:36:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F9083A6C6D for ; Mon, 2 Aug 2010 14:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU7S4rRMtM9G for ; Mon, 2 Aug 2010 14:36:44 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BEDEB3A6877 for ; Mon, 2 Aug 2010 14:36:44 -0700 (PDT) Received: by iwn3 with SMTP id 3so423910iwn.31 for ; Mon, 02 Aug 2010 14:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WaJsKNwUiA4OC+aqE5TxFgRRzOW6kgvxfLI37yAaCmo=; b=ENb5Qp/bhxJPtkLgrvtTq1eM06M0bOmkWJy8Bz6cEQBEf+Wr1DX42AR6OfgWSBm1Hz 0H25+63Xsm+CkagyM7Nn2w0LjDLLJZCmXJJyZJIf27C2mM9X23lt1xQGLhJPVAFTlYMs /+PFE07+1Ujuor92SMx2R1pnNBXyfXG4PtyIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DT6TWG/2k8gXAnYA+zG1c+8PVgHrUtnhkEZgUdkzRPIN1laU3ttoaqbM3tFkJ6PWH5 xnoCYThTkS/8JkEmsuIfrKX2kfDXbHEpiiBI90eWEjzb6/0v3LWUxFSffNKtabfGqEWH Nb1Mhc96M857177RK5E8YHqeOT+RntLZ6JZw0= MIME-Version: 1.0 Received: by 10.231.38.9 with SMTP id z9mr1896392ibd.17.1280785026985; Mon, 02 Aug 2010 14:37:06 -0700 (PDT) Received: by 10.231.174.2 with HTTP; Mon, 2 Aug 2010 14:37:06 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 2 Aug 2010 14:37:06 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0022152d6ddd912f50048cde00fa Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 21:36:47 -0000 --0022152d6ddd912f50048cde00fa Content-Type: text/plain; charset=ISO-8859-1 That matches my understanding as well. --David On Mon, Aug 2, 2010 at 1:33 PM, Eran Hammer-Lahav wrote: > General discussions on the list and during the interim meeting. > > EHL > > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: Monday, August 02, 2010 1:20 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Extensibility: new endpoints > > > > What consensus do you refer to? The WG charter? > > > > regards, > > Torsten. > > > > Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: > > > No according to WG consensus. We took it all out because too many > people > > considered it experimental, so while it may be a WG item, it is not part > of the > > core spes. > > > > > > EHL > > > > > > > > >> -----Original Message----- > > >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > >> Sent: Monday, August 02, 2010 1:07 PM > > >> To: Eran Hammer-Lahav > > >> Cc: OAuth WG (oauth@ietf.org) > > >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints > > >> > > >> and discovery does not belong into the core? > > >> > > >> regards, > > >> Torsten. > > >> > > >> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: > > >> > > >>> This doesn't belong in core. A registry is used to avoid name > > >>> collisions, not > > >>> > > >> to provide an inventory. > > >> > > >>> Maybe in discovery. > > >>> > > >>> EHL > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >>>> Behalf Of Torsten Lodderstedt > > >>>> Sent: Monday, August 02, 2010 12:54 PM > > >>>> To: OAuth WG (oauth@ietf.org) > > >>>> Subject: [OAUTH-WG] Extensibility: new endpoints > > >>>> > > >>>> the existing authorization server endpoints (end-user authorization > > >>>> and tokens endpoint) have a relatively clearly semantics and scope. > > >>>> Adding distinct new functions to an authorization server will (in > > >>>> my > > >>>> opionion) require the definition of new endpoints. For example, I'm > > >>>> working on an I-D for token revocation. Such a function does not > > >>>> fit into the tokens endpoint since it has become a "token issuance > > >>>> endpoint" rather than a general purpose client2server endpoint. > > >>>> > > >>>> I therefore would propose to include the option to define and > > >>>> register new endpoints into the Extensibility section of the spec. > > >>>> This would also facilitate the incorporation of additional > > >>>> endpoints (with well-defined names) into OAuth discovery. > > >>>> > > >>>> Any thoughts? > > >>>> > > >>>> regards, > > >>>> Torsten. > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> OAuth mailing list > > >>>> OAuth@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/oauth > > >>>> > > >>>> > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0022152d6ddd912f50048cde00fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That matches my understanding as well.

--David


On Mon, Aug 2, 2010 at 1:33 PM, Eran Ha= mmer-Lahav <era= n@hueniverse.com> wrote:
General discussions on the list and during = the interim meeting.

EHL

> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Monday, August 02, 2010 = 1:20 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Extensibility: new endpoints
>
> What consensus do you refer to? The WG charter?
>
> regards,
> Torsten.
>
> Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav:
> > No according to WG consensus. We took it all out because too many= people
> considered it experimental, so while it may be a WG item, it is not pa= rt of the
> core spes.
> >
> > EHL
> >
> >
> >> -----Original Message-----
> >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> >> Sent: Monday, August 02, 2010 1:07 PM
> >> To: Eran Hammer-Lahav
> >> Cc: OAuth WG (oauth@ietf.or= g)
> >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints
> >>
> >> and discovery does not belong into the core?
> >>
> >> regards,
> >> Torsten.
> >>
> >> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav:
> >>
> >>> This doesn't belong in core. A registry is used to av= oid name
> >>> collisions, not
> >>>
> >> to provide an inventory.
> >>
> >>> Maybe =A0in discovery.
> >>>
> >>> EHL
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: oauth= -bounces@ietf.org [mailto:oau= th-bounces@ietf.org] On
> >>>> Behalf Of Torsten Lodderstedt
> >>>> Sent: Monday, August 02, 2010 12:54 PM
> >>>> To: OAuth WG (oauth= @ietf.org)
> >>>> Subject: [OAUTH-WG] Extensibility: new endpoints
> >>>>
> >>>> the existing authorization server endpoints (end-user= authorization
> >>>> and tokens endpoint) have a relatively clearly semant= ics and scope.
> >>>> Adding distinct new functions to an authorization ser= ver will (in
> >>>> my
> >>>> opionion) require the definition of new endpoints. Fo= r example, I'm
> >>>> working on an I-D for token revocation. Such a functi= on does not
> >>>> fit into the tokens endpoint since it has become a &q= uot;token issuance
> >>>> endpoint" rather than a general purpose client2s= erver endpoint.
> >>>>
> >>>> I therefore would propose to include the option to de= fine and
> >>>> register new endpoints into the Extensibility section= of the spec.
> >>>> This would also facilitate the incorporation of addit= ional
> >>>> endpoints (with well-defined names) into OAuth discov= ery.
> >>>>
> >>>> Any thoughts?
> >>>>
> >>>> regards,
> >>>> Torsten.
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> OAuth@ietf.org<= br> > >>>> https://www.ietf.org/mailman/listinfo/oauth
> >>>>
> >>>>
> >

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

--0022152d6ddd912f50048cde00fa-- From recordond@gmail.com Mon Aug 2 14:38:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 474C23A6877 for ; Mon, 2 Aug 2010 14:38:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY+O30gZ+wXx for ; Mon, 2 Aug 2010 14:38:13 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 138343A69D5 for ; Mon, 2 Aug 2010 14:38:13 -0700 (PDT) Received: by iwn3 with SMTP id 3so424943iwn.31 for ; Mon, 02 Aug 2010 14:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hIgpvq0ww7qRRhlNVDHy3aw/B5LAajtI6wtMN7QSEGw=; b=x6ol7b1DyRjkb27EdgPyZmDm2+QhpZ2UG3j80xT3DieRoMFKMl+DHI6WOWYFkkGZtZ vOjmqkR97Je4KFlXxKsx0G7fKsISPgHNfXbhMGrkFZV2K1il+xCBFPcGhYiEixU2s+Gi XNu3ytx/fvRi9tc7N12pLk/fPlCH2L/RSG9rc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tMGS91vnxvZbS6SoIXYmWdJcje5K24YQyT4+EOvLwyGCyCxX1+Q6FWxvcFmi1oL9Dw KxhW0dMmThwEIETorXF+Nn2kFKMEctGJioSJ96WrPP0XNPZ5u9A5ikNCQwh3dG/5Yodp d9yBf4trMm4068DcKghz8tQv6O9vzNscT7ijA= MIME-Version: 1.0 Received: by 10.231.149.12 with SMTP id r12mr7328640ibv.185.1280785120815; Mon, 02 Aug 2010 14:38:40 -0700 (PDT) Received: by 10.231.174.2 with HTTP; Mon, 2 Aug 2010 14:38:39 -0700 (PDT) In-Reply-To: References: <635529.20547.qm@web37602.mail.mud.yahoo.com> <304014.50128.qm@web37605.mail.mud.yahoo.com> Date: Mon, 2 Aug 2010 14:38:39 -0700 Message-ID: From: David Recordon To: Brian Eaton Content-Type: multipart/alternative; boundary=0016e645b94228eba1048cde06d0 Cc: Oleg Gryb , oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 21:38:14 -0000 --0016e645b94228eba1048cde06d0 Content-Type: text/plain; charset=ISO-8859-1 A richer history API is also coming as a part of HTML5. http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html On Mon, Aug 2, 2010 at 12:47 PM, Brian Eaton wrote: > On Mon, Aug 2, 2010 at 9:23 AM, Oleg Gryb wrote: > > > > What about browsing history? I've just run the JSP below in Tomcat and > found out that Firefox remembers the redirect in the browsing history. It'll > be a problem in a shared desktop or Internet kiosk environment. > > I think the best practice for authentication tokens passed on URLs is > to clean the URL as soon as it is received. > > For the web server flow, that would mean sending a 302 after receiving > the authorization code. > > For the user-agent/javascript flow, that would mean copying the token > into a cookie or a javascript variable, and then using > window.location.replace() to clean the URL. > > My javascript ninja sources tell me that location.replace() cleans the > browser history, but I haven't actually tested it. The mozilla > documentation is very clear on the expected behavior: > > https://developer.mozilla.org/en/window.location > > "Replace the current document with the one at the provided URL. The > difference from the assign() method is that after using replace() the > current page will not be saved in session history, meaning the user > won't be able to use the Back button to navigate to it." > > Cheers, > Brian > --0016e645b94228eba1048cde06d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A richer history API is also coming as a part of HTML5.=A0http://= www.whatwg.org/specs/web-apps/current-work/multipage/history.html
On Mon, Aug 2, 2010 at 12:47 PM, Brian Eaton <beaton@google.com> wrote:
On Mon, Aug 2, 2010 at 9:23 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:
>
> What about browsing history? I've just run the JSP below in Tomcat= and found out that Firefox remembers the redirect in the browsing history.= It'll be a problem in a shared desktop or Internet kiosk environment.<= br>
I think the best practice for authentication tokens passed on URLs is=
to clean the URL as soon as it is received.

For the web server flow, that would mean sending a 302 after receiving
the authorization code.

For the user-agent/javascript flow, that would mean copying the token
into a cookie or a javascript variable, and then using
window.location.replace() to clean the URL.

My javascript ninja sources tell me that location.replace() cleans the
browser history, but I haven't actually tested it. =A0The mozilla
documentation is very clear on the expected behavior:

https://developer.mozilla.org/en/window.location

"Replace the current document with the one at the provided URL. The difference from the=A0assign()=A0method is that after using=A0replace()=A0t= he
current page will not be saved in session history, meaning the user
won't be able to use the Back button to navigate to it."

Cheers,
Brian

--0016e645b94228eba1048cde06d0-- From bcampbell@pingidentity.com Mon Aug 2 14:53:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A64F73A69BB for ; Mon, 2 Aug 2010 14:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLfhQZyYM06l for ; Mon, 2 Aug 2010 14:53:27 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by core3.amsl.com (Postfix) with SMTP id EA4183A65A5 for ; Mon, 2 Aug 2010 14:53:26 -0700 (PDT) Received: from source ([74.125.82.54]) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTFc+ca1OmPfZYg4QZrB7RD7P9YKvKzIn@postini.com; Mon, 02 Aug 2010 14:53:55 PDT Received: by mail-ww0-f54.google.com with SMTP id 31so684924wwb.35 for ; Mon, 02 Aug 2010 14:53:53 -0700 (PDT) Received: by 10.216.26.145 with SMTP id c17mr3195615wea.70.1280786033247; Mon, 02 Aug 2010 14:53:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Mon, 2 Aug 2010 14:53:23 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 2 Aug 2010 15:53:23 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 21:53:28 -0000 I guess I'd need to understand the scenario better before I'd have an opinion one way or the other. However, I will say that In this profile I was specifically looking to avoid the complexity that exists in SAML Web SSO by allowing for multiple assertions and multiple subject confirmations. On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin wro= te: > There are many cases where we need to have more than 1 SAML assertion be = used to represent the authorization token, so would want a provision for mu= ltiple SAML tokens and not sure it makes sense to have a separate profile f= or that or add it as an option here. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Brian Campbell > Sent: Thursday, July 15, 2010 1:50 PM > To: oauth > Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft > > I'm gong to join the growing list of people attaching a potential I-D to = an email due to he cut off time for the I-D submissions. =A0Attached is a d= raft that aims to tightly define the particular format of a SAML > 2.0 bearer assertion in requesting an access token using the assertion > grant_type. =A0 I've been working with Chuck at Salesforce.com on this > and the primary goal is to have some documentation or specification that = is sufficient to facilitate interoperability between > independently developed implementations or products. =A0 =A0This, of > course, wouldn't preclude using SAML in other ways - it would only provid= e one concrete definition to implement against. > > I intend to submit this as an I-D when the submission process reopens. > =A0Any feedback from this group would be appreciated as well as thoughts = about this eventually becoming a working group draft. > > Thanks, > Brian Campbell > From tonynad@microsoft.com Mon Aug 2 15:25:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31973A69DA for ; Mon, 2 Aug 2010 15:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDDy+2KUZ5t4 for ; Mon, 2 Aug 2010 15:25:48 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 633573A6805 for ; Mon, 2 Aug 2010 15:25:48 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 2 Aug 2010 15:26:16 -0700 Received: from TK5EX14MBXC103.redmond.corp.microsoft.com ([169.254.3.64]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0180.004; Mon, 2 Aug 2010 15:26:16 -0700 From: Anthony Nadalin To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft Thread-Index: AQHLJF9rSVp55J5Ts06rNhaRHOhU75LOx+iQgAB+84D//40ukA== Date: Mon, 2 Aug 2010 22:26:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 22:25:51 -0000 So the scenario we have is where there are multiple tokens from attribute a= nd identity providers need to be delivered to an OAuth authorization server= to satisfy the resource owner's policy of required claims. So this is a ca= se where a single SAML token/assertion is not enough to satisfy the claim, = we still expect that the signature verification is out of scope. -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Monday, August 02, 2010 2:53 PM To: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 dra= ft I guess I'd need to understand the scenario better before I'd have an opinion one way or the other. However, I will say that In this profile I was specifically looking to avoid the complexity that exists in S= AML Web SSO by allowing for multiple assertions and multiple subject confir= mations. On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin wro= te: > There are many cases where we need to have more than 1 SAML assertion be = used to represent the authorization token, so would want a provision for mu= ltiple SAML tokens and not sure it makes sense to have a separate profile f= or that or add it as an option here. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Brian Campbell > Sent: Thursday, July 15, 2010 1:50 PM > To: oauth > Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0=20 > draft > > I'm gong to join the growing list of people attaching a potential I-D=20 > to an email due to he cut off time for the I-D submissions. =A0Attached=20 > is a draft that aims to tightly define the particular format of a SAML > 2.0 bearer assertion in requesting an access token using the assertion=20 > grant_type. =A0 I've been working with Chuck at Salesforce.com on this=20 > and the primary goal is to have some documentation or specification=20 > that is sufficient to facilitate interoperability between=20 > independently developed implementations or products. =A0 =A0This, of cour= se, wouldn't preclude using SAML in other ways - it would only provide one = concrete definition to implement against. > > I intend to submit this as an I-D when the submission process reopens. > =A0Any feedback from this group would be appreciated as well as thoughts = about this eventually becoming a working group draft. > > Thanks, > Brian Campbell > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From dstanek@dstanek.com Mon Aug 2 18:15:05 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AAE73A6A11 for ; Mon, 2 Aug 2010 18:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdYj4sVD+DKr for ; Mon, 2 Aug 2010 18:14:56 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8C76D3A6852 for ; Mon, 2 Aug 2010 18:14:56 -0700 (PDT) Received: by vws10 with SMTP id 10so2738309vws.31 for ; Mon, 02 Aug 2010 18:15:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.71.136 with SMTP id h8mr4715003vcj.275.1280798124322; Mon, 02 Aug 2010 18:15:24 -0700 (PDT) Received: by 10.220.181.194 with HTTP; Mon, 2 Aug 2010 18:15:24 -0700 (PDT) In-Reply-To: <635529.20547.qm@web37602.mail.mud.yahoo.com> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> Date: Mon, 2 Aug 2010 21:15:24 -0400 Message-ID: From: David Stanek To: oleg@gryb.info Content-Type: multipart/alternative; boundary=0016e64757dc3aaeb5048ce10dcd Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 01:15:07 -0000 --0016e64757dc3aaeb5048ce10dcd Content-Type: text/plain; charset=ISO-8859-1 On Sun, Aug 1, 2010 at 10:47 PM, Oleg Gryb wrote: > I've just verified Ruby and Perl's user agents as well: both worked as > expected - no fragments in the web log files. It adds confidence. Thanks to > everyone who has answered. I just verified that the Python urllib client does send the fragment to the server. I've created a patch and will be created a bug on the Python tracker. Does anyone know what RFC actually talks about not sending the fragment? I've seen 3986 where it explains that a fragment isn't really a part of the URI, but it's doesn't specifically say that the client should not send it to the server. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek --0016e64757dc3aaeb5048ce10dcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Aug 1, 2010 at 10:47 PM, Oleg Gr= yb <oleg_gryb@y= ahoo.com> wrote:
I've just verified Ruby and Perl'= s user agents as well: both worked as expected - no fragments in the web lo= g files. It adds confidence. Thanks to everyone who has answered.


I just= verified that the Python urllib client does send the fragment to the serve= r. I've created a patch and will be created a bug on the Python tracker= .

Does anyone know what RFC actually talks about not send= ing the fragment? I've seen 3986 where it explains that a fragment isn&= #39;t really a part of the URI, but it's doesn't specifically say t= hat the client should not send it to the server.

--
David
blog: http:/= /www.traceback.org
twitter: h= ttp://twitter.com/dstanek
--0016e64757dc3aaeb5048ce10dcd-- From beaton@google.com Mon Aug 2 20:31:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7823A67A7 for ; Mon, 2 Aug 2010 20:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.839 X-Spam-Level: X-Spam-Status: No, score=-105.839 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT3sonHPSA3B for ; Mon, 2 Aug 2010 20:31:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 7DD093A6781 for ; Mon, 2 Aug 2010 20:31:32 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o733Vx83015760 for ; Mon, 2 Aug 2010 20:32:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280806320; bh=GnkncdkE0FZWs5ijhg7P80RUYsU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=QLZBb/dRGVQb0ip0SCO7a131VmKip7Pgr7wSzsBPXWzb2A4krl0oOfnD9gJ//SinN 1bT3skvl0b81UYigAkxzw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=aTMFIVRYlGGUdNJdByrIj21WKSW24Y8aIxXtLJGpJT7SD4ho3Ua3us4XBp5ODKEvE vfDu2SKaNiN2BnPsQJ7IA== Received: from pzk26 (pzk26.prod.google.com [10.243.19.154]) by hpaq1.eem.corp.google.com with ESMTP id o733VvIA011143 for ; Mon, 2 Aug 2010 20:31:58 -0700 Received: by pzk26 with SMTP id 26so1459443pzk.5 for ; Mon, 02 Aug 2010 20:31:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.148.10 with SMTP id v10mr6095968wfd.105.1280806316995; Mon, 02 Aug 2010 20:31:56 -0700 (PDT) Received: by 10.142.195.9 with HTTP; Mon, 2 Aug 2010 20:31:56 -0700 (PDT) In-Reply-To: References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> Date: Mon, 2 Aug 2010 20:31:56 -0700 Message-ID: From: Brian Eaton To: David Stanek Content-Type: multipart/alternative; boundary=000e0cd28dba8cf6f4048ce2f5cf X-System-Of-Record: true Cc: oleg@gryb.info, oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 03:31:39 -0000 --000e0cd28dba8cf6f4048ce2f5cf Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 2, 2010 at 6:15 PM, David Stanek wrote: > I just verified that the Python urllib client does send the fragment to the > server. I've created a patch and will be created a bug on the Python > tracker. > Cool, but this doesn't seem relevant to the user-agent profile. Market penetration of browsers written in python is limited. > Does anyone know what RFC actually talks about not sending the fragment? > I've seen 3986 where it explains that a fragment isn't really a part of the > URI, but it's doesn't specifically say that the client should not send it to > the server. > No idea. This might be one of those things that all the browsers implement, but has never been fully specified. There are a few notes on referers in the browsersec wiki: http://code.google.com/p/browsersec/wiki/Part1 Cheers, Brian --000e0cd28dba8cf6f4048ce2f5cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 2, 2010 at 6:15 PM, David Stanek <dstanek@dstanek.com> wrote:
I just verified that the Python urllib clie= nt does send the fragment to the server. I've created a patch and will = be created a bug on the Python tracker.

Cool, but this doesn't seem relevant to the user-agent profi= le. =A0Market penetration of browsers written in python is limited.
=A0
Does anyone know what RFC actually talks about not sending the fragmen= t? I've seen 3986 where it explains that a fragment isn't really a = part of the URI, but it's doesn't specifically say that the client = should not send it to the server.

No idea. =A0This might be one of those th= ings that all the browsers implement, but has never been fully specified.

There are a few notes on referers in the browsersec= wiki:=A0http://= code.google.com/p/browsersec/wiki/Part1

Cheers,
Brian
--000e0cd28dba8cf6f4048ce2f5cf-- From oleg_gryb@yahoo.com Mon Aug 2 22:21:00 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB6A3A6842 for ; Mon, 2 Aug 2010 22:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpBRd4rq0eps for ; Mon, 2 Aug 2010 22:20:58 -0700 (PDT) Received: from web37602.mail.mud.yahoo.com (web37602.mail.mud.yahoo.com [209.191.87.85]) by core3.amsl.com (Postfix) with SMTP id 1B2623A67FC for ; Mon, 2 Aug 2010 22:20:58 -0700 (PDT) Received: (qmail 43699 invoked by uid 60001); 3 Aug 2010 05:21:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280812883; bh=BF9F1iOTluX9KU+JBnQPkLW9SR7oH/KDsLw0xdCgFHc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sZ7/Tf6iv8jUs9KfmgVoP9cQ4ZU50fpA0jb+uiH7Mf4esmo9fvcyd4olhNHazp2az+DajniPUoFpXvIm6agZ1W8nMr2FIRYOtCC9DLURSbIGQqYKGD0J9j7gn3pJ0msqWnPJ7NXNDfho/tCfCpFa9UvgAqdcxuSAm8wAgvhzbwo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gKtdrkmtUGJ9I+ZzXOZPfHLZMxVuSPepcMsYaE85Re8g58ZAmWeYycLJ5UHgDdQXUHzaWyqT7I9c2OVHfjBP627KiWD199PvM/q6tC3I8C9/iTHjZOFylzg+CS+fBQuggwrnvzvIgkw91d4Q+ITMprQwcTkLTCBWNHS5Mt/12FE=; Message-ID: <204869.37310.qm@web37602.mail.mud.yahoo.com> X-YMail-OSG: todeFFoVM1lYYH76KbHkxz7feTwEMiZDpRGP6PHZNXNfZ1q viu4oUSnIx1bDB8amjxztaaZeqmbJFQUd5q2dUoDSgVqqZVaoHwfh1hl6PKq Ksng646K5nlQ0XozinKryWVlSbaFnczXz_DnOHuALKc8ejceMN6oszta43S. I7Y83TKnfxL_nKvplpEeGVafMZFJ7qX5Y4EQP3QfKbndAGrYOo4VknHkqs2E TcLRvRYTiG7PQg0tKt3_czKQm6S1nvB70SE5vhlFDS8W6ZLyVr224oVZS9dy Q2fYFXzp7vcFwHDC8AQdyEO7JlrnZDT7OOpfJx1WB6C0E Received: from [67.119.192.108] by web37602.mail.mud.yahoo.com via HTTP; Mon, 02 Aug 2010 22:21:23 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> Date: Mon, 2 Aug 2010 22:21:23 -0700 (PDT) From: Oleg Gryb To: Brian Eaton , David Stanek In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-841599478-1280812883=:37310" Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 05:21:00 -0000 --0-841599478-1280812883=:37310 Content-Type: text/plain; charset=us-ascii Brian, I think, it's not so much about browsers written in Python, as about automation (crawler) that somebody might want to use. Also, since Python user agent works this way, we might have others user agents like that, e.g. did anyone check all obscure browsers on smart phones? Returning to our discussion about necessity of passing access_token in URL's fragment, I've read both your proposal for changing v.9 and the current v.10, but still don't understand why we need access_token in a fragment. I think, a safer solution would be to return an access token in a response form, not in Location header. This way, we'll avoid problems with user agents that David Stanek described and prevent browsers from storing tokens in a browser's history. In sense of efficiency, I don't think that we'll loose much. We might even eliminate two last steps. If you're still concerned about caching pages in a browser, it's a known problem for any sensitive pages and it can be resolved, e.g. by adding HTTP headers in response: Pragma:No-cache and Cache-Control:no-cache. Here is how JSP that generates access token can look like: form.jsp ----------------------------------------------------------- <% response.addHeader("Pragma", "No-cache"); response.addHeader("Cache-Control", "no-cache"); String token = "123"; // It could be more complicated of course %>
http://localhost:8080/resource.jsp"/>
resource.jsp in this example will take the request with access_token, verify it and send a response with the requested resource back to the browser. In the example below it just prints out the request (with access_token in it). It means that after modified step C, you'll have just one more step that takes URL from the form and POST the form to that URL. Ajax might work as well. No need in passing access token in a fragment. resource.jsp that I've used for testing (it simply prints the request coming from form.jsp): <% String input =""; try { java.io.BufferedReader reader = request.getReader(); String line = reader.readLine(); while (line != null) { input += line + "\n"; line = reader.readLine(); } } catch (Exception ex) { } %> <%=input%> ________________________________ From: Brian Eaton To: David Stanek Cc: oleg@gryb.info; oauth@ietf.org Sent: Mon, August 2, 2010 8:31:56 PM Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? On Mon, Aug 2, 2010 at 6:15 PM, David Stanek wrote: I just verified that the Python urllib client does send the fragment to the server. I've created a patch and will be created a bug on the Python tracker. Cool, but this doesn't seem relevant to the user-agent profile. Market penetration of browsers written in python is limited. Does anyone know what RFC actually talks about not sending the fragment? I've seen 3986 where it explains that a fragment isn't really a part of the URI, but it's doesn't specifically say that the client should not send it to the server. No idea. This might be one of those things that all the browsers implement, but has never been fully specified. There are a few notes on referers in the browsersec wiki: http://code.google.com/p/browsersec/wiki/Part1 Cheers, Brian --0-841599478-1280812883=:37310 Content-Type: text/html; charset=us-ascii
Brian,

I think, it's not so much about browsers written in Python, as about automation (crawler) that somebody might want to use. Also, since Python user agent works this way, we might have others user agents like that, e.g. did anyone check all obscure browsers on smart phones?

Returning to our discussion about necessity of passing access_token in URL's fragment, I've read both your proposal for changing  v.9 and the current v.10, but still don't understand why we need access_token in a fragment.

I think, a safer solution would be to return an access token in a response form, not in Location header. This way, we'll avoid problems with user agents that David Stanek described and prevent browsers from storing tokens in a browser's history.

In sense of efficiency, I don't think that we'll loose much. We might even eliminate two last steps. If you're still concerned about caching pages in a browser, it's a known problem for any sensitive pages and it can be resolved, e.g. by adding HTTP headers in response: Pragma:No-cache and Cache-Control:no-cache.

Here is how JSP that generates access token can look like:
form.jsp
-----------------------------------------------------------
<HTML>
<HEAD>
<%
   response.addHeader("Pragma", "No-cache");
   response.addHeader("Cache-Control", "no-cache");
   String token = "123"; // It could be more complicated of course
%>
<script>

function process(token, url) {
   document.params.setAttribute("method", "POST");
   document.params.setAttribute("action", url);
   document.params.submit();
}
</script>
</HEAD>
<BODY onload="process(document.params.access_token.value,document.params.url.value)">
<form name="params">
<input type="hidden" name="access_token" value="<%=token%>"/>
http://localhost:8080/resource.jsp"/>
</form>
</BODY>
</HTML>

resource.jsp in this example will take the request with access_token, verify it and send a response with the requested resource back to the browser. In the example below it just prints out the request (with access_token in it).

It means that after modified step C, you'll have just one more step that takes URL from the form and POST the form to that URL. Ajax might work as well. No need in passing access token in a fragment.

resource.jsp that I've used for testing (it simply prints the request coming from form.jsp):
<HTML>
<HEAD>
<%
   String input ="";
   try {
      java.io.BufferedReader reader = request.getReader();
      String line = reader.readLine();
      while (line != null) {
         input += line + "\n";
         line = reader.readLine();
      }

   }
   catch (Exception ex) {
   }
%>
<script>
</script>
</HEAD>
<BODY>
<%=input%>
</BODY>
</HTML>


From: Brian Eaton <beaton@google.com>
To: David Stanek <dstanek@dstanek.com>
Cc: oleg@gryb.info; oauth@ietf.org
Sent: Mon, August 2, 2010 8:31:56 PM
Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0?

On Mon, Aug 2, 2010 at 6:15 PM, David Stanek <dstanek@dstanek.com> wrote:
I just verified that the Python urllib client does send the fragment to the server. I've created a patch and will be created a bug on the Python tracker.

Cool, but this doesn't seem relevant to the user-agent profile.  Market penetration of browsers written in python is limited.
 
Does anyone know what RFC actually talks about not sending the fragment? I've seen 3986 where it explains that a fragment isn't really a part of the URI, but it's doesn't specifically say that the client should not send it to the server.

No idea.  This might be one of those things that all the browsers implement, but has never been fully specified.

There are a few notes on referers in the browsersec wiki: http://code.google.com/p/browsersec/wiki/Part1

Cheers,
Brian

--0-841599478-1280812883=:37310-- From eran@hueniverse.com Mon Aug 2 22:39:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6158D3A6843 for ; Mon, 2 Aug 2010 22:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITbbc3IBedt7 for ; Mon, 2 Aug 2010 22:39:14 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 04AE13A6803 for ; Mon, 2 Aug 2010 22:38:44 -0700 (PDT) Received: (qmail 8858 invoked from network); 3 Aug 2010 05:38:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Aug 2010 05:38:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 2 Aug 2010 22:38:07 -0700 From: Eran Hammer-Lahav To: David Stanek , "oleg@gryb.info" Date: Mon, 2 Aug 2010 22:38:11 -0700 Thread-Topic: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? Thread-Index: AcsyqWo48NbN66VwT0iYIDqrJzph5gAIxivw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A6B5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 05:39:38 -0000 RFC 2616 (5.1.2) defines the request URI as: Request-URI =3D "*" | absoluteURI | abs_path | authority And imports 'absoluteURI' from RFC 2396 (3): absoluteURI =3D scheme ":" ( hier_part | opaque_part ) hier_part =3D ( net_path | abs_path ) [ "?" query ] opaque_part =3D uric_no_slash *uric uric_no_slash =3D unreserved | escaped | ";" | "?" | ":" | "@" | "&" | "=3D" | "+" | "$" | "," uric =3D reserved | unreserved | escaped So as you can clearly :-) see, fragments are not allowed per the ABNF rules= ... --- The new HTTPbis spec had clearer ABNF rules in draft -09, but still only re= stricted the fragment in ABNF. At my request, the editors added in -10 [1]: Note: Fragments ([RFC3986], Section 3.5) are not part of the request-target and thus will not be transmitted in an HTTP request. So hopefully this is clearer now. [1] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-10#section-4= .1.2 EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D= avid Stanek Sent: Monday, August 02, 2010 6:15 PM To: oleg@gryb.info Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? On Sun, Aug 1, 2010 at 10:47 PM, Oleg Gryb wrote: I've just verified Ruby and Perl's user agents as well: both worked as expe= cted - no fragments in the web log files. It adds confidence. Thanks to eve= ryone who has answered. I just verified that the Python urllib client does send the fragment to the= server. I've created a patch and will be created a bug on the Python track= er. Does anyone know what RFC actually talks about not sending the fragment? I'= ve seen 3986 where it explains that a fragment isn't really a part of the U= RI, but it's doesn't specifically say that the client should not send it to= the server. --=20 David blog: http://www.traceback.org twitter: http://twitter.com/dstanek From beaton@google.com Mon Aug 2 23:16:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3831B3A6A44 for ; Mon, 2 Aug 2010 23:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.959 X-Spam-Level: X-Spam-Status: No, score=-101.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkquAjLD83hA for ; Mon, 2 Aug 2010 23:16:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id E00053A6868 for ; Mon, 2 Aug 2010 23:16:44 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o736HBiF026819 for ; Mon, 2 Aug 2010 23:17:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280816232; bh=J3R43I702jePoThuLkwLg+ODg+o=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=jAd07W3iDXH/41knyXtK8Ym3KI5cQZ8uyIRtWyFkvtj09eDT9b8nt5iy1fkAxr7fe TAOu+xlrU8Q7VDAqWGfLw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=HRaBh0jwhKaZIunaLKX/ejwedTC/6pWeqYXxx+UnU56tqp/2p48tvs5+VJikReFvx hyWUdsdKqn7q9QISVAcZQ== Received: from pzk7 (pzk7.prod.google.com [10.243.19.135]) by wpaz13.hot.corp.google.com with ESMTP id o736HAsi000717 for ; Mon, 2 Aug 2010 23:17:10 -0700 Received: by pzk7 with SMTP id 7so2190583pzk.27 for ; Mon, 02 Aug 2010 23:17:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.215.7 with SMTP id n7mr6328089wfg.206.1280816229332; Mon, 02 Aug 2010 23:17:09 -0700 (PDT) Received: by 10.142.195.9 with HTTP; Mon, 2 Aug 2010 23:17:09 -0700 (PDT) In-Reply-To: <204869.37310.qm@web37602.mail.mud.yahoo.com> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> Date: Mon, 2 Aug 2010 23:17:09 -0700 Message-ID: From: Brian Eaton To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 06:16:47 -0000 On Mon, Aug 2, 2010 at 10:21 PM, Oleg Gryb wrote: > Returning to our discussion about necessity of passing access_token in UR= L's > fragment, I've read both your proposal for changing=A0 v.9 and the curren= t > v.10, but still don't understand why we need access_token in a fragment. Question: why are you implementing the user-agent flow? > I think, a safer solution would be to return an access token in a respons= e > form, not in Location header. This way, we'll avoid problems with user > agents that David Stanek described and prevent browsers from storing toke= ns > in a browser's history. This is nuts. It would completely break all of the use cases the user-agent flow was designed to address. For example, let's say you want to allow third-party site thirdparty.com to embed some javascript from serviceprovider.com. The javascript should be able to: - redirect the user to serviceprovider.com, where serviceprovider.com can get user consent to share data if necessary. - receive an access token back from serviceprovider.com. - use the access token from thirdparty.com to fetch data from serviceprovider.com. - do all of the above without server-side code at thirdparty.com. - do all of the above with as few client <-> server round trips as possible= . The user-agent profile allows that. If that's not your use case, then you probably shouldn't be using the user-agent profile at all. Cheers, Brian From torsten@lodderstedt.net Tue Aug 3 04:45:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100B23A69F9 for ; Tue, 3 Aug 2010 04:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNP1gWfn8FxI for ; Tue, 3 Aug 2010 04:45:49 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by core3.amsl.com (Postfix) with ESMTP id E0B433A6949 for ; Tue, 3 Aug 2010 04:45:48 -0700 (PDT) Received: from tmo-098-40.customers.d1-online.com ([80.187.98.40] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OgFwd-00061o-Np; Tue, 03 Aug 2010 13:46:08 +0200 Message-ID: <4C58016C.8070403@lodderstedt.net> Date: Tue, 03 Aug 2010 13:45:48 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Darren Bounds References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11267EC8194@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 11:45:50 -0000 Darren, > As an OAuth 2 provider and consumer as well as someone who's preparing > to build the DiSo interactions my proposal was based on, I would > prefer a single flow that addresses what I feel will be a increasingly > common set of requirements rather than combining two flows designed > for two distinct purposes. > > I would rather put this the other way around. Your particular use case can be implemented by utilizing the building blocks already built into the specification. Great! That's what I expect from a _standard_. It provides people with atomic building blocks, they can create their solutions from. I don't think we should add every possible flow to the standard. Even regarding your proposal, much more is possible. You suggest to use the web server flow for end-user authorization if the assertion flow failed. Why not using the user agent or the username/password flow instead? Or any other way of authenticating and authorizing an end-user? That way, clients can choose the option matching their requirements and capabilities the most. Please also note your proposal has an significant impact on access token lifecycle. In step 1 you propose to issue a none-authorized access token. This means an authz server must be able to authorize access tokens after issuance, which is not required currently. Additionally, resource servers must be able to recognize none-authorized (invalid) access tokens and refuse any attempt to access resources with an access token in that state. In my opinion, this makes the tokens lifecycle much more complex and will not work in all possible setups, especially if the authorization server issues self-contained tokens. In such a setup, no direct communication takes place during request processing on the resource server. regards, Torsten. From torsten@lodderstedt.net Tue Aug 3 04:52:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2CA3A69F2 for ; Tue, 3 Aug 2010 04:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9yjbBSH9zhk for ; Tue, 3 Aug 2010 04:52:39 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.26]) by core3.amsl.com (Postfix) with ESMTP id 39B723A6A15 for ; Tue, 3 Aug 2010 04:52:38 -0700 (PDT) Received: from tmo-098-40.customers.d1-online.com ([80.187.98.40] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OgG33-0003UN-EG; Tue, 03 Aug 2010 13:53:00 +0200 Message-ID: <4C5802F0.3030007@lodderstedt.net> Date: Tue, 03 Aug 2010 13:52:16 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 11:52:41 -0000 James, > This example illustrates that OAuth2 discovery needs to let a service > explicitly indicate whether a direct and/or user-delegation flow is required. > For instance, a "WWW-Authenticate: OAuth2" response could define 2 parameters: > 'user-uri' and 'token-uri'. If only one is present, only the corresponding mode > is useful in this interaction. > In my opinion, this decision is up to the authorization server and not the resource server. egards, Torsten. > > Another interesting facet of this example is what token the app uses > at step 4. Is it the token the app got in the first OAuth2 flow (step 1), > or the token from the second OAuth2 flow (step 3)? > > Presumably the second token overrides the first. > In this example, however, it may be sufficient to keep using the first token. > OAuth2 doesn’t need to make returning a token mandatory -- it is not > always required in a user-delegation flow. > > -- > James Manger > > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Darren Bounds > Sent: Thursday, 29 July 2010 6:29 AM > To: oauth@ietf.org; pubsubhubbub@googlegroups.com; federated-social-web@googlegroups.com > Subject: [OAUTH-WG] OAuth& Protected feeds > > Please excuse the cross posting. > > Following the Federated Social Web Summit in Portland a couple weeks > ago, there has been a lot of chatter around protected feeds and how > they'll function to achieve SWAT0 > (http://federatedsocialweb.net/wiki/SWAT0). Protected feed > subscriptions are clearly an important component of DiSo and necessary > for features like remote follow/friending. > > During the summit Brett Stlakin published and discussed a document > (http://tinyurl.com/push-oauth) where he proposes one technique for > how OAuth may be used with PuSH to achieve the requirements. The > proposal details an OAuth 2 flow (in addition to OAuth 1x) for > handling a usecase that involves ToS acknowledgement before a > protected feed subscription may be granted. The flow is essentially > the web server client profile combined with the assertion grant type. > While the flow will work and achieve the goals it also has a > fundamental need for a user-agent redirect, something that not all > providers may desire or require. > > What I'd like to propose is a variant of the assertion grant type that > would make the user-agent redirect optional. The goal here was to stay > within the bounds of the current spec where ever possible. That said; > it may be desirable to break this out into it's own client profile. > > The flow detailed below is using the OAuth 2 scenario described in > Brett's document (http://tinyurl.com/push-oauth). > > 1) cliqset.com would like to request an access token from google.com. > Sends a request with grant_type=assertion. > > Request: > POST /token HTTP/1.1 > Host: google.com > Content-Type: application/x-www-form-urlencoded > > grant_type=assertion&assertion_type=http://webfinger.org/& > assertion=eyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ== > > The assertion value in the request is a Base64 encoded JSON string > with two properties, uri and magic_signature. Example: > > { > "uri": "acct:dbounds@cliqset.com", > "magic_signature": "asdlkklafsdjkldsfjlkj=" > } > > Response: > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"supersecrettoken" > "precondition_uri","http://google.com/oauth/authorize?state=opaquevalue > "code","myrandomcode123" > } > > The access token response introduces two new optional properties: > precondition_uri and code > > The existence of a precondition_uri means the consumer will be > required to redirect the user to this uri in order to complete the > activation of the provided access token. > > The precondition_uri resource has the same characteristics of the > OAuth 2.0 Web Server client profile with the ‘state’ property being > used to maintain state between the assertion request and the user > redirect. Successful acknowledgement of the precondition results in a > 302 response with the code provided in the assertion response (see > example below). > > The existence of a code is required upon the presence of a precondition_uri. > > If no precondition_uri is provided, the access token should be > considered active and immediately usable barring any provider specific > back-end authorization (e.g. user acceptance of remote follow). > > 2) access token received optional precondition_uri. Issuing user > redirect to precondition_uri with redirect_uri. > > Request: > GET /oauth/authorize?state=opaquevalue&response_type=token&client_id=acct:dbounds@cliqset.com&redirect_uri=http://cliqset.com/callback > HTTP/1.1 > Host: google.com > > User acknowledges the precondition. This could be any number of > activities, including authenticating. > > > Response: > HTTP/1.1 302 Found > Location: http://cliqset.com/callback?code=myrandomcode123 > > 3) Subscription has been authorized. ToS has been acknowledged. Compete. > > The consumer is able to activate the access_token by confirming the > code provided in the redirect. > > This flow offers what we feel are several significant advantages over > the hybrid approach. > > 1) Redirection becomes optional and is only required when the > precondition_uri is defined by the provider in the access token > response. > > 2) For providers who require TOS acknowledgement, it enables > additional flexibility in how they go about it. For example, if a > provider only requires TOS acknowledgement on the initial subscription > request by a given user, subsequent requests will not provide a > precondition_uri. > > 3) It is also worth exploring this flow as a suitable and more > flexible alternative to the traditional Web Server flow. > > > Questions? Comments? Suggestions? > > > -- > darren bounds > darren@cliqset.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Tue Aug 3 04:52:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2BF3A6A6F for ; Tue, 3 Aug 2010 04:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_20=-0.74, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7SdicTyAynP for ; Tue, 3 Aug 2010 04:52:46 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id 05BDE3A69F2 for ; Tue, 3 Aug 2010 04:52:46 -0700 (PDT) Received: from tmo-098-40.customers.d1-online.com ([80.187.98.40] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OgG3T-0004T3-NK; Tue, 03 Aug 2010 13:53:13 +0200 Message-ID: <4C58031B.60206@lodderstedt.net> Date: Tue, 03 Aug 2010 13:52:59 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Manger, James H" References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 11:52:47 -0000 James, > This example illustrates that OAuth2 discovery needs to let a service > explicitly indicate whether a direct and/or user-delegation flow is required. > For instance, a "WWW-Authenticate: OAuth2" response could define 2 parameters: > 'user-uri' and 'token-uri'. If only one is present, only the corresponding mode > is useful in this interaction. > In my opinion, this decision is up to the authorization server and not the resource server. Or should both be possible? What do you think? egards, Torsten. > > Another interesting facet of this example is what token the app uses > at step 4. Is it the token the app got in the first OAuth2 flow (step 1), > or the token from the second OAuth2 flow (step 3)? > > Presumably the second token overrides the first. > In this example, however, it may be sufficient to keep using the first token. > OAuth2 doesn’t need to make returning a token mandatory -- it is not > always required in a user-delegation flow. > > -- > James Manger > > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Darren Bounds > Sent: Thursday, 29 July 2010 6:29 AM > To: oauth@ietf.org; pubsubhubbub@googlegroups.com; federated-social-web@googlegroups.com > Subject: [OAUTH-WG] OAuth& Protected feeds > > Please excuse the cross posting. > > Following the Federated Social Web Summit in Portland a couple weeks > ago, there has been a lot of chatter around protected feeds and how > they'll function to achieve SWAT0 > (http://federatedsocialweb.net/wiki/SWAT0). Protected feed > subscriptions are clearly an important component of DiSo and necessary > for features like remote follow/friending. > > During the summit Brett Stlakin published and discussed a document > (http://tinyurl.com/push-oauth) where he proposes one technique for > how OAuth may be used with PuSH to achieve the requirements. The > proposal details an OAuth 2 flow (in addition to OAuth 1x) for > handling a usecase that involves ToS acknowledgement before a > protected feed subscription may be granted. The flow is essentially > the web server client profile combined with the assertion grant type. > While the flow will work and achieve the goals it also has a > fundamental need for a user-agent redirect, something that not all > providers may desire or require. > > What I'd like to propose is a variant of the assertion grant type that > would make the user-agent redirect optional. The goal here was to stay > within the bounds of the current spec where ever possible. That said; > it may be desirable to break this out into it's own client profile. > > The flow detailed below is using the OAuth 2 scenario described in > Brett's document (http://tinyurl.com/push-oauth). > > 1) cliqset.com would like to request an access token from google.com. > Sends a request with grant_type=assertion. > > Request: > POST /token HTTP/1.1 > Host: google.com > Content-Type: application/x-www-form-urlencoded > > grant_type=assertion&assertion_type=http://webfinger.org/& > assertion=eyJ1cmkiOiAiYWNjdDpkYm91bmRzQGNsaXFzZXQuY29tIiwibWFnaWNfc2lnbmF0dXJlIjogImFzZGxra2xhZnNkamtsZHNmamxraj0ifQ== > > The assertion value in the request is a Base64 encoded JSON string > with two properties, uri and magic_signature. Example: > > { > "uri": "acct:dbounds@cliqset.com", > "magic_signature": "asdlkklafsdjkldsfjlkj=" > } > > Response: > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "access_token":"supersecrettoken" > "precondition_uri","http://google.com/oauth/authorize?state=opaquevalue > "code","myrandomcode123" > } > > The access token response introduces two new optional properties: > precondition_uri and code > > The existence of a precondition_uri means the consumer will be > required to redirect the user to this uri in order to complete the > activation of the provided access token. > > The precondition_uri resource has the same characteristics of the > OAuth 2.0 Web Server client profile with the ‘state’ property being > used to maintain state between the assertion request and the user > redirect. Successful acknowledgement of the precondition results in a > 302 response with the code provided in the assertion response (see > example below). > > The existence of a code is required upon the presence of a precondition_uri. > > If no precondition_uri is provided, the access token should be > considered active and immediately usable barring any provider specific > back-end authorization (e.g. user acceptance of remote follow). > > 2) access token received optional precondition_uri. Issuing user > redirect to precondition_uri with redirect_uri. > > Request: > GET /oauth/authorize?state=opaquevalue&response_type=token&client_id=acct:dbounds@cliqset.com&redirect_uri=http://cliqset.com/callback > HTTP/1.1 > Host: google.com > > User acknowledges the precondition. This could be any number of > activities, including authenticating. > > > Response: > HTTP/1.1 302 Found > Location: http://cliqset.com/callback?code=myrandomcode123 > > 3) Subscription has been authorized. ToS has been acknowledged. Compete. > > The consumer is able to activate the access_token by confirming the > code provided in the redirect. > > This flow offers what we feel are several significant advantages over > the hybrid approach. > > 1) Redirection becomes optional and is only required when the > precondition_uri is defined by the provider in the access token > response. > > 2) For providers who require TOS acknowledgement, it enables > additional flexibility in how they go about it. For example, if a > provider only requires TOS acknowledgement on the initial subscription > request by a given user, subsequent requests will not provide a > precondition_uri. > > 3) It is also worth exploring this flow as a suitable and more > flexible alternative to the traditional Web Server flow. > > > Questions? Comments? Suggestions? > > > -- > darren bounds > darren@cliqset.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From torsten@lodderstedt.net Tue Aug 3 07:00:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E86D3A67D1 for ; Tue, 3 Aug 2010 07:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-DsZi2u1NmB for ; Tue, 3 Aug 2010 07:00:49 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by core3.amsl.com (Postfix) with ESMTP id 5619A3A6885 for ; Tue, 3 Aug 2010 07:00:47 -0700 (PDT) Received: from [80.187.108.16] (helo=[10.164.37.224]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OgI2c-0007El-Og; Tue, 03 Aug 2010 16:01:14 +0200 References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-3--258401510 Message-Id: <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Tue, 3 Aug 2010 15:59:39 +0200 To: Eran Hammer-Lahav X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 14:00:50 -0000 --Apple-Mail-3--258401510 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm fine with specifying OAuth discovery in an additional I-D/RFC (along wit= h the extension I have asked for). As a consequence, does this mean you will= remove all references to OAuth Discovery from the core specification? Beside that, this raises another question: Are there additional functional a= reas to be include into the core spec? How many additional WG items/ upcomin= g RFCs complementing the core spec are planned? What about the following topics? - security considerations - token revocation (requested by several attendees during Maastricht WG meet= ing) - signatures regards, Torsten. Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav : > General discussions on the list and during the interim meeting. >=20 > EHL >=20 >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Monday, August 02, 2010 1:20 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>=20 >> What consensus do you refer to? The WG charter? >>=20 >> regards, >> Torsten. >>=20 >> Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: >>> No according to WG consensus. We took it all out because too many people= >> considered it experimental, so while it may be a WG item, it is not part o= f the >> core spes. >>>=20 >>> EHL >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>>> Sent: Monday, August 02, 2010 1:07 PM >>>> To: Eran Hammer-Lahav >>>> Cc: OAuth WG (oauth@ietf.org) >>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>>>=20 >>>> and discovery does not belong into the core? >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: >>>>=20 >>>>> This doesn't belong in core. A registry is used to avoid name >>>>> collisions, not >>>>>=20 >>>> to provide an inventory. >>>>=20 >>>>> Maybe in discovery. >>>>>=20 >>>>> EHL >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf Of Torsten Lodderstedt >>>>>> Sent: Monday, August 02, 2010 12:54 PM >>>>>> To: OAuth WG (oauth@ietf.org) >>>>>> Subject: [OAUTH-WG] Extensibility: new endpoints >>>>>>=20 >>>>>> the existing authorization server endpoints (end-user authorization >>>>>> and tokens endpoint) have a relatively clearly semantics and scope. >>>>>> Adding distinct new functions to an authorization server will (in >>>>>> my >>>>>> opionion) require the definition of new endpoints. For example, I'm >>>>>> working on an I-D for token revocation. Such a function does not >>>>>> fit into the tokens endpoint since it has become a "token issuance >>>>>> endpoint" rather than a general purpose client2server endpoint. >>>>>>=20 >>>>>> I therefore would propose to include the option to define and >>>>>> register new endpoints into the Extensibility section of the spec. >>>>>> This would also facilitate the incorporation of additional >>>>>> endpoints (with well-defined names) into OAuth discovery. >>>>>>=20 >>>>>> Any thoughts? >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>=20 >=20 --Apple-Mail-3--258401510 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I'm fine with spe= cifying OAuth discovery in an additional I-D/RFC (along with the extension I= have asked for). As a consequence, does this mean you will remove all refer= ences to OAuth Discovery from the core specification?

Beside that, this raises another question: Are there additional f= unctional areas to be include into the core spec? How many additional WG ite= ms/ upcoming RFCs complementing the core spec are planned?
W= hat about the following topics?
- security considerations
- token revocation (requested by several attendees during Maas= tricht WG meeting)
- signatures

<= span>regards,
Torsten.


<= br>Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav <eran@hueniverse.com>:

General discussions on the list and during t= he interim meeting.

EHL

-----Original Message-----
From: Torsten Lodderstedt [mai= lto:torsten@lodderstedt.net]
Sent: Monday, August 02, 2010 1:20 PM
To: Eran Hammer-Lahav
Cc: OAuth WG (oa= uth@ietf.org)
Sub= ject: Re: [OAUTH-WG] Extensibility: new endpoints

What consensus do you refer to? The WG charter?

regards,
Torsten.
<= br>
Am 02.08.2010 22:18, schrieb= Eran Hammer-Lahav:
No according to WG consensus. We took it all out be= cause too many people
considered it experimental, so while it may be a WG item, it is= not part of the
core= spes.

<= blockquote type=3D"cite">EHL


-----Original Message-----
=
From: Torsten Lodderstedt [ma= ilto:torsten@lodderstedt.net]
Sent: Monday, August 02, 2010 1:07 PM
To: Eran Hammer-Lahav
<= /blockquote>
Cc: OAuth WG (oauth@ietf.org)
= Subject: Re: [OAUTH-WG] Extensibility: new endpoints

=
and discovery does not belong into the core?
=

regards,
Torsten.

Am 02.08.20= 10 22:05, schrieb Eran Hammer-Lahav:

This doesn't belong in core. A registry is used to= avoid name
=
collisions, not
<= br>
to provide an= inventory.
=
Maybe  in discovery.
=

EHL

=


-----Original Message-----
=
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=
Behalf Of Torsten Lodde= rstedt
Sent: Monda= y, August 02, 2010 12:54 PM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUT= H-WG] Extensibility: new endpoints

the existing authorization server endpoints (end-user authorization=
and tokens endpoint) ha= ve a relatively clearly semantics and scope.
Adding distinct new functions to an authorizatio= n server will (in
my
opionion) req= uire the definition of new endpoints. For example, I'm
working on an I-D for token revocation= . Such a function does not
=
fit into the tokens endpoint since it has become a "token issuance=
=
endpoint" rather= than a general purpose client2server endpoint.
<= blockquote type=3D"cite">
I therefore would propose to include the option to define and
=
register new endpo= ints into the Extensibility section of the spec.
=
This would also facilitate the incorporation= of additional
en= dpoints (with well-defined names) into OAuth discovery.

=
Any thoughts?

regards,
Torst= en.


<= blockquote type=3D"cite">_____________________________________________= __
OAuth mailing l= ist
OAuth@ietf.org
=
https://www.ietf.org/mailman/listinfo/oauth
=


=

= --Apple-Mail-3--258401510-- From torsten@lodderstedt.net Tue Aug 3 07:05:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F383A680D for ; Tue, 3 Aug 2010 07:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_05=-1.11, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jkw7dqPHwkf for ; Tue, 3 Aug 2010 07:05:56 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by core3.amsl.com (Postfix) with ESMTP id BF1933A6894 for ; Tue, 3 Aug 2010 07:05:54 -0700 (PDT) Received: from [80.187.108.16] (helo=[10.164.37.224]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OgI7n-0001Mu-Kp; Tue, 03 Aug 2010 16:06:21 +0200 References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <4C48C116.9000609@lodderstedt.net> <4C4FE913.9030508@lodderstedt.net> <4C512095.5050802@lodderstedt.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-4--258080308 Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Tue, 3 Aug 2010 16:04:49 +0200 To: Eve Maler X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 14:05:58 -0000 --Apple-Mail-4--258080308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I mean address as in "uniquely label". Based on your explanation I assume you address resources instead of resource= servers. Correct? What parameter of the end-user authorization flow is used= to indicate the resource URL to the authz server. The scope? regards, Torsten. Am 02.08.2010 um 02:16 schrieb Eve Maler : > I'm not sure if you mean "address" as in "handle", or "address" as in "uni= quely label", but... UMA's first step involves a user-delegated introduction= of a resource server to an authorization server as a special kind of client= of it, using an OAuth2 web server flow with dynamic client registration as n= ecessary. As part of this overall process, the resource server can tell the a= uthorization server specifically which resource URLs are protected thereby (= one way to do this is to wield its just-acquired access token at a protected= resource registration endpoint at the authz server). Access tokens given to= requesters (the real end-of-the-line clients) for accessing these resources= are currently assumed to be given out on a per-resource-server basis, and e= ach resource is uniquely associated with a single resource server and unique= ly protected by a single authorization server, so there is no ambiguity. I s= uppose a resource server namespace could allow for higher-order aggregation a= s discussed below but I would personally prefer baby steps when it comes to t= he amount of dynamicism we're already assuming... >=20 > If you want to follow along with the UMA work, we have floated a number of= spec drafts for these portions of our Step 1, and should shortly (within a d= ay or so) have a more fleshed-out resource registration draft ready. We're n= ot just cataloguing the resource URLs, but also the possible methods for acc= essing them; our assumption to date, as noted previously on this list, has b= een that the simple set of HTTP methods can get everyone really far -- but m= indful of the need in OAuth-land for arbitrary "space-delimited list of stri= ngs" for scope, the current nascent draft allows for this. >=20 > Eve >=20 > On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote: >=20 >> Eve, >>=20 >> how does UMA plan to address resource servers during the OAuth end-user a= uthorization process? >>=20 >> regards, >> Torsten. >>=20 >> Am 29.07.2010 02:37, schrieb Eve Maler: >>>=20 >>> Belatedly... Sorry if I sound like a broken record on this, but: Most o= f UMA's use involve letting a user introduce their various hosts (UMA-flavor= ed resource servers) to their single chosen "authorization manager" (UMA-fla= vored authorization server), by treating the former as a dynamically introdu= ced OAuth client of the latter. This sounds an awful lot like the question o= riginally posed in this thread. We have exactly the problem of figuring out h= ow the host can tell the AM what resources the AM should be protecting and w= hat can be done to them, which we've begun to solve with what we're calling a= "resource registration API" (RRAPI). >>>=20 >>> (BTW, we're also working on an I-D to submit here that proposes a soluti= on for discovery/dynamic registration that meets our needs. Hoping it can fe= ed into Eran's discovery work.) >>>=20 >>> Eve >>>=20 >>> On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote: >>>=20 >>>> thanks for sharing your thoughts. >>>>=20 >>>> Differentiating resource servers by using different end-user authorizat= ion endpoint URLs is an option. I dont't know how this will work in conjunct= ion with discovery, especially since this differentiation might by required o= n other endpoints, too. For example, if a client wants to obtain an access t= oken for the end-user's credentials, it has to identify the resource server a= lso on the tokens endpoint. There might be additional endpoint for other flo= ws with similar requirements, e.g. the device flow. >>>>=20 >>>> Based on your proposal, a derived solution could be to define a standar= d parameter "resourceserver" and to state how clients should use this parame= ter on the different endpoints. On the coding level, there would be no diffe= rence to your proposal :-) But the client would be able to construct such a U= RL on its own. >>>>=20 >>>> Authorizing access for different resource servers is indeed an issue fo= r me. How would you propose to add the namespace? Shall the scope obtained f= rom the resource server already contain such a namespace are shall there be a= rule to construct such namespaced-ed scopes in the spec? >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>> Am 25.07.2010 19:11, schrieb Andrew Arnott: >>>>>=20 >>>>> It seems to me that if one auth server can create tokens for a diverse= set of resource servers, then why not have different user authorization end= point URLs for each type of resource server, as an added differentiator for t= he scope (a namespace, if you will)? >>>>>=20 >>>>> So suppose one auth server serves two different photo services, both u= sing overlapping scopes such that a client requesting access of some scope i= s otherwise ambiguous between which resource server the client needs access t= o. The auth server that serves both resource servers could have two end use= r authorization endpoints: >>>>> http://auth.server.org/authorize?resourceserver=3D1 >>>>> http://auth.server.org/authorize?resourceserver=3D2 >>>>>=20 >>>>> And that way the auth server knows exactly what the client needs. >>>>>=20 >>>>> The only scenario this doesn't allow for is for a user to authorize a c= lient's access to both resource servers in one redirect. If this were an is= sue, perhaps you can apply a namespace-like prefix to each scope substring: >>>>>=20 >>>>> rs1:photo:read rs2:photo:read >>>>>=20 >>>>> Which would serve a similar purpose. >>>>>=20 >>>>> -- >>>>> Andrew Arnott >>>>> "I [may] not agree with what you have to say, but I'll defend to the d= eath your right to say it." - S. G. Tallentyre >>>>>=20 >>>>>=20 >>>>> On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt wrote: >>>>> no one else in the group having an opinion on this topic? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Am 15.07.2010 20:14, schrieb Marius Scurtescu: >>>>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt >>>>> wrote: >>>>> As I have written in my reply to Marius's posting. I'm fine with inclu= ding >>>>> server ids in scopes. But this requires a definition of the scope's sy= ntax >>>>> and semantics in the spec. Otherwise, scope interpretation (and server= >>>>> identification) will be deployment specific. >>>>> Sure, it is deployment specific, but why is that an issue? >>>>>=20 >>>>> In your case, the authz server and all the resource servers are >>>>> managed by the same organization, right? >>>>>=20 >>>>> Do clients need to be aware of the actual resource server? >>>>>=20 >>>>> You can probably create a separate spec that defines scope syntax for >>>>> this purpose, if really needed. Does it have to be in core? >>>>>=20 >>>>> Marius >>>>>=20 >>>>> Solving the challenge I described in a deployment specific way is not a= n issue. But the consequence is that authz server, resource servers and clie= nts are tight together. >>>>>=20 >>>>> Let me ask you one question: Why are we working together towards a sta= ndard protocol? I can tell you my expectations: I hope there will be broad s= upport not only by libraries, but also by ready-to-use services and clients,= so we could integrate such services into our deployment easily. Moreover, I= would like to see OAuth to be included in application/service protocols lik= e PortableContacts, SIP, WebDAV, IMAP, ... >>>>>=20 >>>>> So what if I would like to use standard clients to access our services= ? Using scopes for specifying resource server id's in this case is also simp= le - if you take an isolated view. But since scopes may be used to specifiy a= lot of other things, like resources, permissions, and durations, handling w= /o a more detailed spec will in practice be impossible. >>>>>=20 >>>>> Suppose a WebDAV service for media data access. Any WebDAV client know= s the WebDAV protocol (=3D=3D interface), e.g. the supported methods (GET, P= UT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is suff= icient to configure the client with the URL of my personal web storage. To s= tart with let's assume, scopes are used to designate resource servers only. S= o the server's scope could be "webstorage". >>>>>=20 >>>>> WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage" >>>>>=20 >>>>> The client could just pass this parameter to the authz server and ever= ything is fine. >>>>>=20 >>>>> On the next level, let's assume the (future) WebDAV standard with OAut= h-support uses one permission per method type. So the full scope could be as= follows: >>>>>=20 >>>>> WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage:GET= webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY webstorage= :MOVE" >>>>>=20 >>>>> Passing this scope w/o any unmodified to the authz server is not an is= sue. But this implies the client asks for full access to the users media sto= rage. Since our client is a gallery application, it requires the "GET" permi= ssion only. How does the client know which of the scope values to pick for t= he end-user authorization process? It must somehow select "webstorage:GET". >>>>>=20 >>>>> But how? >>>>>=20 >>>>> In my personal opinion, clients should be enabled to interpret, combin= e and even create scopes. And yes, this should go to the core of the spec. >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> Eve Maler >>> http://www.xmlgrrl.com/blog >>> http://www.twitter.com/xmlgrrl >>> http://www.linkedin.com/in/evemaler >>>=20 >>=20 >=20 >=20 > Eve Maler > http://www.xmlgrrl.com/blog > http://www.twitter.com/xmlgrrl > http://www.linkedin.com/in/evemaler >=20 --Apple-Mail-4--258080308 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I mean address as in "u= niquely label".

Based on your explanation I assume you address resour= ces instead of resource servers. Correct? What parameter of the end-user aut= horization flow is used to indicate the resource URL to the authz server. Th= e scope?

regards,
Torsten.



Am 02.= 08.2010 um 02:16 schrieb Eve Maler <ev= e@xmlgrrl.com>:

I'm not sure if you mean "address" as in "handle", or "address" as in= "uniquely label", but... UMA's first step involves a user-delegated introdu= ction of a resource server to an authorization server as a special kind of c= lient of it, using an OAuth2 web server flow with dynamic client registratio= n as necessary. As part of this overall process, the resource server can tel= l the authorization server specifically which resource URLs are protected th= ereby (one way to do this is to wield its just-acquired access token at a pr= otected resource registration endpoint at the authz server). Access tokens g= iven to requesters (the real end-of-the-line clients) for accessing these re= sources are currently assumed to be given out on a per-resource-server basis= , and each resource is uniquely associated with a single resource server and= uniquely protected by a single authorization server, so there is no ambigui= ty. I suppose a resource server namespace could allow for higher-order aggre= gation as discussed below but I would personally prefer baby steps when it c= omes to the amount of dynamicism we're already assuming...

If you want to follow along with the UMA work, we have floated a num= ber of spec drafts for these portions of our Step 1, and sh= ould shortly (within a day or so) have a more fleshed-out resource registrat= ion draft ready. We're not just cataloguing the resource URLs, but also the p= ossible methods for accessing them; our assumption to date, as noted previou= sly on this list, has been that the simple set of HTTP methods can get every= one really far -- but mindful of the need in OAuth-land for arbitrary "space= -delimited list of strings" for scope, the current nascent draft allows for t= his.

Eve

On 28 Jul 2010, at 11:32 PM, T= orsten Lodderstedt wrote:

Eve,

how does UMA plan to address resource servers during the OAuth end-user authorization process?

regards,
Torsten.

Am 29.07.2010 02:37, schrieb Eve Maler:
Belatedly...  Sorry if I sound like a broken record on this, but: Most of UMA's use involve letting a user introduce their various hosts (UMA-flavored resource servers) to their single chosen "authorization manager" (UMA-flavored authorization server), by treating the former as a dynamically introduced OAuth client of the latter. This sounds an awful lot like the question originally posed in this thread. We have exactly the problem of figuring out how the host can tell the AM what resources the AM should be protecting and what can be done to them, which we've begun to solve with what we're calling a "resource registration API" (RRAPI).

(BTW, we're also working on an I-D to submit here that proposes a solution for discovery/dynamic registration that meets our needs. Hoping it can feed into Eran's discovery work.)

Ev= e

On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:

thanks for sharing your thoughts.

Differentiating resource servers by using different end-user authorization endpoint URLs is an option. I dont't know how this will work in conjunction with discovery, especially since this differentiation might by required on other endpoints, too. For example, if a client wants to obtain an access token for the end-user's credentials, it has to identify the resource server also on the tokens endpoint. There might be additional endpoint for other flows with similar requirements, e.g. the device flow.

Based on your proposal, a derived solution could be to define a standard parameter "resourceserver" and to state how clients should use this parameter on the different endpoints. On the coding level, there would be no difference to your proposal :-) But the client would be able to construct such a URL on its own.

Authorizing access for different resource servers is indeed an issue for me. How would you propose to add the namespace? Shall the scope obtained from the resource server already contain such a namespace are shall there be a rule to construct such namespaced-ed scopes in the spec?

regards,
Torsten.

Am 25.07.2010 19:11, schrieb Andrew Arnott:
It seems to me that if one auth server can cre= ate tokens for a diverse set of resource servers, then why not have different user authorization endpoint URLs for each type of resource server, as an added differentiator for the scope (a namespace, if you will)?

So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to.  The auth server that serves both resource servers could have two end user authorization endpoints:
http://auth.server.org/authorize?resourceserver=3D1
http://auth.server.org/authorize?resourceserver=3D2

And that way the auth server knows exactly what the client needs.

The only scenario this doesn't allow for is for a user to authorize a client's access to both resource servers in one redirect.  If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring:

rs1:photo:read rs2:photo:read

Which would serve a similar purpose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt <torsten= @lodderstedt.net> wrote:
no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
<torsten@lodderstedt= .net>  wrote:
As I have written in my reply to Marius's posting. I'm fine with including
server ids in scopes. But this requires a definition of the scope's syntax
and semantics in the spec. Otherwise, scope interpretation (and server
identification) will be deployment specific.
Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax for
this purpose, if really needed. Does it have to be in core?

Marius

Solving the challenge I described in a deployment specific way is not an issue. But the consequence is that authz server, resource servers and clients are tight together.

Let me ask you one question: Why are we working together towards a standard protocol? I can tell you my expectations: I hope there will be broad support not only by libraries, but also by ready-to-use services and clients, so we could integrate such services into our deployment easily. Moreover, I would like to see OAuth to be included in application/service protocols like PortableContacts, SIP, WebDAV, IMAP, ...

So what if I would like to use standard clients to access our services? Using scopes for specifying resource server id's in this case is also simple - if you take an isolated view. But since scopes may be used to specifiy a lot of other things, like resources, permissions, and durations, handling w/o a more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV client knows the WebDAV protocol (=3D=3D interface), e.g. the supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is sufficient to configure the client with the URL of my personal web storage. To start with let's assume, scopes are used to designate resource servers only. So the server's scope could be "webstorage".

   WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage= "

The client could just pass this parameter to the authz server and everything is fine.

On the next level, let's assume the (future) WebDAV standard with OAuth-support uses one permission per method type. So the full scope could be as follows:

   WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage= :GET webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY webstorage:MOVE"

Passing this scope w/o any unmodified to the authz server is not an issue. But this implies the client asks for full access to the users media storage. Since our client is a gallery application, it requires the "GET" permission only. How does the client know which of the scope values to pick for the end-user authorization process? It must somehow select "webstorage:GET".

But how?

In my personal opinion, clients should be enabled to interpret, combine and even create scopes. And yes, this should go to the core of the spec.
=
regards,
Torsten.




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

_______________________________________________
OAuth mailing 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-4--258080308-- From eran@hueniverse.com Tue Aug 3 08:17:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A39773A68AF for ; Tue, 3 Aug 2010 08:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UATPDztndoQC for ; Tue, 3 Aug 2010 08:17:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5E8013A687A for ; Tue, 3 Aug 2010 08:17:06 -0700 (PDT) Received: (qmail 25442 invoked from network); 3 Aug 2010 15:17:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Aug 2010 15:17:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 3 Aug 2010 08:17:21 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Tue, 3 Aug 2010 08:17:14 -0700 Thread-Topic: [OAUTH-WG] Extensibility: new endpoints Thread-Index: AcszFFoiHyF+SO5gSJ+sLuLz3cXnYAACY1bQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> In-Reply-To: <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 15:17:08 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVG9yc3RlbiBMb2RkZXJz dGVkdCBbbWFpbHRvOnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBB dWd1c3QgMDMsIDIwMTAgNzowMCBBTQ0KPiBUbzogRXJhbiBIYW1tZXItTGFoYXYNCj4gQ2M6IE9B dXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4gU3ViamVjdDogUmU6IFtPQVVUSC1XR10gRXh0ZW5z aWJpbGl0eTogbmV3IGVuZHBvaW50cw0KPiANCj4gSSdtIGZpbmUgd2l0aCBzcGVjaWZ5aW5nIE9B dXRoIGRpc2NvdmVyeSBpbiBhbiBhZGRpdGlvbmFsIEktRC9SRkMgKGFsb25nIHdpdGgNCj4gdGhl IGV4dGVuc2lvbiBJIGhhdmUgYXNrZWQgZm9yKS4gQXMgYSBjb25zZXF1ZW5jZSwgZG9lcyB0aGlz IG1lYW4geW91IHdpbGwNCj4gcmVtb3ZlIGFsbCByZWZlcmVuY2VzIHRvIE9BdXRoIERpc2NvdmVy eSBmcm9tIHRoZSBjb3JlIHNwZWNpZmljYXRpb24/DQoNCklmIHdlIGdldCBhIGRpc2NvdmVyeSBz cGVjIHJlYWR5IGluIHRpbWUsIEknbGwgcmVmZXJlbmNlIGl0IGFzIG9uZSB3YXkgdG8gb2J0YWlu IGNvbmZpZ3VyYXRpb24gaW5mby4gT3RoZXJ3aXNlIEknbGwgcmVtb3ZlIHRoZSByZWZlcmVuY2Vz IHdoaWNoIGFyZSBhbHJlYWR5IG1hcmtlZCB3aXRoIFtdLg0KDQo+IEJlc2lkZSB0aGF0LCB0aGlz IHJhaXNlcyBhbm90aGVyIHF1ZXN0aW9uOiBBcmUgdGhlcmUgYWRkaXRpb25hbCBmdW5jdGlvbmFs DQo+IGFyZWFzIHRvIGJlIGluY2x1ZGUgaW50byB0aGUgY29yZSBzcGVjPyBIb3cgbWFueSBhZGRp dGlvbmFsIFdHIGl0ZW1zLw0KPiB1cGNvbWluZyBSRkNzIGNvbXBsZW1lbnRpbmcgdGhlIGNvcmUg c3BlYyBhcmUgcGxhbm5lZD8NCg0KSSBhbSBzdXJlIHRoZXJlIGFyZSBnb2luZyB0byBiZSBtb3Jl IFdHIGl0ZW1zLiBEaXNjb3ZlcnkgbWlnaHQgYmUgb25lLCBzaWduYXR1cmVzIGFyZSBsaWtlbHkg dG8gYmUgb25lLiBUaGVuIHRoZXJlIGlzIHRoZSBTQU1MIHdvcmssIGFydGlmYWN0IGJpbmRpbmcs IGRldmljZSBwcm9maWxlLCBVWCwgaWRlbnRpdHkuLi4NCg0KVGhlIG1haW4gcHJvYmxlbSBpcyBs YWNrIG9mIGF1dGhvcnMvZWRpdG9ycyB0byBwdXQgdGhlIHdvcmsgaW4sIG5vdCBsYWNrIG9mIGlk ZWFzLiBJIHN0aWxsIGhvcGUgdG8gZ2V0IHRoZSBkaXNjb3Zlcnkgc3BlYyBmaW5pc2hlZCBpbiB0 aGUgc2FtZSB0aW1lZnJhbWUsIGJ1dCBoYXZlIG5vIHBsYW5zIHRvIGF1dGhvciBvciBlZGl0IGFu eSBvdGhlciBkcmFmdC4NCg0KPiBXaGF0IGFib3V0IHRoZSBmb2xsb3dpbmcgdG9waWNzPw0KPiAt IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQoNClRoYXQncyBwYXJ0IG9mIGNvcmUgYW5kIHNvbWVv bmUgaGFzIHRvIHdyaXRlIGl0LiBJJ2QgbGlrZSB0byBzZWUgc29tZW9uZSB0YWtlIHRoZSBzZWN1 cml0eSBzZWN0aW9uIGZyb20gUkZDIDU4NDkgYW5kIHJld29yayBpdCB0byBtYXRjaCAyLjAsIGFz IHdlbGwgYXMgYWRkIGV2ZXJ5dGhpbmcgdGhhdCBpcyBtaXNzaW5nLiBJIHdpbGwgaW5jb3Jwb3Jh dGUgaXQgYW5kIHRha2UgY2FyZSBvZiB0aGUgZWRpdG9yaWFsIHdvcmsgYnV0IEkgYW0gbm90IHdy aXRpbmcgaXQgZnJvbSBzY3JhdGNoLg0KDQo+IC0gdG9rZW4gcmV2b2NhdGlvbiAocmVxdWVzdGVk IGJ5IHNldmVyYWwgYXR0ZW5kZWVzIGR1cmluZyBNYWFzdHJpY2h0IFdHIG1lZXRpbmcpDQoNClNv bWVvbmUgbmVlZHMgdG8gd3JpdGUgYSBwcm9wb3NhbCBhbmQgd29yayB0byBnZXQgV0cgY29uc2Vu c3VzICh0byB0aGUgcG9pbnQgd2hlcmUgZW5vdWdoIHBlb3BsZSBzYXkgdGhleSBsaWtlIGl0IGFu ZCBubyBvbmUgaXMgb2JqZWN0aW5nKS4gR2V0IGl0IHRoZXJlLCBJJ2xsIGRvIHRoZSByZXN0LiBG ZWVsIGZyZWUgdG8gYXNrIHRoZSBjaGFpcnMgdG8gaGVscCBvdXQuDQoNCj4gLSBzaWduYXR1cmVz DQoNCkkgdGhpbmsgTmF0IG9mZmVyZWQgdG8gdGFrZSBhIHN0YWIgYXQgYSBmaXJzdCBkcmFmdCBi YXNlZCBvbiBEaXJrJ3Mgd29yayBhbmQgdGhlIFdHIGRpc2N1c3Npb25zLiBJIGhhdmUgb2ZmZXJl ZCB0byBoZWxwIHdpdGggZWRpdG9yaWFsIHdvcmsgaWYgcmVxdWVzdGVkLg0KDQpFSEwNCiANCj4g cmVnYXJkcywNCj4gVG9yc3Rlbi4NCj4gDQo+IA0KPiBBbSAwMi4wOC4yMDEwIHVtIDIyOjMzIHNj aHJpZWIgRXJhbiBIYW1tZXItTGFoYXYNCj4gPGVyYW5AaHVlbml2ZXJzZS5jb20+Og0KPiBHZW5l cmFsIGRpc2N1c3Npb25zIG9uIHRoZSBsaXN0IGFuZCBkdXJpbmcgdGhlIGludGVyaW0gbWVldGlu Zy4NCj4gDQo+IEVITA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFRvcnN0ZW4gTG9kZGVyc3RlZHQgW21haWx0bzp0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldF0N Cj4gU2VudDogTW9uZGF5LCBBdWd1c3QgMDIsIDIwMTAgMToyMCBQTQ0KPiBUbzogRXJhbiBIYW1t ZXItTGFoYXYNCj4gQ2M6IE9BdXRoIFdHIChvYXV0aEBpZXRmLm9yZykNCj4gU3ViamVjdDogUmU6 IFtPQVVUSC1XR10gRXh0ZW5zaWJpbGl0eTogbmV3IGVuZHBvaW50cw0KPiANCj4gV2hhdCBjb25z ZW5zdXMgZG8geW91IHJlZmVyIHRvPyBUaGUgV0cgY2hhcnRlcj8NCj4gDQo+IHJlZ2FyZHMsDQo+ IFRvcnN0ZW4uDQo+IA0KPiBBbSAwMi4wOC4yMDEwIDIyOjE4LCBzY2hyaWViIEVyYW4gSGFtbWVy LUxhaGF2Og0KPiBObyBhY2NvcmRpbmcgdG8gV0cgY29uc2Vuc3VzLiBXZSB0b29rIGl0IGFsbCBv dXQgYmVjYXVzZSB0b28gbWFueSBwZW9wbGUNCj4gY29uc2lkZXJlZCBpdCBleHBlcmltZW50YWws IHNvIHdoaWxlIGl0IG1heSBiZSBhIFdHIGl0ZW0sIGl0IGlzIG5vdCBwYXJ0IG9mIHRoZQ0KPiBj b3JlIHNwZXMuDQo+IA0KPiBFSEwNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBUb3JzdGVuIExvZGRlcnN0ZWR0IFttYWlsdG86dG9yc3RlbkBsb2RkZXJzdGVk dC5uZXRdDQo+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDAyLCAyMDEwIDE6MDcgUE0NCj4gVG86IEVy YW4gSGFtbWVyLUxhaGF2DQo+IENjOiBPQXV0aCBXRyAob2F1dGhAaWV0Zi5vcmcpDQo+IFN1Ympl Y3Q6IFJlOiBbT0FVVEgtV0ddIEV4dGVuc2liaWxpdHk6IG5ldyBlbmRwb2ludHMNCj4gDQo+IGFu ZCBkaXNjb3ZlcnkgZG9lcyBub3QgYmVsb25nIGludG8gdGhlIGNvcmU/DQo+IA0KPiByZWdhcmRz LA0KPiBUb3JzdGVuLg0KPiANCj4gQW0gMDIuMDguMjAxMCAyMjowNSwgc2NocmllYiBFcmFuIEhh bW1lci1MYWhhdjoNCj4gDQo+IFRoaXMgZG9lc24ndCBiZWxvbmcgaW4gY29yZS4gQSByZWdpc3Ry eSBpcyB1c2VkIHRvIGF2b2lkIG5hbWUgY29sbGlzaW9ucywgbm90DQo+IA0KPiB0byBwcm92aWRl IGFuIGludmVudG9yeS4NCj4gDQo+IE1heWJlIMKgaW4gZGlzY292ZXJ5Lg0KPiANCj4gRUhMDQo+ IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG9hdXRoLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYN Cj4gT2YgVG9yc3RlbiBMb2RkZXJzdGVkdA0KPiBTZW50OiBNb25kYXksIEF1Z3VzdCAwMiwgMjAx MCAxMjo1NCBQTQ0KPiBUbzogT0F1dGggV0cgKG9hdXRoQGlldGYub3JnKQ0KPiBTdWJqZWN0OiBb T0FVVEgtV0ddIEV4dGVuc2liaWxpdHk6IG5ldyBlbmRwb2ludHMNCj4gDQo+IHRoZSBleGlzdGlu ZyBhdXRob3JpemF0aW9uIHNlcnZlciBlbmRwb2ludHMgKGVuZC11c2VyIGF1dGhvcml6YXRpb24g YW5kDQo+IHRva2VucyBlbmRwb2ludCkgaGF2ZSBhIHJlbGF0aXZlbHkgY2xlYXJseSBzZW1hbnRp Y3MgYW5kIHNjb3BlLg0KPiBBZGRpbmcgZGlzdGluY3QgbmV3IGZ1bmN0aW9ucyB0byBhbiBhdXRo b3JpemF0aW9uIHNlcnZlciB3aWxsIChpbiBteQ0KPiBvcGlvbmlvbikgcmVxdWlyZSB0aGUgZGVm aW5pdGlvbiBvZiBuZXcgZW5kcG9pbnRzLiBGb3IgZXhhbXBsZSwgSSdtIHdvcmtpbmcNCj4gb24g YW4gSS1EIGZvciB0b2tlbiByZXZvY2F0aW9uLiBTdWNoIGEgZnVuY3Rpb24gZG9lcyBub3QgZml0 IGludG8gdGhlIHRva2Vucw0KPiBlbmRwb2ludCBzaW5jZSBpdCBoYXMgYmVjb21lIGEgInRva2Vu IGlzc3VhbmNlIGVuZHBvaW50IiByYXRoZXIgdGhhbiBhDQo+IGdlbmVyYWwgcHVycG9zZSBjbGll bnQyc2VydmVyIGVuZHBvaW50Lg0KPiANCj4gSSB0aGVyZWZvcmUgd291bGQgcHJvcG9zZSB0byBp bmNsdWRlIHRoZSBvcHRpb24gdG8gZGVmaW5lIGFuZCByZWdpc3RlciBuZXcNCj4gZW5kcG9pbnRz IGludG8gdGhlIEV4dGVuc2liaWxpdHkgc2VjdGlvbiBvZiB0aGUgc3BlYy4NCj4gVGhpcyB3b3Vs ZCBhbHNvIGZhY2lsaXRhdGUgdGhlIGluY29ycG9yYXRpb24gb2YgYWRkaXRpb25hbCBlbmRwb2lu dHMgKHdpdGggd2VsbC0NCj4gZGVmaW5lZCBuYW1lcykgaW50byBPQXV0aCBkaXNjb3ZlcnkuDQo+ IA0KPiBBbnkgdGhvdWdodHM/DQo+IA0KPiByZWdhcmRzLA0KPiBUb3JzdGVuLg0KPiANCj4gDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRo IG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IA0KPiANCj4gDQoNCg== From torsten@lodderstedt.net Tue Aug 3 08:25:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0169E3A67DB for ; Tue, 3 Aug 2010 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.664 X-Spam-Level: X-Spam-Status: No, score=-0.664 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zSm+IV7H9yB for ; Tue, 3 Aug 2010 08:25:53 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id 8272E3A68AF for ; Tue, 3 Aug 2010 08:25:48 -0700 (PDT) Received: from [80.187.108.16] (helo=[10.164.37.224]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OgJNb-0005AM-Vn; Tue, 03 Aug 2010 17:26:15 +0200 References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Tue, 3 Aug 2010 17:25:28 +0200 To: Eran Hammer-Lahav X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 15:25:54 -0000 >=20 >>=20 >=20 > The main problem is lack of authors/editors to put the work in, not lack o= f ideas. I still hope to get the discovery spec finished in the same timefra= me, but have no plans to author or edit any other draft. Just to get this clear. Do you plan to author the discovery spec? And what i= s the core spec's timeframe? regards, Torsten. >=20 >> What about the following topics? >> - security considerations >=20 > That's part of core and someone has to write it. I'd like to see someone t= ake the security section from RFC 5849 and rework it to match 2.0, as well a= s add everything that is missing. I will incorporate it and take care of the= editorial work but I am not writing it from scratch. >=20 >> - token revocation (requested by several attendees during Maastricht WG m= eeting) >=20 > Someone needs to write a proposal and work to get WG consensus (to the poi= nt where enough people say they like it and no one is objecting). Get it the= re, I'll do the rest. Feel free to ask the chairs to help out. >=20 >> - signatures >=20 > I think Nat offered to take a stab at a first draft based on Dirk's work a= nd the WG discussions. I have offered to help with editorial work if request= ed. >=20 > EHL >=20 >> regards, >> Torsten. >>=20 >>=20 >> Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav >> : >> General discussions on the list and during the interim meeting. >>=20 >> EHL >>=20 >>=20 >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Monday, August 02, 2010 1:20 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>=20 >> What consensus do you refer to? The WG charter? >>=20 >> regards, >> Torsten. >>=20 >> Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: >> No according to WG consensus. We took it all out because too many people >> considered it experimental, so while it may be a WG item, it is not part o= f the >> core spes. >>=20 >> EHL >>=20 >>=20 >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Monday, August 02, 2010 1:07 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>=20 >> and discovery does not belong into the core? >>=20 >> regards, >> Torsten. >>=20 >> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: >>=20 >> This doesn't belong in core. A registry is used to avoid name collisions,= not >>=20 >> to provide an inventory. >>=20 >> Maybe in discovery. >>=20 >> EHL >>=20 >>=20 >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Monday, August 02, 2010 12:54 PM >> To: OAuth WG (oauth@ietf.org) >> Subject: [OAUTH-WG] Extensibility: new endpoints >>=20 >> the existing authorization server endpoints (end-user authorization and >> tokens endpoint) have a relatively clearly semantics and scope. >> Adding distinct new functions to an authorization server will (in my >> opionion) require the definition of new endpoints. For example, I'm worki= ng >> on an I-D for token revocation. Such a function does not fit into the tok= ens >> endpoint since it has become a "token issuance endpoint" rather than a >> general purpose client2server endpoint. >>=20 >> I therefore would propose to include the option to define and register ne= w >> endpoints into the Extensibility section of the spec. >> This would also facilitate the incorporation of additional endpoints (wit= h well- >> defined names) into OAuth discovery. >>=20 >> Any thoughts? >>=20 >> regards, >> Torsten. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >=20 From eran@hueniverse.com Tue Aug 3 08:32:09 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54D423A69FB for ; Tue, 3 Aug 2010 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl9Cgn-yM0dl for ; Tue, 3 Aug 2010 08:32:06 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2D6E23A69FC for ; Tue, 3 Aug 2010 08:32:04 -0700 (PDT) Received: (qmail 31132 invoked from network); 3 Aug 2010 15:32:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 3 Aug 2010 15:32:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 3 Aug 2010 08:32:12 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Tue, 3 Aug 2010 08:32:04 -0700 Thread-Topic: [OAUTH-WG] Extensibility: new endpoints Thread-Index: AcszIDvR7MBnlD9ZQUW/w7jgL4/ZkAAADPXg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A764@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 15:32:09 -0000 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Tuesday, August 03, 2010 8:25 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Extensibility: new endpoints >=20 > > > > The main problem is lack of authors/editors to put the work in, not lac= k of > ideas. I still hope to get the discovery spec finished in the same timefr= ame, > but have no plans to author or edit any other draft. >=20 > Just to get this clear. Do you plan to author the discovery spec? And wha= t is > the core spec's timeframe? I have started to write the discovery spec, but work on the core spec has t= aken most of my free time to do this (OAuth is not part of my day job). I have no idea what's the timeframe for the core spec. This groups isn't ve= ry good at providing timely feedback and staying focused. So far no one has= offered to work on the security consideration section (Brian's draft is to= o far from the format I need to incorporate). I am planning the next draft for early September which will include the few= changes raised on the list, but will focus on finding a middle ground betw= een detailed profiles and a generic architecture (editorial work). EHL > >> What about the following topics? > >> - security considerations > > > > That's part of core and someone has to write it. I'd like to see someon= e > take the security section from RFC 5849 and rework it to match 2.0, as we= ll as > add everything that is missing. I will incorporate it and take care of th= e > editorial work but I am not writing it from scratch. > > > >> - token revocation (requested by several attendees during Maastricht > >> WG meeting) > > > > Someone needs to write a proposal and work to get WG consensus (to the > point where enough people say they like it and no one is objecting). Get = it > there, I'll do the rest. Feel free to ask the chairs to help out. > > > >> - signatures > > > > I think Nat offered to take a stab at a first draft based on Dirk's wor= k and > the WG discussions. I have offered to help with editorial work if request= ed. > > > > EHL > > > >> regards, > >> Torsten. > >> > >> > >> Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav > >> : > >> General discussions on the list and during the interim meeting. > >> > >> EHL > >> > >> > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >> Sent: Monday, August 02, 2010 1:20 PM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints > >> > >> What consensus do you refer to? The WG charter? > >> > >> regards, > >> Torsten. > >> > >> Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: > >> No according to WG consensus. We took it all out because too many > >> people considered it experimental, so while it may be a WG item, it > >> is not part of the core spes. > >> > >> EHL > >> > >> > >> -----Original Message----- > >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >> Sent: Monday, August 02, 2010 1:07 PM > >> To: Eran Hammer-Lahav > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints > >> > >> and discovery does not belong into the core? > >> > >> regards, > >> Torsten. > >> > >> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: > >> > >> This doesn't belong in core. A registry is used to avoid name > >> collisions, not > >> > >> to provide an inventory. > >> > >> Maybe in discovery. > >> > >> EHL > >> > >> > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Monday, August 02, 2010 12:54 PM > >> To: OAuth WG (oauth@ietf.org) > >> Subject: [OAUTH-WG] Extensibility: new endpoints > >> > >> the existing authorization server endpoints (end-user authorization > >> and tokens endpoint) have a relatively clearly semantics and scope. > >> Adding distinct new functions to an authorization server will (in my > >> opionion) require the definition of new endpoints. For example, I'm > >> working on an I-D for token revocation. Such a function does not fit > >> into the tokens endpoint since it has become a "token issuance > >> endpoint" rather than a general purpose client2server endpoint. > >> > >> I therefore would propose to include the option to define and > >> register new endpoints into the Extensibility section of the spec. > >> This would also facilitate the incorporation of additional endpoints > >> (with well- defined names) into OAuth discovery. > >> > >> Any thoughts? > >> > >> regards, > >> Torsten. > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > > From mscurtescu@google.com Tue Aug 3 09:00:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DFB3A6A66 for ; Tue, 3 Aug 2010 09:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.823 X-Spam-Level: X-Spam-Status: No, score=-101.823 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRFhzsupdNAH for ; Tue, 3 Aug 2010 09:00:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 38F043A6961 for ; Tue, 3 Aug 2010 09:00:14 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o73G0frp021525 for ; Tue, 3 Aug 2010 09:00:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280851242; bh=Fm7QGk8D0TEmwOukGnughhS7nig=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=HjBHb0yCs9xwAYp54rhQ3/+EQWJpANWTWrPmrpKkAumj/BgBNLxAA1PxfE22b4Csa TEPFVOb/12pjw+GEHY/7w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=frcexgxlu/MG4s41PYBKE8lc4yy42L1r7hc2wJFJaRGqZLNjleuFktDKMqO74S+is ppqZQ5VhMkXncaN+TwWkw== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by hpaq14.eem.corp.google.com with ESMTP id o73G0Ij6006100 for ; Tue, 3 Aug 2010 09:00:40 -0700 Received: by yxm8 with SMTP id 8so2046490yxm.39 for ; Tue, 03 Aug 2010 09:00:40 -0700 (PDT) Received: by 10.101.168.7 with SMTP id v7mr8387751ano.244.1280851240156; Tue, 03 Aug 2010 09:00:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.143.4 with HTTP; Tue, 3 Aug 2010 09:00:20 -0700 (PDT) In-Reply-To: <204869.37310.qm@web37602.mail.mud.yahoo.com> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> From: Marius Scurtescu Date: Tue, 3 Aug 2010 09:00:20 -0700 Message-ID: To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 16:00:15 -0000 On Mon, Aug 2, 2010 at 10:21 PM, Oleg Gryb wrote: > Brian, > > I think, it's not so much about browsers written in Python, as about > automation (crawler) that somebody might want to use. The User-Agent profile cannot be used by crawlers, the end user needs to be present to approve. An autonomous client profile would work in this case, see section 1.4.4. Marius From oleg_gryb@yahoo.com Tue Aug 3 09:08:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932FC3A6A70 for ; Tue, 3 Aug 2010 09:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=2.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh696dEZb7e2 for ; Tue, 3 Aug 2010 09:08:55 -0700 (PDT) Received: from web37607.mail.mud.yahoo.com (web37607.mail.mud.yahoo.com [209.191.87.90]) by core3.amsl.com (Postfix) with SMTP id 9FDD73A6995 for ; Tue, 3 Aug 2010 09:08:55 -0700 (PDT) Received: (qmail 2490 invoked by uid 60001); 3 Aug 2010 16:09:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280851764; bh=+2emZdfuYmdWOscQIvuxuMcImPaOpOVr4hAOoYL3qkI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=zGo/tcPpghwrbsDPGiWEyXUWmRVbqPhEgnCgQjeiE/T9hzc4gtFFBKbvX6osHz/Gg9WJqbccUd/uKO098TgNdpRcLBTrrIA+jFO6x9I//ZfXpv6SfWvBWLDXc7vAfTfnM2qB9saAFGFg4+WPi1O5BfJMHyN6AOd2ToBM9JUPD3A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LmyAsKjj09oMOc2WnUHiwzYwRJTyfrD3Jp0xAk3FhM5fF6ko4pPbF4zS7WTKRuIe6Cmaq9H/5KcqvB8rdA6qEG2nJ1oqTKi4jmqZtgk+MKMzH0HIPBHDkIHwkbwFsT+FrNlAqe6AtzMX+k8biUrFRgg3wCQV506Oi+LD1IJuq0A=; Message-ID: <51735.1415.qm@web37607.mail.mud.yahoo.com> X-YMail-OSG: 3eZyAwgVM1mauMCyBIxNHQ7jeIfEPy8OcvTYTVPtDI4eNy2 .dDHdBqh_T9BBE4utIPaCgsaQPBpDHm1GOLJTkpcy.ca2Upy4.KXz5VVU593 Yfuwxm92YJLAWtrgS8L1kw02LLWTZGw7B6QgSKs11WAgKjKm5diqB_6kL0gk rjJk1uzDmShvcMSeQJzyNyGKWQWqEq3ba_fu305SuAGmaUzeYou3sBqZSo_o pnMUshx0LQuOXzpZkJgXwIS_BVcG.suRFYSHVUNMxPf5TOphUKxinz5qddMg NhQWrLUVMSf0uY2l0J32tKiNeUFNg3Fk6ork8LgwYMQycabPDIFn1qjrqqO9 vD16sA2QaIdtGoawfTNB2voanOJnz Received: from [208.240.243.170] by web37607.mail.mud.yahoo.com via HTTP; Tue, 03 Aug 2010 09:09:23 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> Date: Tue, 3 Aug 2010 09:09:23 -0700 (PDT) From: Oleg Gryb To: Marius Scurtescu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 16:08:57 -0000 ----- Original Message ---- > From: Marius Scurtescu > To: Oleg Gryb > Cc: oauth@ietf.org > Sent: Tue, August 3, 2010 9:00:20 AM > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > > On Mon, Aug 2, 2010 at 10:21 PM, Oleg Gryb wrote: > > Brian, > > > > I think, it's not so much about browsers written in Python, as about > > automation (crawler) that somebody might want to use. > > The User-Agent profile cannot be used by crawlers, the end user needs > to be present to approve. Why? There are crawlers that can do approval/authentication by providing credentials in a request, e.g. when you want to trade stocks at ameritrade.com, you usually need to provide creds, but if you're too lazy to do that, you can write a crawler that will do it for you. The examples are numerous and very common for the user agents written in P/R languages. Regarding AOuth, I can envision the following scenario: log to Facebook, select photos, request Facebook to print those photos at printig.com From oleg_gryb@yahoo.com Tue Aug 3 09:59:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C13C3A6ABB for ; Tue, 3 Aug 2010 09:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjdimEYcSerL for ; Tue, 3 Aug 2010 09:59:37 -0700 (PDT) Received: from web37607.mail.mud.yahoo.com (web37607.mail.mud.yahoo.com [209.191.87.90]) by core3.amsl.com (Postfix) with SMTP id EB3833A6AAB for ; Tue, 3 Aug 2010 09:59:36 -0700 (PDT) Received: (qmail 31179 invoked by uid 60001); 3 Aug 2010 17:00:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280854799; bh=AdXwLlJdfiyBFnACXN/ZUZLXN5JEqYhgrp03tkOK+nA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=JhKAKB0rB2aq6AVkwQfe5Gm5csZ27Ex4ejsyn6jmy8dKsvCrO/w11q3dhMhfgYw4F5TQvguA1tWLz4ivsx9GbF4UiPP8erxDn6KL5n0qJdqF5ux4Fiwv4GR8cHhwN6f6X0wpgGNN9Wp+wJkfPl7kYZMuCr5ACQI/aqzAnozXF4o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yLFCLunjAk2asMvBBDfK3M8UUms/+ZC4j/L+/nfr2/UE1i75v1CdM5d9JVpWwvGgvV6KdoeQx3Yqs/aJRAx0r2BtmAy2VHBO9r5yeCzDsFXMCUseM9IIZNT64myNFnhVwOJa6+Y0dG4gYtLKKdeuaITWMPXlzKzkSBKHbdhiBfk=; Message-ID: <983904.30885.qm@web37607.mail.mud.yahoo.com> X-YMail-OSG: UaATqPAVM1kXmb0.mlQw6V_t7WLzeSEtmS9VWyt5Lt9wRyz GCGy4tYr5ukH0nU1PDBVP8Ywts4AS8.hIlBWaQPC1_hMjtfsxpDM.6IwrkO2 5zKmwh5EOgSk0R9Fy5NVcvy0dvMVpm1Yqgz7nImBpEEAwFoayowbAXbvwnP0 R8lC1w_LAmZGO2hYzYwzIlLnRQtTBPOB96lxga77zs8GVinOeKH9xuq2FJpe mYVhPNmm_xK3nvkid_TeMcAbZHEOIAvNCik4jPAUbDfTI4rIX.ITro2vuUGO DDeVDoMVa3HLVWA096gXnDG26lXo3bcjnYf69MZMox5zp1mh9tX1Yeq2pRP8 rv8FFvjMYVhjwN9wj0g8x Received: from [208.240.243.170] by web37607.mail.mud.yahoo.com via HTTP; Tue, 03 Aug 2010 09:59:59 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> Date: Tue, 3 Aug 2010 09:59:59 -0700 (PDT) From: Oleg Gryb To: Brian Eaton , Oleg Gryb In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 16:59:41 -0000 > On Mon, Aug 2, 2010 at 10:21 PM, Oleg Gryb wrote: > > Returning to our discussion about necessity of passing access_token in >URL's > > fragment, I've read both your proposal for changing v.9 and the current > > v.10, but still don't understand why we need access_token in a fragment. > > Question: why are you implementing the user-agent flow? It's not helpful. Doesn't answer the qs. > > I think, a safer solution would be to return an access token in a response > > form, not in Location header. This way, we'll avoid problems with user > > agents that David Stanek described and prevent browsers from storing tokens > > in a browser's history. > > This is nuts. That's what I thought when was reading User Agent Flow in v.10, but I didn't voice it, because wanted to be polite to the authors. My opinion didn't change much after this discussion, but it probably will, after I get my answers (see below). >It would completely break all of the use cases the > user-agent flow was designed to address. > For example, let's say you want to allow third-party site > thirdparty.com to embed some javascript from serviceprovider.com. > Please provide an example of code that you would put to thirdparty.com and that would not break the use cases. Please also provide an example of response from serviceprovider.com with an access token in it (wherever it is - as I understand you want to put it to the Location header, but probably I'm wrong). > - do all of the above without server-side code at thirdparty.com. Is it a requirement/use case? Where is it written in the spec? What if thirdparty.com generates that JavaScript on the server and returns in a response? Would it be a violation of the protocol? If it would, do you want to require only static content containing that script at thirdparty.com? > - do all of the above with as few client <-> server round trips as possible. When it comes to an authentication and communication protocols, security is more important than an extra round trip in my view, otherwise people would never use SSL, which is very inefficient from performance point of view. Also, until I see the code that I've asked for above, I won't understand how that "fragment" solution will reduce the number of trips. We can see from this discussion so far that: 1. You don't know how many user agents are out there that would send the fragment with the token in a request. 2. It's not clear if that "replace" function will be sufficient to clear browser's history in numerous browsers and their versions. These are still valid security concerns. Best, Oleg. From john@jkemp.net Tue Aug 3 10:23:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E31E3A6AB5 for ; Tue, 3 Aug 2010 10:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb6kHpUlFho7 for ; Tue, 3 Aug 2010 10:23:57 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 3A8173A6950 for ; Tue, 3 Aug 2010 10:23:57 -0700 (PDT) Received: (qmail 30494 invoked by uid 0); 3 Aug 2010 17:24:25 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy1.bluehost.com with SMTP; 3 Aug 2010 17:24:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=hr8+igi3G47sS3lhM50co7NIkgf/ToxYcwh8rFEowOhl7f0QvUYVzmcXJT0wKJmH1lG5otal026wwV4wybi9d7Iopxs3J31wGM76cMdBBFDRB62RVCMGuRexSFSGgEu8; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.101]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OgLDy-000736-RX; Tue, 03 Aug 2010 11:24:25 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: Date: Tue, 3 Aug 2010 13:24:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> To: Brian Eaton X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: oleg@gryb.info, oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:23:58 -0000 On Aug 2, 2010, at 11:31 PM, Brian Eaton wrote: > On Mon, Aug 2, 2010 at 6:15 PM, David Stanek = wrote: > I just verified that the Python urllib client does send the fragment = to the server. I've created a patch and will be created a bug on the = Python tracker. >=20 > Cool, but this doesn't seem relevant to the user-agent profile. = Market penetration of browsers written in python is limited. > =20 > Does anyone know what RFC actually talks about not sending the = fragment? I've seen 3986 where it explains that a fragment isn't really = a part of the URI, but it's doesn't specifically say that the client = should not send it to the server. >=20 > No idea. This might be one of those things that all the browsers = implement, but has never been fully specified. It's actually the HTTP specification which fully defines the use of HTTP = URIs, and their syntax: = http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2 The HTTP specification of URIs does not include the fragment component = present in the generic URI specification. So, according to the URI specification, a URI can (generically) contain = a fragment. HTTP URIs should not, when participating in the HTTP protocol, send the = fragment, as this is not included in HTTP implementation parsing of the = URI (according to the specification). The fragment ID's use is then also dependent of the MIME type in use. = This allows HTML to define the usage of fragments that we're all so = familiar with (as internal links within a retrieved HTML document).=20 For HTTP implementations though, the fragment ID should clearly NOT be = sent, and if it is, that's a bug.=20 Regards, - johnk >=20 > There are a few notes on referers in the browsersec wiki: = http://code.google.com/p/browsersec/wiki/Part1 >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Tue Aug 3 10:31:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 507FD3A68DB for ; Tue, 3 Aug 2010 10:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.842 X-Spam-Level: X-Spam-Status: No, score=-105.842 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvttjMaPjDMh for ; Tue, 3 Aug 2010 10:31:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2CE3E3A6991 for ; Tue, 3 Aug 2010 10:31:38 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o73HW629032361 for ; Tue, 3 Aug 2010 10:32:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280856727; bh=uMgurlMnxyogERTOfCsUHVFt1G0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=NbyG87tGjGEk6mhQRPYVmdtyTFGWLGuD3rtmpGZSpmdWtPM6KRjqnOmToBWGLc8Ye wpEw102Jr3W1sPAt7PTJg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=HYW9tu04qgX9zYKt954/uu7Gvn08RuImtpI0C29rYafpAZBl7lNrPkB2x0ZglQLZ8 /d1cnFxPLx89VG5iFhoAQ== Received: from pwj7 (pwj7.prod.google.com [10.241.219.71]) by hpaq14.eem.corp.google.com with ESMTP id o73HVGdq006362 for ; Tue, 3 Aug 2010 10:32:05 -0700 Received: by pwj7 with SMTP id 7so1701977pwj.22 for ; Tue, 03 Aug 2010 10:32:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.73.1 with SMTP id v1mr6724613wfa.171.1280856724289; Tue, 03 Aug 2010 10:32:04 -0700 (PDT) Received: by 10.143.46.3 with HTTP; Tue, 3 Aug 2010 10:32:04 -0700 (PDT) In-Reply-To: <983904.30885.qm@web37607.mail.mud.yahoo.com> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> <983904.30885.qm@web37607.mail.mud.yahoo.com> Date: Tue, 3 Aug 2010 10:32:04 -0700 Message-ID: From: Brian Eaton To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:31:56 -0000 On Tue, Aug 3, 2010 at 9:59 AM, Oleg Gryb wrote: >> Question: why are you implementing the user-agent =A0flow? > > It's not helpful. Doesn't answer the qs. The reason I asked is because I suspect you are trying to use the user-agent flow in a way very different from other people. It's important to choose the right tool for the right job. Given that you are writing lots of server-side code, you should probably be looking at the web server flow, not the user-agent flow. > Please provide an example of code that you would put to thirdparty.com an= d that > would not break the use cases. Take a look at the facebook APIs, in particular the cross-domain communication schemes: http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication_Ch= annel > Please also provide an example of response from > serviceprovider.com with an access token in it (wherever it is - as I und= erstand > you want to put it to the Location header, but probably I'm wrong). HTTP/1.1 302 Moved Temporarily Location: http://www.thirdparty.com/rpc_relay.html#access_token=3D12345 rpc_relay.html is highly cached in the browser, so instead of incurring hundreds of ms to fetch a file, the data lands in the third-party.com javascript in under a millisecond. > Is it a requirement/use case? Yes, it's a requirement. > Where is it written in the spec? Hopefully the spec will start adding more language around specific use cases to guide developers in picking which profiles they want to use. > What if > thirdparty.com generates that JavaScript on the server and returns in a > response? Would it be a violation of the protocol? It would not be a violation of the protocol. It would be inefficient. >> - do all of the above =A0with as few client <-> server round trips as po= ssible. > > When it comes to an authentication and communication protocols, security = is more > important than an extra round trip in my view, otherwise people would nev= er use > SSL, which is very inefficient from performance point of view. SSL inefficiency is largely mythical: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html. > Also, until I see > the code that I've asked for above, I won't understand how that "fragment= " > solution will reduce the number of trips. HTH. If this hasn't been helpful, you want want to run up firebug and visit a web site like iGoogle. Watch the number of requests triggered in the browser, and watch how many are served from cache. Cheers, Brian From oleg_gryb@yahoo.com Tue Aug 3 10:33:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8866D3A6ABD for ; Tue, 3 Aug 2010 10:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKa37M3SSb2Q for ; Tue, 3 Aug 2010 10:33:17 -0700 (PDT) Received: from web37605.mail.mud.yahoo.com (web37605.mail.mud.yahoo.com [209.191.87.88]) by core3.amsl.com (Postfix) with SMTP id 969213A6AC0 for ; Tue, 3 Aug 2010 10:33:16 -0700 (PDT) Received: (qmail 23980 invoked by uid 60001); 3 Aug 2010 17:33:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280856822; bh=Ys5isA+fnbRC3U4TpEjJ1/qoO1azzX2I26fhu3kNh+0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=sA0qaV8tfs4OhlFXA4gr1mkqXVjYO+yoXm+ECHB84o7BrOQZ/ExFt2Sz3eog57HF5lao2MKv8qbMn4FseowPxJ4QhQG1TjPQBLjMWQ6dIhq5//Rxf1fEzrvZRsj5DTrrZB9WT0jYgFS29GRhdpxGYJ9i1930haSsPCwrKH2WewQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ftPz8q5d4wqUr7FYqOCVj1pDmmGKJCHslfQCdfcAAZHGWiXRV6IqfEKGLf0uF5Olaxw+R2VAgTTmGpClXp4P1HTc2ZI82fSyObnnFnM/BcNgw4BlsD2JWOH/J8IkiD8q+GZb+Mcv+kMNHavIxb+fxOOkaQ8abEZ8fRmFCMfUKNo=; Message-ID: <450348.22430.qm@web37605.mail.mud.yahoo.com> X-YMail-OSG: FUWjkAwVM1m_5PJSbhwpwfyZ1hqZ1op6SGDUvYKbxXmWMyB AqiwLwX3b3wXdZnWJjBh5AdUEApeBNK6ItTeatu_Sd3WFA.L7UOzu36R9Tdj uGyU8zMq4WVLgQ9o5rMag7Kyl5nUhRq6U22o2uqtsyCr6ImZpdB.H3dcTrJl tPCKdHXjJxwqH.PxKMp2lYOKSWob72.aKEsO_8xUw1nurtKq4kcx_iPgmBCQ bpw7KmQwfy5.K_KhifUq1GULTCauDtOecm2XeALO6ZRkPbwt3kS8dc5C5j4W vkpjbTCHVpIqc3Z1EIZyhfSyIHIjYCzEW1TFB8sLgVCJD9ciBEcAOgXf5K0H rMEi.qUv7X1iorXUcia0ALfdI Received: from [208.240.243.170] by web37605.mail.mud.yahoo.com via HTTP; Tue, 03 Aug 2010 10:33:42 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> Date: Tue, 3 Aug 2010 10:33:42 -0700 (PDT) From: Oleg Gryb To: John Kemp , Brian Eaton In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:33:26 -0000 ----- Original Message ---- > From: John Kemp > To: Brian Eaton > Cc: oleg@gryb.info; oauth@ietf.org > Sent: Tue, August 3, 2010 10:24:19 AM > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > HTTP URIs should not, when participating in the HTTP protocol, send the >fragment, as this is not included in HTTP implementation parsing of the URI >(according to the specification). That's interesting, so if somebody puts a fragment to Location header, which is a part of HTTP protocol, it will be a violation of the protocol and can be considered as a server side bug? See 14.2 in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. Location = "Location" ":" absoluteURI From eran@hueniverse.com Tue Aug 3 10:39:03 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A11983A6831 for ; Tue, 3 Aug 2010 10:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCUM6HfPDn36 for ; Tue, 3 Aug 2010 10:39:01 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B17663A6845 for ; Tue, 3 Aug 2010 10:39:01 -0700 (PDT) Received: (qmail 4065 invoked from network); 3 Aug 2010 17:39:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 3 Aug 2010 17:39:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 3 Aug 2010 10:39:10 -0700 From: Eran Hammer-Lahav To: Oleg Gryb , John Kemp , Brian Eaton Date: Tue, 3 Aug 2010 10:39:02 -0700 Thread-Topic: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? Thread-Index: AcszMh+jvmI0rZorRkahDJJYHP0InQAAImPQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A80F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <450348.22430.qm@web37605.mail.mud.yahoo.com> In-Reply-To: <450348.22430.qm@web37605.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:39:04 -0000 Fragments are perfectly valid in the Location header URI: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4 EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Oleg Gryb > Sent: Tuesday, August 03, 2010 10:34 AM > To: John Kemp; Brian Eaton > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? >=20 >=20 >=20 >=20 >=20 > ----- Original Message ---- > > From: John Kemp > > To: Brian Eaton > > Cc: oleg@gryb.info; oauth@ietf.org > > Sent: Tue, August 3, 2010 10:24:19 AM > > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > > HTTP URIs should not, when participating in the HTTP protocol, send > >the fragment, as this is not included in HTTP implementation parsing > >of the URI (according to the specification). >=20 > That's interesting, so if somebody puts a fragment to Location header, wh= ich > is a part of HTTP protocol, it will be a violation of the protocol and ca= n be > considered as a server side bug? >=20 > See 14.2 in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. >=20 >=20 > Location =3D "Location" ":" absoluteURI >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From john@jkemp.net Tue Aug 3 10:50:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E83423A6831 for ; Tue, 3 Aug 2010 10:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFfNHQqAqxr5 for ; Tue, 3 Aug 2010 10:50:42 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id C71F93A687D for ; Tue, 3 Aug 2010 10:50:42 -0700 (PDT) Received: (qmail 16027 invoked by uid 0); 3 Aug 2010 17:51:11 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy1.bluehost.com with SMTP; 3 Aug 2010 17:51:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=Q7IMV2C8G77f77VYRwDjpHFr7EEjcE9t+DT2aSggJ4mIc2Kkz6agfY1aV3eiKWVzRVO2b4gzwFXSd6ceKaMhyucH0uOiWo6B2J7tSCtYNnMmTvgwsjqFxH2l2KfEU7ET; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.101]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OgLdv-0005lB-1X; Tue, 03 Aug 2010 11:51:11 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A80F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 3 Aug 2010 13:51:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <90C00A9C-3F1D-47D7-9FFF-4F235B856847@jkemp.net> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <450348.22430.qm@web37605.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A80F@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:50:44 -0000 Yes, that's correct, as HTTP adopts the definition of 'absoluteURI' from = the URI specification itself. It's just in the protocol itself that = fragments are not sent. =46rom RFC2616: "This specification adopts the definitions of = "URI-reference", "absoluteURI", "relativeURI", "port", = "host","abs_path", "rel_path", and "authority" from that specification" = (where 'that' refers to RFC2396). It then proceeds to restrict URIs used = in the HTTP scheme itself as being: http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] Fragments are not valid in the protocol itself, but they often are = elsewhere (depending on the usage, and which specifications apply). As = Eran says, they are perfectly valid in a Location HTTP header. Regards, - johnk On Aug 3, 2010, at 1:39 PM, Eran Hammer-Lahav wrote: > Fragments are perfectly valid in the Location header URI: >=20 > = http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4 >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Oleg Gryb >> Sent: Tuesday, August 03, 2010 10:34 AM >> To: John Kemp; Brian Eaton >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? >>=20 >>=20 >>=20 >>=20 >>=20 >> ----- Original Message ---- >>> From: John Kemp >>> To: Brian Eaton >>> Cc: oleg@gryb.info; oauth@ietf.org >>> Sent: Tue, August 3, 2010 10:24:19 AM >>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? >>> HTTP URIs should not, when participating in the HTTP protocol, send >>> the fragment, as this is not included in HTTP implementation = parsing >>> of the URI (according to the specification). >>=20 >> That's interesting, so if somebody puts a fragment to Location = header, which >> is a part of HTTP protocol, it will be a violation of the protocol = and can be >> considered as a server side bug? >>=20 >> See 14.2 in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. >>=20 >>=20 >> Location =3D "Location" ":" absoluteURI >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From oleg_gryb@yahoo.com Tue Aug 3 11:44:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7743A6A33 for ; Tue, 3 Aug 2010 11:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLQvB9U7oRMk for ; Tue, 3 Aug 2010 11:44:02 -0700 (PDT) Received: from web37603.mail.mud.yahoo.com (web37603.mail.mud.yahoo.com [209.191.87.86]) by core3.amsl.com (Postfix) with SMTP id BE71B3A6915 for ; Tue, 3 Aug 2010 11:44:02 -0700 (PDT) Received: (qmail 72962 invoked by uid 60001); 3 Aug 2010 18:44:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280861066; bh=fGGtr07gIhHXbptZk5FK/RXaU5V2NTbYMXTPy8OgOpA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hFga+g6QTV70IjXgDrH6luT9x2Mc1hB+1K7MILnZSyHTh+XtCYO7bG9sqAuEJkjnba0mJ+ruRgNTvbRjBEQYT3nl6PbDk8Ywl05KJPN94dvvf7uYxMG4gadxqdSOOASeBvuZEyX22aKqrGTrhPBEQDfgPK+IIuELGNDyVpGmSg0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1JAhblMMuNrsJmsnBZBD5CW/PZiy1ZHiY7ODSz1dyuRx1uj9flVdrv8HvdCkoldbhaYXfOhskS4wBm4rYh5a6o6nSp4taOEJ/UbZXRcL4BcoBXy2odVj9qRKg8HaGg9XVyAb6SIWcUQa+KtW7t7cN9VAAEnW1P7818MFMhjFuM0=; Message-ID: <826575.70974.qm@web37603.mail.mud.yahoo.com> X-YMail-OSG: 5_oVkrIVM1kLmG9cx_wVm6HddeyUM3_d5R3vQjnp72cs335 CnOS6y0LJjMAFUSP7B7QKvuvgdZkWz3FY458USfMgle18zuheFvlasVy77aI QOPehH1gYgiIk2Mo5W21VmYEQjq6iGSU9LyBOhwKJk_az45SccJm44G8AeCt eA48czppOHKo5lXFGdaq.IBebmHVUSZ0JWmFXpuM7GeqrXIMSbG_Y3Tx.fTl dK0_rAmRJw1AVFfiYLWXEmJIUCJf8U8kKVP5ekpJdEpNDLdnzDiOmpjyRGwg 1_GJIdQe3NKxyaSUciWFayM6rRfYZsOPOTpQaVjECfZZKnjrXaI5YJySIWyE Eo_52Qw-- Received: from [208.240.243.170] by web37603.mail.mud.yahoo.com via HTTP; Tue, 03 Aug 2010 11:44:26 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <450348.22430.qm@web37605.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A80F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C00A9C-3F1D-47D7-9FFF-4F235B856847@jkemp.net> Date: Tue, 3 Aug 2010 11:44:26 -0700 (PDT) From: Oleg Gryb To: John Kemp In-Reply-To: <90C00A9C-3F1D-47D7-9FFF-4F235B856847@jkemp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 18:44:04 -0000 ----- Original Message ---- > From: John Kemp > To: Eran Hammer-Lahav > Cc: Oleg Gryb ; "oauth@ietf.org" > Sent: Tue, August 3, 2010 10:51:09 AM > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > > Yes, that's correct, as HTTP adopts the definition of 'absoluteURI' from the >URI specification itself. It's just in the protocol itself that fragments are >not sent. > > From RFC2616: "This specification adopts the definitions of "URI-reference", >"absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and >"authority" from that specification" (where 'that' refers to RFC2396). It then >proceeds to restrict URIs used in the HTTP scheme itself as being: > > http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] > > Fragments are not valid in the protocol itself, but they often are elsewhere >(depending on the usage, and which specifications apply). As Eran says, they >are perfectly valid in a Location HTTP header. Definition of absoluteURI in RFC2396 doesn't include fragment. Fragment is explicitly defined in URI-reference only. URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] If authors wanted to have fragment in absoluteURI, why would they use the syntax above for URI-reference? Location header is not defined through URI-reference, it's defined through absoluteURI in the current version of RFC2616: Location = "Location" ":" absoluteURI The only puzzle for me is the definition and example that Eran has provided at http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4 It's a draft though, where absoluteURI in Location header definition was replaced with URI-reference, so Location header has been redefined as follows: Location = "Location" ":" OWS Location-v Location-v = URI-reference The draft will replace RFC2616 IF approved. Until then, fragments in Location header should be considered as HTTP protocol violation, I think. Changing definitions retrospectively in the existing protocol looks like a bad idea: it can break some HTTP clients that expect absouteURI in Location, but it's a topic for a different discussion. > - johnk > > On Aug 3, 2010, at 1:39 PM, Eran Hammer-Lahav wrote: > > > Fragments are perfectly valid in the Location header URI: > > > > http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4 > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > >> Of Oleg Gryb > >> Sent: Tuesday, August 03, 2010 10:34 AM > >> To: John Kemp; Brian Eaton > >> Cc: oauth@ietf.org > >> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > >> > >> > >> > >> > >> > >> ----- Original Message ---- > >>> From: John Kemp > >>> To: Brian Eaton > >>> Cc: oleg@gryb.info; oauth@ietf.org > >>> Sent: Tue, August 3, 2010 10:24:19 AM > >>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > >>> HTTP URIs should not, when participating in the HTTP protocol, send > >>> the fragment, as this is not included in HTTP implementation parsing > >>> of the URI (according to the specification). > >> > >> That's interesting, so if somebody puts a fragment to Location header, >which > >> is a part of HTTP protocol, it will be a violation of the protocol and can >be > >> considered as a server side bug? > >> > >> See 14.2 in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. > >> > >> > >> Location = "Location" ":" absoluteURI > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From eve@xmlgrrl.com Tue Aug 3 12:09:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF213A6ADA for ; Tue, 3 Aug 2010 12:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_40=-0.185, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NkuGfQuuQ7v for ; Tue, 3 Aug 2010 12:09:16 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 512B13A6AB9 for ; Tue, 3 Aug 2010 12:09:14 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o73J9gB3008040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Aug 2010 12:09:42 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1850--239812220 From: Eve Maler In-Reply-To: Date: Tue, 3 Aug 2010 12:09:42 -0700 Message-Id: <9F58EB83-D74D-4DB6-B27E-0780F759176F@xmlgrrl.com> References: <4C3F3F6A.5000409@lodderstedt.net> <4C3F9064.6060604@lodderstedt.net> <4C48C116.9000609@lodderstedt.net> <4C4FE913.9030508@lodderstedt.net> <4C512095.5050802@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] resource server id needed? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:09:18 -0000 --Apple-Mail-1850--239812220 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The "scope flow" is intended to carry this information, and the authz = manager/server compares the requested scope to a known mapping of = protected resources to resource servers. (We're still working out = details, and also trying to keep up with the changes to the OAuth2 = substrate...) Eve On 3 Aug 2010, at 7:04 AM, Torsten Lodderstedt wrote: > I mean address as in "uniquely label". >=20 > Based on your explanation I assume you address resources instead of = resource servers. Correct? What parameter of the end-user authorization = flow is used to indicate the resource URL to the authz server. The = scope? >=20 > regards, > Torsten. >=20 >=20 >=20 > Am 02.08.2010 um 02:16 schrieb Eve Maler : >=20 >> I'm not sure if you mean "address" as in "handle", or "address" as in = "uniquely label", but... UMA's first step involves a user-delegated = introduction of a resource server to an authorization server as a = special kind of client of it, using an OAuth2 web server flow with = dynamic client registration as necessary. As part of this overall = process, the resource server can tell the authorization server = specifically which resource URLs are protected thereby (one way to do = this is to wield its just-acquired access token at a protected resource = registration endpoint at the authz server). Access tokens given to = requesters (the real end-of-the-line clients) for accessing these = resources are currently assumed to be given out on a per-resource-server = basis, and each resource is uniquely associated with a single resource = server and uniquely protected by a single authorization server, so there = is no ambiguity. I suppose a resource server namespace could allow for = higher-order aggregation as discussed below but I would personally = prefer baby steps when it comes to the amount of dynamicism we're = already assuming... >>=20 >> If you want to follow along with the UMA work, we have floated a = number of spec drafts for these portions of our Step 1, and should = shortly (within a day or so) have a more fleshed-out resource = registration draft ready. We're not just cataloguing the resource URLs, = but also the possible methods for accessing them; our assumption to = date, as noted previously on this list, has been that the simple set of = HTTP methods can get everyone really far -- but mindful of the need in = OAuth-land for arbitrary "space-delimited list of strings" for scope, = the current nascent draft allows for this. >>=20 >> Eve >>=20 >> On 28 Jul 2010, at 11:32 PM, Torsten Lodderstedt wrote: >>=20 >>> Eve, >>>=20 >>> how does UMA plan to address resource servers during the OAuth = end-user authorization process? >>>=20 >>> regards, >>> Torsten. >>>=20 >>> Am 29.07.2010 02:37, schrieb Eve Maler: >>>>=20 >>>> Belatedly... Sorry if I sound like a broken record on this, but: = Most of UMA's use involve letting a user introduce their various hosts = (UMA-flavored resource servers) to their single chosen "authorization = manager" (UMA-flavored authorization server), by treating the former as = a dynamically introduced OAuth client of the latter. This sounds an = awful lot like the question originally posed in this thread. We have = exactly the problem of figuring out how the host can tell the AM what = resources the AM should be protecting and what can be done to them, = which we've begun to solve with what we're calling a "resource = registration API" (RRAPI). >>>>=20 >>>> (BTW, we're also working on an I-D to submit here that proposes a = solution for discovery/dynamic registration that meets our needs. Hoping = it can feed into Eran's discovery work.) >>>>=20 >>>> Eve >>>>=20 >>>> On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote: >>>>=20 >>>>> thanks for sharing your thoughts. >>>>>=20 >>>>> Differentiating resource servers by using different end-user = authorization endpoint URLs is an option. I dont't know how this will = work in conjunction with discovery, especially since this = differentiation might by required on other endpoints, too. For example, = if a client wants to obtain an access token for the end-user's = credentials, it has to identify the resource server also on the tokens = endpoint. There might be additional endpoint for other flows with = similar requirements, e.g. the device flow. >>>>>=20 >>>>> Based on your proposal, a derived solution could be to define a = standard parameter "resourceserver" and to state how clients should use = this parameter on the different endpoints. On the coding level, there = would be no difference to your proposal :-) But the client would be able = to construct such a URL on its own. >>>>>=20 >>>>> Authorizing access for different resource servers is indeed an = issue for me. How would you propose to add the namespace? Shall the = scope obtained from the resource server already contain such a namespace = are shall there be a rule to construct such namespaced-ed scopes in the = spec? >>>>>=20 >>>>> regards, >>>>> Torsten. >>>>>=20 >>>>> Am 25.07.2010 19:11, schrieb Andrew Arnott: >>>>>>=20 >>>>>> It seems to me that if one auth server can create tokens for a = diverse set of resource servers, then why not have different user = authorization endpoint URLs for each type of resource server, as an = added differentiator for the scope (a namespace, if you will)? >>>>>>=20 >>>>>> So suppose one auth server serves two different photo services, = both using overlapping scopes such that a client requesting access of = some scope is otherwise ambiguous between which resource server the = client needs access to. The auth server that serves both resource = servers could have two end user authorization endpoints: >>>>>> http://auth.server.org/authorize?resourceserver=3D1 >>>>>> http://auth.server.org/authorize?resourceserver=3D2 >>>>>>=20 >>>>>> And that way the auth server knows exactly what the client needs. >>>>>>=20 >>>>>> The only scenario this doesn't allow for is for a user to = authorize a client's access to both resource servers in one redirect. = If this were an issue, perhaps you can apply a namespace-like prefix to = each scope substring: >>>>>>=20 >>>>>> rs1:photo:read rs2:photo:read >>>>>>=20 >>>>>> Which would serve a similar purpose. >>>>>>=20 >>>>>> -- >>>>>> Andrew Arnott >>>>>> "I [may] not agree with what you have to say, but I'll defend to = the death your right to say it." - S. G. Tallentyre >>>>>>=20 >>>>>>=20 >>>>>> On Thu, Jul 22, 2010 at 3:07 PM, Torsten Lodderstedt = wrote: >>>>>> no one else in the group having an opinion on this topic? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Am 15.07.2010 20:14, schrieb Marius Scurtescu: >>>>>> On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt >>>>>> wrote: >>>>>> As I have written in my reply to Marius's posting. I'm fine with = including >>>>>> server ids in scopes. But this requires a definition of the = scope's syntax >>>>>> and semantics in the spec. Otherwise, scope interpretation (and = server >>>>>> identification) will be deployment specific. >>>>>> Sure, it is deployment specific, but why is that an issue? >>>>>>=20 >>>>>> In your case, the authz server and all the resource servers are >>>>>> managed by the same organization, right? >>>>>>=20 >>>>>> Do clients need to be aware of the actual resource server? >>>>>>=20 >>>>>> You can probably create a separate spec that defines scope syntax = for >>>>>> this purpose, if really needed. Does it have to be in core? >>>>>>=20 >>>>>> Marius >>>>>>=20 >>>>>> Solving the challenge I described in a deployment specific way is = not an issue. But the consequence is that authz server, resource servers = and clients are tight together. >>>>>>=20 >>>>>> Let me ask you one question: Why are we working together towards = a standard protocol? I can tell you my expectations: I hope there will = be broad support not only by libraries, but also by ready-to-use = services and clients, so we could integrate such services into our = deployment easily. Moreover, I would like to see OAuth to be included in = application/service protocols like PortableContacts, SIP, WebDAV, IMAP, = ... >>>>>>=20 >>>>>> So what if I would like to use standard clients to access our = services? Using scopes for specifying resource server id's in this case = is also simple - if you take an isolated view. But since scopes may be = used to specifiy a lot of other things, like resources, permissions, and = durations, handling w/o a more detailed spec will in practice be = impossible. >>>>>>=20 >>>>>> Suppose a WebDAV service for media data access. Any WebDAV client = knows the WebDAV protocol (=3D=3D interface), e.g. the supported methods = (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So = it is sufficient to configure the client with the URL of my personal web = storage. To start with let's assume, scopes are used to designate = resource servers only. So the server's scope could be "webstorage". >>>>>>=20 >>>>>> WWW-Authenticate OAuth realm=3D'webstorage' scope=3D"webstorage"= >>>>>>=20 >>>>>> The client could just pass this parameter to the authz server and = everything is fine. >>>>>>=20 >>>>>> On the next level, let's assume the (future) WebDAV standard with = OAuth-support uses one permission per method type. So the full scope = could be as follows: >>>>>>=20 >>>>>> WWW-Authenticate OAuth realm=3D'webstorage' = scope=3D"webstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE = webstorage:COPY webstorage:MOVE" >>>>>>=20 >>>>>> Passing this scope w/o any unmodified to the authz server is not = an issue. But this implies the client asks for full access to the users = media storage. Since our client is a gallery application, it requires = the "GET" permission only. How does the client know which of the scope = values to pick for the end-user authorization process? It must somehow = select "webstorage:GET". >>>>>>=20 >>>>>> But how? >>>>>>=20 >>>>>> In my personal opinion, clients should be enabled to interpret, = combine and even create scopes. And yes, this should go to the core of = the spec. >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> Eve Maler >>>> http://www.xmlgrrl.com/blog >>>> http://www.twitter.com/xmlgrrl >>>> http://www.linkedin.com/in/evemaler >>>>=20 >>=20 >>=20 >> Eve Maler >> http://www.xmlgrrl.com/blog >> http://www.twitter.com/xmlgrrl >> http://www.linkedin.com/in/evemaler >>=20 Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler --Apple-Mail-1850--239812220 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Eve

On 3 Aug = 2010, at 7:04 AM, Torsten Lodderstedt wrote:

I mean address as in "uniquely label".

Based = on your explanation I assume you address resources instead of resource = servers. Correct? What parameter of the end-user authorization flow is = used to indicate the resource URL to the authz server. The = scope?

regards,
Torsten.



Am = 02.08.2010 um 02:16 schrieb Eve Maler <eve@xmlgrrl.com>:

I'm not sure if you mean = "address" as in "handle", or "address" as in "uniquely label", but... = UMA's first step involves a user-delegated introduction of a resource = server to an authorization server as a special kind of client of it, = using an OAuth2 web server flow with dynamic client registration as = necessary. As part of this overall process, the resource server can tell = the authorization server specifically which resource URLs are protected = thereby (one way to do this is to wield its just-acquired access token = at a protected resource registration endpoint at the authz server). = Access tokens given to requesters (the real end-of-the-line clients) for = accessing these resources are currently assumed to be given out on a = per-resource-server basis, and each resource is uniquely associated with = a single resource server and uniquely protected by a single = authorization server, so there is no ambiguity. I suppose a resource = server namespace could allow for higher-order aggregation as discussed = below but I would personally prefer baby steps when it comes to the = amount of dynamicism we're already = assuming...

If you want to follow along with = the UMA work, we have floated a number of spec drafts for these portions of our Step 1, and should = shortly (within a day or so) have a more fleshed-out resource = registration draft ready. We're not just cataloguing the resource URLs, = but also the possible methods for accessing them; our assumption to = date, as noted previously on this list, has been that the simple set of = HTTP methods can get everyone really far -- but mindful of the need in = OAuth-land for arbitrary "space-delimited list of strings" for scope, = the current nascent draft allows for = this.

Eve

On 28 Jul = 2010, at 11:32 PM, Torsten Lodderstedt wrote:

Eve,

how does UMA plan to address resource servers during the OAuth end-user authorization process?

regards,
Torsten.

Am 29.07.2010 02:37, schrieb Eve Maler:
Belatedly...  Sorry if I sound like a broken record on this, but: Most of UMA's use involve letting a user introduce their various hosts (UMA-flavored resource servers) to their single chosen "authorization manager" (UMA-flavored authorization server), by treating the former as a dynamically introduced OAuth client of the latter. This sounds an awful lot like the question originally posed in this thread. We have exactly the problem of figuring out how the host can tell the AM what resources the AM should be protecting and what can be done to them, which we've begun to solve with what we're calling a "resource registration API" (RRAPI).

(BTW, we're also working on an I-D to submit here that proposes a solution for discovery/dynamic registration that meets our needs. Hoping it can feed into Eran's discovery work.)

= Eve

On 28 Jul 2010, at 1:23 AM, Torsten Lodderstedt wrote:

thanks for sharing your thoughts.

Differentiating resource servers by using different end-user authorization endpoint URLs is an option. I dont't know how this will work in conjunction with discovery, especially since this differentiation might by required on other endpoints, too. For example, if a client wants to obtain an access token for the end-user's credentials, it has to identify the resource server also on the tokens endpoint. There might be additional endpoint for other flows with similar requirements, e.g. the device flow.

Based on your proposal, a derived solution could be to define a standard parameter "resourceserver" and to state how clients should use this parameter on the different endpoints. On the coding level, there would be no difference to your proposal :-) But the client would be able to construct such a URL on its own.

Authorizing access for different resource servers is indeed an issue for me. How would you propose to add the namespace? Shall the scope obtained from the resource server already contain such a namespace are shall there be a rule to construct such namespaced-ed scopes in the spec?

regards,
Torsten.

Am 25.07.2010 19:11, schrieb Andrew Arnott:
It seems to me that if one auth server can create tokens for a diverse set of resource servers, then why not have different user authorization endpoint URLs for each type of resource server, as an added differentiator for the scope (a namespace, if you will)?

So suppose one auth server serves two different photo services, both using overlapping scopes such that a client requesting access of some scope is otherwise ambiguous between which resource server the client needs access to.  The auth server that serves both resource servers could have two end user authorization endpoints:

And that way the auth server knows exactly what the client needs.

The only scenario this doesn't allow for is for a user to authorize a client's access to both resource servers in one redirect.  If this were an issue, perhaps you can apply a namespace-like prefix to each scope substring:

rs1:photo:read rs2:photo:read

Which would serve a similar purpose.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre


On Thu, Jul 22, 2010 at 3:07 PM, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
no one else in the group having an opinion on this topic?



Am 15.07.2010 20:14, schrieb Marius Scurtescu:
On Thu, Jul 15, 2010 at 10:03 AM, Torsten Lodderstedt
<torsten@lodderstedt.net> =  wrote:
As I have written in my reply to Marius's posting. I'm fine with including
server ids in scopes. But this requires a definition of the scope's syntax
and semantics in the spec. Otherwise, scope interpretation (and = server
identification) will be deployment specific.
Sure, it is deployment specific, but why is that an issue?

In your case, the authz server and all the resource servers are
managed by the same organization, right?

Do clients need to be aware of the actual resource server?

You can probably create a separate spec that defines scope syntax = for
this purpose, if really needed. Does it have to be in core?

Marius

Solving the challenge I described in a deployment specific way is not an issue. But the consequence is that authz server, resource servers and clients are tight together.

Let me ask you one question: Why are we working together towards a standard protocol? I can tell you my expectations: I hope there will be broad support not only by libraries, but also by ready-to-use services and clients, so we could integrate such services into our deployment easily. Moreover, I would like to see OAuth to be included in application/service protocols like PortableContacts, SIP, WebDAV, IMAP, ...

So what if I would like to use standard clients to access our services? Using scopes for specifying resource server id's in this case is also simple - if you take an isolated view. But since scopes may be used to specifiy a lot of other things, like resources, permissions, and durations, handling w/o a more detailed spec will in practice be impossible.

Suppose a WebDAV service for media data access. Any WebDAV client knows the WebDAV protocol (=3D=3D interface), e.g. the supported methods (GET, PUT, POST, DELETE, COPY, MOVE) and how to traverse directories. So it is sufficient to configure the client with the URL of my personal web storage. To start with let's assume, scopes are used to designate resource servers only. So the server's scope could be "webstorage".

   WWW-Authenticate OAuth realm=3D'webstorage' = scope=3D"webstorage"

The client could just pass this parameter to the authz server and everything is fine.

On the next level, let's assume the (future) WebDAV standard with OAuth-support uses one permission per method type. So the full scope could be as follows:

   WWW-Authenticate OAuth realm=3D'webstorage' = scope=3D"webstorage:GET webstorage:PUT webstorage:POST webstorage:DELETE webstorage:COPY webstorage:MOVE"

Passing this scope w/o any unmodified to the authz server is not an issue. But this implies the client asks for full access to the users media storage. Since our client is a gallery application, it requires the "GET" permission only. How does the client know which of the scope values to pick for the end-user authorization process? It must somehow select "webstorage:GET".

But how?

In my personal opinion, clients should be enabled to interpret, combine and even create scopes. And yes, this should go to the core of the = spec.

regards,
Torsten.




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

_______________________________________________
OAuth mailing 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-1850--239812220-- From ynir@checkpoint.com Tue Aug 3 12:44:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 434213A69C9 for ; Tue, 3 Aug 2010 12:44:53 -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=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YmD7fzR05ff for ; Tue, 3 Aug 2010 12:44:51 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 3C1183A6974 for ; Tue, 3 Aug 2010 12:44:50 -0700 (PDT) X-CheckPoint: {4C587D3D-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o73Jj0Dq018997; Tue, 3 Aug 2010 22:45:00 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 3 Aug 2010 22:45:31 +0300 From: Yoav Nir To: Brian Eaton Date: Tue, 3 Aug 2010 22:44:58 +0300 Thread-Topic: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? Thread-Index: AcszRG3TiDDSGFKNR5Wh/7EaHppTCA== Message-ID: <5B1DD06D-DF6E-4F51-8BF8-A59EDE31E0DB@checkpoint.com> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> <983904.30885.qm@web37607.mail.mud.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5B1DD06DDF6E4F518BF8A59EDE31E0DBcheckpointcom_" MIME-Version: 1.0 Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:44:53 -0000 --_000_5B1DD06DDF6E4F518BF8A59EDE31E0DBcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote: Please provide an example of code that you would put to thirdparty.com and that would not break the use cases. Take a look at the facebook APIs, in particular the cross-domain communication schemes: http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication_Ch= annel Please also provide an example of response from serviceprovider.com with an access token in it (wherever it is - as I under= stand you want to put it to the Location header, but probably I'm wrong). HTTP/1.1 302 Moved Temporarily Location: http://www.thirdparty.com/rpc_relay.html#access_token=3D12345 rpc_relay.html is highly cached in the browser, so instead of incurring hundreds of ms to fetch a file, the data lands in the third-party.com javascript in under a millisecond. So if the browser works correctly (instead of what the python library does,= then thirdparty.com sees only "GET rpc_relay.html",= while the javascript also gets the "access_token=3D12345". What I'm not getting is why this matters. Is this supposed to be about secu= rity? It can't be any good at that, because the javascript is coming from = thirdparty.com. If the good people at thirdparty.com= want to know the access token, they can make their = javascript send it to them. So what is the purpose of this funky use of HT= TP? Is the access token a secret? From who? I thought to look in the Security Considerations section, but that is still= TBD, which can be considered worrying at this stage. What assumptions can = be made security-wise of each participant really has to be spelled out bett= er. --_000_5B1DD06DDF6E4F518BF8A59EDE31E0DBcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Aug 3, 20= 10, at 8:32 PM, Brian Eaton wrote:

Please provide an example of code that you would put to thirdparty.com and that
would not break the use cases.

Ta= ke a look at the facebook APIs, in particular the cross-domain
communica= tion schemes:

http://wiki.developers.facebook.com/= index.php/Cross_Domain_Communication_Channel

Please also provide an example of response from
serviceprovider.com with an access token in it (where= ver it is - as I understand
you w= ant to put it to the Location header, but probably I'm wrong).

HTTP/1.1 302 Moved Temporarily

Location: http://www.thirdpar= ty.com/rpc_relay.html#access_token=3D12345

rpc_relay.html is highly = cached in the browser, so instead of
incurring hundreds of ms to fetch a= file, the data lands in the
third-party.com javascript in under a milli= second.
=
So if the browser works correctly (instead of w= hat the python library does, then thirdpa= rty.com sees only "GET rpc_relay.html", while the javascript also gets = the "access_token=3D12345".

What I'm not getting i= s why this matters. Is this supposed to be about security?  It can't b= e any good at that, because the javascript is coming from thirdparty.com. If the good people at thirdparty.com want to know the access token, they ca= n make their javascript send it to them.  So what is the purpose of th= is funky use of HTTP? Is the access token a secret? From who?
I thought to look in the Security Considerations section, but t= hat is still TBD, which can be considered worrying at this stage. What assu= mptions can be made security-wise of each participant really has to be spel= led out better.

= --_000_5B1DD06DDF6E4F518BF8A59EDE31E0DBcheckpointcom_-- From bcampbell@pingidentity.com Tue Aug 3 13:11:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3593A69C6 for ; Tue, 3 Aug 2010 13:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biKAL48rW8cA for ; Tue, 3 Aug 2010 13:11:45 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id 509F43A6972 for ; Tue, 3 Aug 2010 13:11:44 -0700 (PDT) Received: from source ([74.125.82.48]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTFh4HL2KFaPTvC/fQY0yPs8mt3HdouG8@postini.com; Tue, 03 Aug 2010 13:12:14 PDT Received: by mail-ww0-f48.google.com with SMTP id 39so1143774wwb.5 for ; Tue, 03 Aug 2010 13:12:12 -0700 (PDT) Received: by 10.216.30.207 with SMTP id k57mr6751849wea.88.1280866332426; Tue, 03 Aug 2010 13:12:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Tue, 3 Aug 2010 13:11:42 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 3 Aug 2010 14:11:42 -0600 Message-ID: To: Anthony Nadalin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 20:11:48 -0000 Seems like a much more complicated scenario. Allowing more than one assertion, off the top of my head, would necessitate some major changes to this profile: * Define how multiple assertions are encoded into the single "assertion" form control (samlp:Response, concatenated, something else?) * Deal with subject equality across the assertions * Define the processing rules for multiple assertion (from different issuers) and the expected behavior when some but not all are valid. That seems like it would add significant complexity to the existing draft (that I'm trying to keep simple) for a particular scenario that I'm not sure is very common. But maybe I'm wrong. Is this something that others anticipate needing? If so, does it belong here? On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin wro= te: > So the scenario we have is where there are multiple tokens from attribute= and identity providers need to be delivered to an OAuth authorization serv= er to satisfy the resource owner's policy of required claims. So this is a = case where a single SAML token/assertion is not enough to satisfy the claim= , we still expect that the signature verification is out of scope. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Brian Campbell > Sent: Monday, August 02, 2010 2:53 PM > To: oauth > Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 d= raft > > I guess I'd need to understand the scenario better before I'd have an > opinion one way or the other. =A0 However, I will say that In this > profile I was specifically looking to avoid the complexity that exists in= SAML Web SSO by allowing for multiple assertions and multiple subject conf= irmations. > > On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin w= rote: >> There are many cases where we need to have more than 1 SAML assertion be= used to represent the authorization token, so would want a provision for m= ultiple SAML tokens and not sure it makes sense to have a separate profile = for that or add it as an option here. >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Campbell >> Sent: Thursday, July 15, 2010 1:50 PM >> To: oauth >> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >> draft >> >> I'm gong to join the growing list of people attaching a potential I-D >> to an email due to he cut off time for the I-D submissions. =A0Attached >> is a draft that aims to tightly define the particular format of a SAML >> 2.0 bearer assertion in requesting an access token using the assertion >> grant_type. =A0 I've been working with Chuck at Salesforce.com on this >> and the primary goal is to have some documentation or specification >> that is sufficient to facilitate interoperability between >> independently developed implementations or products. =A0 =A0This, of cou= rse, wouldn't preclude using SAML in other ways - it would only provide one= concrete definition to implement against. >> >> I intend to submit this as an I-D when the submission process reopens. >> =A0Any feedback from this group would be appreciated as well as thoughts= about this eventually becoming a working group draft. >> >> Thanks, >> Brian Campbell >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From mscurtescu@google.com Tue Aug 3 13:18:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3103A6AF9 for ; Tue, 3 Aug 2010 13:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.69 X-Spam-Level: X-Spam-Status: No, score=-105.69 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkgk8599251a for ; Tue, 3 Aug 2010 13:18:42 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 749BA3A6972 for ; Tue, 3 Aug 2010 13:18:42 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o73KJALN006905 for ; Tue, 3 Aug 2010 13:19:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280866751; bh=DFRr/yJg6+gzJIEDj2RCe58bRUc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=xlMJirBlI7xnuO7mOraPfJ8CuEQYo6L9I9AxN9zGmd5ASs5FkEYb5eoqLVRYfB+FM RUS4jgp7tBh8fpvyBA6og== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=sQtxqxgH7AyuuSJF/VrWh8p0TGAQ8Cn1DNyhibfVBGgXcv5CQpdWnUt4L0xQlOuXK himHEJ4ExfjunF5GvguwQ== Received: from yxg6 (yxg6.prod.google.com [10.190.2.134]) by hpaq5.eem.corp.google.com with ESMTP id o73KJ8ml025073 for ; Tue, 3 Aug 2010 13:19:09 -0700 Received: by yxg6 with SMTP id 6so1821702yxg.5 for ; Tue, 03 Aug 2010 13:19:08 -0700 (PDT) Received: by 10.100.91.1 with SMTP id o1mr8698634anb.186.1280866748169; Tue, 03 Aug 2010 13:19:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.143.4 with HTTP; Tue, 3 Aug 2010 13:18:47 -0700 (PDT) In-Reply-To: <5B1DD06D-DF6E-4F51-8BF8-A59EDE31E0DB@checkpoint.com> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> <983904.30885.qm@web37607.mail.mud.yahoo.com> <5B1DD06D-DF6E-4F51-8BF8-A59EDE31E0DB@checkpoint.com> From: Marius Scurtescu Date: Tue, 3 Aug 2010 13:18:47 -0700 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 20:18:44 -0000 On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir wrote: > > On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote: > > Please provide an example of code that you would put to thirdparty.com an= d > that > > would not break the use cases. > > Take a look at the facebook APIs, in particular the cross-domain > communication schemes: > > http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication_= Channel > > Please also provide an example of response from > > serviceprovider.com with an access token in it (wherever it is - as I > understand > > you want to put it to the Location header, but probably I'm wrong). > > HTTP/1.1 302 Moved Temporarily > > Location: http://www.thirdparty.com/rpc_relay.html#access_token=3D12345 > > rpc_relay.html is highly cached in the browser, so instead of > incurring hundreds of ms to fetch a file, the data lands in the > third-party.com javascript in under a millisecond. > > So if the browser works correctly (instead of what the python library doe= s, > then thirdparty.com sees only "GET rpc_relay.html", while the javascript > also gets the "access_token=3D12345". > What I'm not getting is why this matters. Is this supposed to be about > security? =A0It can't be any good at that, because the javascript is comi= ng > from thirdparty.com. If the good people at thirdparty.com want to know th= e > access token, they can make their javascript send it to them. =A0So what = is > the purpose of this funky use of HTTP? Is the access token a secret? From > who? Passing the access toke through the URL is insecure and prone to leaking. If in the query string then the access token my leak through: - log files, web server at thirdparty.com and any number of proxies - browser history - referer header Putting the access token into the fragment, and also using JavaScript to clean the URL as soon as the token is extracted, mitigates most of these issues. Marius From ynir@checkpoint.com Tue Aug 3 13:28:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC8D3A688D for ; Tue, 3 Aug 2010 13:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3ezc8wC8if5 for ; Tue, 3 Aug 2010 13:28:26 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 8E3E73A6AFF for ; Tue, 3 Aug 2010 13:28:22 -0700 (PDT) X-CheckPoint: {4C588770-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o73KShDq022948; Tue, 3 Aug 2010 23:28:43 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 3 Aug 2010 23:29:14 +0300 From: Yoav Nir To: Marius Scurtescu Date: Tue, 3 Aug 2010 23:28:42 +0300 Thread-Topic: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? Thread-Index: AcszSolGik8wUlDdTe+O246oB/05+g== Message-ID: References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> <983904.30885.qm@web37607.mail.mud.yahoo.com> <5B1DD06D-DF6E-4F51-8BF8-A59EDE31E0DB@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 20:28:27 -0000 On Aug 3, 2010, at 11:18 PM, Marius Scurtescu wrote: > On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir wrote: >>=20 >> On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote: >>=20 >> Please provide an example of code that you would put to thirdparty.com a= nd >> that >>=20 >> would not break the use cases. >>=20 >> Take a look at the facebook APIs, in particular the cross-domain >> communication schemes: >>=20 >> http://wiki.developers.facebook.com/index.php/Cross_Domain_Communication= _Channel >>=20 >> Please also provide an example of response from >>=20 >> serviceprovider.com with an access token in it (wherever it is - as I >> understand >>=20 >> you want to put it to the Location header, but probably I'm wrong). >>=20 >> HTTP/1.1 302 Moved Temporarily >>=20 >> Location: http://www.thirdparty.com/rpc_relay.html#access_token=3D12345 >>=20 >> rpc_relay.html is highly cached in the browser, so instead of >> incurring hundreds of ms to fetch a file, the data lands in the >> third-party.com javascript in under a millisecond. >>=20 >> So if the browser works correctly (instead of what the python library do= es, >> then thirdparty.com sees only "GET rpc_relay.html", while the javascript >> also gets the "access_token=3D12345". >> What I'm not getting is why this matters. Is this supposed to be about >> security? It can't be any good at that, because the javascript is comin= g >> from thirdparty.com. If the good people at thirdparty.com want to know t= he >> access token, they can make their javascript send it to them. So what i= s >> the purpose of this funky use of HTTP? Is the access token a secret? Fro= m >> who? >=20 > Passing the access toke through the URL is insecure and prone to > leaking. Insecure against what? Prone to leaking of what to whom? > If in the query string then the access token my leak through: > - log files, web server at thirdparty.com and any number of proxies > - browser history > - referer header You're counting a lot on the javascript. That Javascript is coming from thi= rdparty.com. So we have to assume both trustworthiness and competence of th= e people in thirdparty. >=20 > Putting the access token into the fragment, and also using JavaScript > to clean the URL as soon as the token is extracted, mitigates most of > these issues. I think a security considerations section (different for each profile) is d= esperately needed. From mscurtescu@google.com Tue Aug 3 13:38:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC1A3A6B0C for ; Tue, 3 Aug 2010 13:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.834 X-Spam-Level: X-Spam-Status: No, score=-101.834 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrZLAp5hAHNR for ; Tue, 3 Aug 2010 13:38:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1580E3A683E for ; Tue, 3 Aug 2010 13:38:43 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o73KdBT6021625 for ; Tue, 3 Aug 2010 13:39:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280867951; bh=G1CbmNJxIdlI8Tlvo0ynTfln9Kc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=xF0oNCcu66b7Cal+dV7bCoIlRkILSFn1PTwdJojnnChQavruZSFG96GAyI1qVfKO9 VebIaOEICtlI+asBtUghw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=Tz2tTGUJsBp3RvDkmzIIw18mrAcryXLgbq33Ji39KCoxyxnx1Y6X6QJUrdqfvpUYE zEtZnSnEerREasWgiQu8g== Received: from ywa6 (ywa6.prod.google.com [10.192.1.6]) by hpaq14.eem.corp.google.com with ESMTP id o73Kcu7Q007121 for ; Tue, 3 Aug 2010 13:39:10 -0700 Received: by ywa6 with SMTP id 6so2138609ywa.39 for ; Tue, 03 Aug 2010 13:39:10 -0700 (PDT) Received: by 10.100.209.14 with SMTP id h14mr8792914ang.106.1280867950203; Tue, 03 Aug 2010 13:39:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.143.4 with HTTP; Tue, 3 Aug 2010 13:38:50 -0700 (PDT) In-Reply-To: References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> <983904.30885.qm@web37607.mail.mud.yahoo.com> <5B1DD06D-DF6E-4F51-8BF8-A59EDE31E0DB@checkpoint.com> From: Marius Scurtescu Date: Tue, 3 Aug 2010 13:38:50 -0700 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 20:38:45 -0000 On Tue, Aug 3, 2010 at 1:28 PM, Yoav Nir wrote: > > On Aug 3, 2010, at 11:18 PM, Marius Scurtescu wrote: > >> On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir wrote: >>> >>> On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote: >>> >>> Please provide an example of code that you would put to thirdparty.com = and >>> that >>> >>> would not break the use cases. >>> >>> Take a look at the facebook APIs, in particular the cross-domain >>> communication schemes: >>> >>> http://wiki.developers.facebook.com/index.php/Cross_Domain_Communicatio= n_Channel >>> >>> Please also provide an example of response from >>> >>> serviceprovider.com with an access token in it (wherever it is - as I >>> understand >>> >>> you want to put it to the Location header, but probably I'm wrong). >>> >>> HTTP/1.1 302 Moved Temporarily >>> >>> Location: http://www.thirdparty.com/rpc_relay.html#access_token=3D12345 >>> >>> rpc_relay.html is highly cached in the browser, so instead of >>> incurring hundreds of ms to fetch a file, the data lands in the >>> third-party.com javascript in under a millisecond. >>> >>> So if the browser works correctly (instead of what the python library d= oes, >>> then thirdparty.com sees only "GET rpc_relay.html", while the javascrip= t >>> also gets the "access_token=3D12345". >>> What I'm not getting is why this matters. Is this supposed to be about >>> security? =A0It can't be any good at that, because the javascript is co= ming >>> from thirdparty.com. If the good people at thirdparty.com want to know = the >>> access token, they can make their javascript send it to them. =A0So wha= t is >>> the purpose of this funky use of HTTP? Is the access token a secret? Fr= om >>> who? >> >> Passing the access toke through the URL is insecure and prone to >> leaking. > > Insecure against what? Prone to leaking of what to whom? > >> If in the query string then the access token my leak through: >> - log files, web server at thirdparty.com and any number of proxies >> - browser history >> - referer header > > You're counting a lot on the javascript. That Javascript is coming from t= hirdparty.com. So we have to assume both trustworthiness and competence of = the people in thirdparty. Yes, definitely, thirdparty.com must be trusted, it is the client that the end user is authorizing. >> Putting the access token into the fragment, and also using JavaScript >> to clean the URL as soon as the token is extracted, mitigates most of >> these issues. > > I think a security considerations section (different for each profile) is= desperately needed. True. Marius From beaton@google.com Tue Aug 3 13:44:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3B773A69E7 for ; Tue, 3 Aug 2010 13:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.845 X-Spam-Level: X-Spam-Status: No, score=-105.845 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HJCnJ2HqPr8 for ; Tue, 3 Aug 2010 13:44:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BFE403A6AEA for ; Tue, 3 Aug 2010 13:44:53 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o73KjMgW006365 for ; Tue, 3 Aug 2010 13:45:22 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280868322; bh=b4XwrbBfgfc8sFyKBmSzSVVKwAU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=R2BTTxNDRKklbifYjWKSZ32nhv0iQqC9FUYIojcseNzM65R32DOqRtMTqT934MCD9 RyqgJYBcf4emULs8cXbBQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=UBnevC/Yz//p7mTdFN/WNePOic9T3wp4MfVzkXKhXpQLE1NIwvYUchOZGEuJBNsZV Vtqf3KSE4LMHZUgbUP/PQ== Received: from gxk24 (gxk24.prod.google.com [10.202.11.24]) by wpaz37.hot.corp.google.com with ESMTP id o73Kj1EA008704 for ; Tue, 3 Aug 2010 13:45:21 -0700 Received: by gxk24 with SMTP id 24so2172283gxk.13 for ; Tue, 03 Aug 2010 13:45:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.81.7 with SMTP id e7mr6234848agb.109.1280868318569; Tue, 03 Aug 2010 13:45:18 -0700 (PDT) Received: by 10.90.30.3 with HTTP; Tue, 3 Aug 2010 13:45:18 -0700 (PDT) In-Reply-To: References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> <983904.30885.qm@web37607.mail.mud.yahoo.com> <5B1DD06D-DF6E-4F51-8BF8-A59EDE31E0DB@checkpoint.com> Date: Tue, 3 Aug 2010 13:45:18 -0700 Message-ID: From: Brian Eaton To: Marius Scurtescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 20:44:59 -0000 Yoav - You can take a look at this as a starting point: http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsid= erations/OAuthWRAP2.0SecurityConsiderations.pdf On Tue, Aug 3, 2010 at 1:38 PM, Marius Scurtescu wr= ote: > On Tue, Aug 3, 2010 at 1:28 PM, Yoav Nir wrote: >> >> On Aug 3, 2010, at 11:18 PM, Marius Scurtescu wrote: >> >>> On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir wrote: >>>> >>>> On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote: >>>> >>>> Please provide an example of code that you would put to thirdparty.com= and >>>> that >>>> >>>> would not break the use cases. >>>> >>>> Take a look at the facebook APIs, in particular the cross-domain >>>> communication schemes: >>>> >>>> http://wiki.developers.facebook.com/index.php/Cross_Domain_Communicati= on_Channel >>>> >>>> Please also provide an example of response from >>>> >>>> serviceprovider.com with an access token in it (wherever it is - as I >>>> understand >>>> >>>> you want to put it to the Location header, but probably I'm wrong). >>>> >>>> HTTP/1.1 302 Moved Temporarily >>>> >>>> Location: http://www.thirdparty.com/rpc_relay.html#access_token=3D1234= 5 >>>> >>>> rpc_relay.html is highly cached in the browser, so instead of >>>> incurring hundreds of ms to fetch a file, the data lands in the >>>> third-party.com javascript in under a millisecond. >>>> >>>> So if the browser works correctly (instead of what the python library = does, >>>> then thirdparty.com sees only "GET rpc_relay.html", while the javascri= pt >>>> also gets the "access_token=3D12345". >>>> What I'm not getting is why this matters. Is this supposed to be about >>>> security? =A0It can't be any good at that, because the javascript is c= oming >>>> from thirdparty.com. If the good people at thirdparty.com want to know= the >>>> access token, they can make their javascript send it to them. =A0So wh= at is >>>> the purpose of this funky use of HTTP? Is the access token a secret? F= rom >>>> who? >>> >>> Passing the access toke through the URL is insecure and prone to >>> leaking. >> >> Insecure against what? Prone to leaking of what to whom? >> >>> If in the query string then the access token my leak through: >>> - log files, web server at thirdparty.com and any number of proxies >>> - browser history >>> - referer header >> >> You're counting a lot on the javascript. That Javascript is coming from = thirdparty.com. So we have to assume both trustworthiness and competence of= the people in thirdparty. > > Yes, definitely, thirdparty.com must be trusted, it is the client that > the end user is authorizing. > > >>> Putting the access token into the fragment, and also using JavaScript >>> to clean the URL as soon as the token is extracted, mitigates most of >>> these issues. >> >> I think a security considerations section (different for each profile) i= s desperately needed. > > True. > > > Marius > From beaton@google.com Tue Aug 3 13:47:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDAE3A6B18 for ; Tue, 3 Aug 2010 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.96 X-Spam-Level: X-Spam-Status: No, score=-101.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlipLtJsHYVf for ; Tue, 3 Aug 2010 13:47:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C73E33A6B19 for ; Tue, 3 Aug 2010 13:47:09 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id o73KlaLV002122 for ; Tue, 3 Aug 2010 13:47:37 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280868457; bh=AkVp9sI/FRPRoMBVU7u+tPt7HJE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=VjQZM6O1WUvLcJ5DH/LFxpIlMh540JbDP6lvFTwdo4mj6Q/QQeZ97/Gs95vNt6O1r q5xhCdjcvQ2BD5+R+HW+Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=RuEYA4V9JMV258lBxEd6T9W6LNTiGlsnqmgd9s/6xKoYYD+Q10eC5PJWEtshfltsV Y5NnKm1syh+uFoqzyx7Cg== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by kpbe18.cbf.corp.google.com with ESMTP id o73KlJ5r015828 for ; Tue, 3 Aug 2010 13:47:35 -0700 Received: by gyb11 with SMTP id 11so2262195gyb.14 for ; Tue, 03 Aug 2010 13:47:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.119.18 with SMTP id r18mr5851722agc.92.1280868454032; Tue, 03 Aug 2010 13:47:34 -0700 (PDT) Received: by 10.90.30.3 with HTTP; Tue, 3 Aug 2010 13:47:33 -0700 (PDT) In-Reply-To: <5B1DD06D-DF6E-4F51-8BF8-A59EDE31E0DB@checkpoint.com> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> <983904.30885.qm@web37607.mail.mud.yahoo.com> <5B1DD06D-DF6E-4F51-8BF8-A59EDE31E0DB@checkpoint.com> Date: Tue, 3 Aug 2010 13:47:33 -0700 Message-ID: From: Brian Eaton To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 20:47:17 -0000 On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir wrote: > So if the browser works correctly (instead of what the python library doe= s, > then thirdparty.com sees only "GET rpc_relay.html", while the javascript > also gets the "access_token=3D12345". In the average case, thirdparty.com doesn't even see GET /rpc_relay.html. The page is cached in the browser. So the access_token has moved from serviceprovider.com to thirdparty.com, where javascript on thirdparty.com can use it. > What I'm not getting is why this matters. Is this supposed to be about > security? =A0It can't be any good at that, because the javascript is comi= ng > from thirdparty.com. If the good people at thirdparty.com want to know th= e > access token, they can make their javascript send it to them. =A0So what = is > the purpose of this funky use of HTTP? It is in large part a performance optimization. If you pass the token through a server, it adds hundreds of milliseconds to the request. If you pass the token entirely on the client, it is under a millisecond. > Is the access token a secret? From who? If you aren't sure about this, you don't want OAuth. From john@jkemp.net Tue Aug 3 14:23:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5FA3A681A for ; Tue, 3 Aug 2010 14:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOONhboMHFHR for ; Tue, 3 Aug 2010 14:23:24 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 3F3F43A6AE0 for ; Tue, 3 Aug 2010 14:23:24 -0700 (PDT) Received: (qmail 22759 invoked by uid 0); 3 Aug 2010 21:23:52 -0000 Received: from unknown (HELO box320.bluehost.com) (69.89.31.120) by cpoproxy2.bluehost.com with SMTP; 3 Aug 2010 21:23:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=jkemp.net; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Identified-User; b=0DEVuE5CgOjb7Xtn6BS0VpVQI1ktuKTHEUPyLnOdyC/HaLmXENoi88wuEIcbJXtbFlzXY5ET7pdR/Yj02p6rruzXumW3iq0DDVTKjvQ8zLxgxwN14miiGeMfDEkovTEg; Received: from cpe-69-205-56-47.nycap.res.rr.com ([69.205.56.47] helo=[192.168.1.103]) by box320.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OgOxk-000838-Cv; Tue, 03 Aug 2010 15:23:52 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: John Kemp In-Reply-To: <826575.70974.qm@web37603.mail.mud.yahoo.com> Date: Tue, 3 Aug 2010 17:23:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3963E15F-1889-40C5-A0B2-AB044CBA4DC1@jkemp.net> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <450348.22430.qm@web37605.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A80F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C00A9C-3F1D-47D7-9FFF-4F235B856847@jkemp.net> <826575.70974.qm@web37603.mail.mud.yahoo.com> To: Oleg Gryb X-Mailer: Apple Mail (2.1081) X-Identified-User: {1122:box320.bluehost.com:jkempnet:jkemp.net} {sentby:smtp auth 69.205.56.47 authed with john+jkemp.net} Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 21:23:25 -0000 On Aug 3, 2010, at 2:44 PM, Oleg Gryb wrote: >=20 > Definition of absoluteURI in RFC2396 doesn't include fragment. = Fragment is=20 > explicitly defined in URI-reference only. Yes. you're right. My mistake. >=20 > URI-reference =3D [ absoluteURI | relativeURI ] [ "#" fragment ] >=20 > If authors wanted to have fragment in absoluteURI, why would they use = the syntax=20 > above for URI-reference? >=20 > Location header is not defined through URI-reference, it's defined = through=20 > absoluteURI in the current version of RFC2616: And I guess that actually the URI spec itself has been updated since = RFC2616 (see RFC3986) and now has the fragment part included in the = generic syntax ;) >=20 > Location =3D "Location" ":" absoluteURI >=20 > The only puzzle for me is the definition and example that Eran has = provided at=20 > = http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4 Yes, this draft references RFC3986... >=20 > It's a draft though, where absoluteURI in Location header definition = was=20 > replaced with URI-reference, so Location header has been redefined as = follows: >=20 >=20 > Location =3D "Location" ":" OWS Location-v > Location-v =3D URI-reference >=20 > The draft will replace RFC2616 IF approved. Until then, fragments in = Location=20 > header should be considered as HTTP protocol violation, I think. >=20 > Changing definitions retrospectively in the existing protocol looks = like a bad=20 > idea: it can break some HTTP clients that expect absouteURI in = Location, but=20 > it's a topic for a different discussion. Well, things are a bit confusing, certainly, but it seems to me that a) in 2616bis, fragment in Location seems to be explicitly legal b) in 2616, it is not, but if, for example, an implementation were = attempting to conform to both the newer URI spec (RFC3986) and RFC2616, = there might be confusion, but the fragment might well be parsed anyway, = depending on the implementation I would guess.=20 - johnk >=20 >=20 >=20 >> - johnk >>=20 >> On Aug 3, 2010, at 1:39 PM, Eran Hammer-Lahav wrote: >>=20 >>> Fragments are perfectly valid in the Location header URI: >>>=20 >>> = http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4 >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >>>> Of Oleg Gryb >>>> Sent: Tuesday, August 03, 2010 10:34 AM >>>> To: John Kemp; Brian Eaton >>>> Cc: oauth@ietf.org >>>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> ----- Original Message ---- >>>>> From: John Kemp >>>>> To: Brian Eaton >>>>> Cc: oleg@gryb.info; oauth@ietf.org >>>>> Sent: Tue, August 3, 2010 10:24:19 AM >>>>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth = 2.0? >>>>> HTTP URIs should not, when participating in the HTTP protocol, = send >>>>> the fragment, as this is not included in HTTP implementation = parsing >>>>> of the URI (according to the specification). >>>>=20 >>>> That's interesting, so if somebody puts a fragment to Location = header, =20 >> which >>>> is a part of HTTP protocol, it will be a violation of the protocol = and can=20 >> be >>>> considered as a server side bug? >>>>=20 >>>> See 14.2 in = http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. >>>>=20 >>>>=20 >>>> Location =3D "Location" ":" absoluteURI >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 >=20 >=20 From oleg_gryb@yahoo.com Tue Aug 3 15:05:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF5E3A68DF for ; Tue, 3 Aug 2010 15:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMcX3X4enJ7R for ; Tue, 3 Aug 2010 15:05:35 -0700 (PDT) Received: from web37602.mail.mud.yahoo.com (web37602.mail.mud.yahoo.com [209.191.87.85]) by core3.amsl.com (Postfix) with SMTP id 307AC3A6407 for ; Tue, 3 Aug 2010 15:05:35 -0700 (PDT) Received: (qmail 49567 invoked by uid 60001); 3 Aug 2010 22:06:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280873161; bh=QlbA+OPIg2s64R81nanuAMIiz4pOrm8iIaFOa311890=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=17ei7Ts4KAAJtz0PR5PuOKHwieIWmIpgKG0xeksCRbgbNkynqCDakNyrH2luSgifcdbqjUQfH7mt0Do/yHJ7oTU3dPs34r0pD5mWqHYFctwRGUfm1XWhhUEBP7RSy0NHHCsXRjubY0NJXScSucIeJZwW4ByaJieN0L9e+98G5lg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=D9NXeQ/wlUVCTLrn0nVwad75xpOeR1rnLgMn+CcLJ5/mI3wy/SqZZJECW+IlyHeR9u70AwAxEWekNOLXysiUzNigGY9goFeFAq+v5cd3547OpXrH6r6RXBD9bpEmvY5jDIZonoSKEi7nOTADOXB6SPr4sv1rXC/G5OpqWvsbfdI=; Message-ID: <146472.48925.qm@web37602.mail.mud.yahoo.com> X-YMail-OSG: dbhtweAVM1nQNvF2HN782ECDnkD6A4O3pxg4VLWoEZTIBh1 BLjYtbN47402JMO8i2q5IyOfNWJ_9jxK_FLY6.HFkf1m6hNXr6D8VOeRkHap fe1fzAla9tPLYXIkmpW8gnJOteql_K2X3PMOP.i38tnzxN10AfAuyzrz3TKI 1RGyCwq1xRso3FBV2VpTTCubq.EX86bMXsLyHHT3MVxz5e7fn2TsBkkgfuPQ YaM4vALczK_wORxTW.25.MTdIqF3rI5rZseKPmIOZClj3t9lrTsLlEZ8ZFYe q.4s7pcCapBhKF5pQgJZiSerw6AN4GMqSI15nUXX_6ckbJzzMKN4FXf8cuxL 89PP1 Received: from [208.240.243.170] by web37602.mail.mud.yahoo.com via HTTP; Tue, 03 Aug 2010 15:06:01 PDT X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950 References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <450348.22430.qm@web37605.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A80F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C00A9C-3F1D-47D7-9FFF-4F235B856847@jkemp.net> <826575.70974.qm@web37603.mail.mud.yahoo.com> <3963E15F-1889-40C5-A0B2-AB044CBA4DC1@jkemp.net> Date: Tue, 3 Aug 2010 15:06:01 -0700 (PDT) From: Oleg Gryb To: John Kemp In-Reply-To: <3963E15F-1889-40C5-A0B2-AB044CBA4DC1@jkemp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 22:05:36 -0000 ----- Original Message ---- > From: John Kemp > And I guess that actually the URI spec itself has been updated since RFC2616 >(see RFC3986) and now has the fragment part included in the generic syntax ;) I don't see it in RFC3986: absolute-URI = scheme ":" hier-part [ "?" query ] Where is the fragment? The answer is: it's still in URI-reference: URI-reference = URI / relative-ref relative-ref = relative-part [ "?" query ] [ "#" fragment ] > Well, things are a bit confusing, certainly, but it seems to me that > a) in 2616bis, fragment in Location seems to be explicitly legal Unlike RFC2616, 2616bis is still a draft, right? > b) in 2616, it is not, but if, for example, an implementation were attempting >to conform to both the newer URI spec (RFC3986) and RFC2616, there might be >confusion, but the fragment might well be parsed anyway, depending on the >implementation I would guess. > > I don't understand why they didn't bump the HTTP version in 2616bis. Apparently, they've changed the definition of very important HTTP header. If existing HTTP clients implement strict syntax validation for the response header, they can easily fail with the new syntax. I think, the right approach would be to declare 2616bis as HTTP 2.0 and state in OAuth 2.0 specification that it works with HTTP 2.0 only (if we really can't get rid of passing access token in a URL's fragment). Otherwise it's very confusing. > >> - johnk > >> > >> On Aug 3, 2010, at 1:39 PM, Eran Hammer-Lahav wrote: > >> > >>> Fragments are perfectly valid in the Location header URI: > >>> > >>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#section-9.4 > >>> > >>> EHL > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > >>>> Of Oleg Gryb > >>>> Sent: Tuesday, August 03, 2010 10:34 AM > >>>> To: John Kemp; Brian Eaton > >>>> Cc: oauth@ietf.org > >>>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> ----- Original Message ---- > >>>>> From: John Kemp > >>>>> To: Brian Eaton > >>>>> Cc: oleg@gryb.info; oauth@ietf.org > >>>>> Sent: Tue, August 3, 2010 10:24:19 AM > >>>>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > >>>>> HTTP URIs should not, when participating in the HTTP protocol, send > >>>>> the fragment, as this is not included in HTTP implementation parsing > >>>>> of the URI (according to the specification). > >>>> > >>>> That's interesting, so if somebody puts a fragment to Location header, > >> which > >>>> is a part of HTTP protocol, it will be a violation of the protocol and >can > > >> be > >>>> considered as a server side bug? > >>>> > >>>> See 14.2 in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html. > >>>> > >>>> > >>>> Location = "Location" ":" absoluteURI > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From tonynad@microsoft.com Tue Aug 3 15:29:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C1B3A6407 for ; Tue, 3 Aug 2010 15:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oosKMKGt0Npm for ; Tue, 3 Aug 2010 15:29:06 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 261E43A6B39 for ; Tue, 3 Aug 2010 15:29:06 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 3 Aug 2010 15:29:34 -0700 Received: from TK5EX14MBXC103.redmond.corp.microsoft.com ([169.254.3.130]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi id 14.01.0180.004; Tue, 3 Aug 2010 15:29:35 -0700 From: Anthony Nadalin To: Brian Campbell Thread-Topic: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft Thread-Index: AQHLJF9rSVp55J5Ts06rNhaRHOhU75LOx+iQgAB+84D//40ukIAB6L4A//+wD7A= Date: Tue, 3 Aug 2010 22:29:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 22:29:08 -0000 This is a use case we are seeing from the various government agencies (UK, = USA, BC), I agree it add complexity but with having to satisfy several clai= ms (i.e. over 21 and being a resident of sate) this seems to be pretty comm= on these days. -----Original Message----- From: Brian Campbell [mailto:bcampbell@pingidentity.com]=20 Sent: Tuesday, August 03, 2010 1:12 PM To: Anthony Nadalin Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 dra= ft Seems like a much more complicated scenario. Allowing more than one assert= ion, off the top of my head, would necessitate some major changes to this p= rofile: * Define how multiple assertions are encoded into the single "assertion" fo= rm control (samlp:Response, concatenated, something else?) * Deal with subject equality across the assertions * Define the processing rules for multiple assertion (from different issuers) and the expected behavior when some but not all are valid. That seems like it would add significant complexity to the existing draft (= that I'm trying to keep simple) for a particular scenario that I'm not sure= is very common. But maybe I'm wrong. Is this something that others anticipate needing? If so, does it belong here? On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin wro= te: > So the scenario we have is where there are multiple tokens from attribute= and identity providers need to be delivered to an OAuth authorization serv= er to satisfy the resource owner's policy of required claims. So this is a = case where a single SAML token/assertion is not enough to satisfy the claim= , we still expect that the signature verification is out of scope. > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Brian Campbell > Sent: Monday, August 02, 2010 2:53 PM > To: oauth > Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth=20 > 2.0 draft > > I guess I'd need to understand the scenario better before I'd have an=20 > opinion one way or the other. =A0 However, I will say that In this=20 > profile I was specifically looking to avoid the complexity that exists in= SAML Web SSO by allowing for multiple assertions and multiple subject conf= irmations. > > On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin w= rote: >> There are many cases where we need to have more than 1 SAML assertion be= used to represent the authorization token, so would want a provision for m= ultiple SAML tokens and not sure it makes sense to have a separate profile = for that or add it as an option here. >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 >> Behalf Of Brian Campbell >> Sent: Thursday, July 15, 2010 1:50 PM >> To: oauth >> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0=20 >> draft >> >> I'm gong to join the growing list of people attaching a potential I-D=20 >> to an email due to he cut off time for the I-D submissions. =A0Attached= =20 >> is a draft that aims to tightly define the particular format of a=20 >> SAML >> 2.0 bearer assertion in requesting an access token using the=20 >> assertion grant_type. =A0 I've been working with Chuck at=20 >> Salesforce.com on this and the primary goal is to have some=20 >> documentation or specification that is sufficient to facilitate=20 >> interoperability between independently developed implementations or prod= ucts. =A0 =A0This, of course, wouldn't preclude using SAML in other ways - = it would only provide one concrete definition to implement against. >> >> I intend to submit this as an I-D when the submission process reopens. >> =A0Any feedback from this group would be appreciated as well as thoughts= about this eventually becoming a working group draft. >> >> Thanks, >> Brian Campbell >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From James.H.Manger@team.telstra.com Tue Aug 3 20:00:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D241D3A6A43 for ; Tue, 3 Aug 2010 20:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.683 X-Spam-Level: X-Spam-Status: No, score=0.683 tagged_above=-999 required=5 tests=[AWL=-0.829, BAYES_40=-0.185, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrCRdVI4ix6b for ; Tue, 3 Aug 2010 20:00:24 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id BCD0B3A68EA for ; Tue, 3 Aug 2010 20:00:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,313,1278252000"; d="scan'208";a="7260373" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 04 Aug 2010 13:00:48 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,6063"; a="5253765" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcavi.tcif.telstra.com.au with ESMTP; 04 Aug 2010 13:00:50 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Wed, 4 Aug 2010 13:00:49 +1000 From: "Manger, James H" To: Torsten Lodderstedt Date: Wed, 4 Aug 2010 13:00:48 +1000 Thread-Topic: [OAUTH-WG] OAuth & Protected feeds Thread-Index: AcszAnec9C6ByrgpTlWZ3biNEqVjtAAfEDTw Message-ID: <255B9BB34FB7D647A506DC292726F6E11268028567@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> <4C58031B.60206@lodderstedt.net> In-Reply-To: <4C58031B.60206@lodderstedt.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 03:00:24 -0000 VG9yc3RlbiwNCg0KPj4gVGhpcyBleGFtcGxlIGlsbHVzdHJhdGVzIHRoYXQgT0F1dGgyIGRpc2Nv dmVyeSBuZWVkcyB0byBsZXQgYSBzZXJ2aWNlDQo+PiBleHBsaWNpdGx5IGluZGljYXRlIHdoZXRo ZXIgYSBkaXJlY3QgYW5kL29yIHVzZXItZGVsZWdhdGlvbiBmbG93IGlzIHJlcXVpcmVkLg0KPj4g Rm9yIGluc3RhbmNlLCBhICJXV1ctQXV0aGVudGljYXRlOiBPQXV0aDIiIHJlc3BvbnNlIGNvdWxk IGRlZmluZSAyIHBhcmFtZXRlcnM6DQo+PiAndXNlci11cmknIGFuZCAndG9rZW4tdXJpJy4gSWYg b25seSBvbmUgaXMgcHJlc2VudCwgb25seSB0aGUgY29ycmVzcG9uZGluZyBtb2RlDQo+PiBpcyB1 c2VmdWwgaW4gdGhpcyBpbnRlcmFjdGlvbi4NCg0KPiBJbiBteSBvcGluaW9uLCB0aGlzIGRlY2lz aW9uIGlzIHVwIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhbmQgbm90IA0KPiB0aGUgcmVz b3VyY2Ugc2VydmVyLiBPciBzaG91bGQgYm90aCBiZSBwb3NzaWJsZT8gV2hhdCBkbyB5b3UgdGhp bms/DQoNClRoZW9yZXRpY2FsbHksIHRoZSBkZWNpc2lvbiBzaG91bGQgcHJvYmFibHkgYmUgdXAg dG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLg0KSW4gcHJhY3Rpc2UsIGhvd2V2ZXIsIHRoZSBk ZWNpc2lvbiBzaG91bGQgYmUgKmRlbGl2ZXJlZCogZnJvbSB0aGUgcmVzb3VyY2Ugc2VydmVyLg0K DQpJdCBpcyByZXNvdXJjZXMgdGhhdCBhcHBzIGFyZSB1bHRpbWF0ZWx5IGludGVyZXN0ZWQgaW4u DQpJdCBpcyBhdCBhIHJlc291cmNlIHdoZXJlIGFuIGFwcCBzaG91bGQgc3RhcnQNCih1bmxlc3Mg aXQgY2FuIHNraXAgc29tZSBzdGVwcyBieSB1c2luZyBzb21lIHNlcnZpY2Utc3BlY2lmaWMga25v d2xlZGdlKS4NCkNvbnNlcXVlbnRseSwgZGVsaXZlcmluZyB0aGUgZGVjaXNpb24gZnJvbSB0aGUg cmVzb3VyY2Ugc2VydmVyIGlzIG1vcmUgZWZmaWNpZW50Lg0KSXQgYXZvaWRzIGFuIGV4dHJhIHN0 ZXAgKHJlc291cmNlIHNlcnZlciAtPiBhdXRoeiBzZXJ2ZXIgLT4gYW5zd2VyKS4NCg0KU2VwYXJh dGluZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZnJvbSByZXNvdXJjZSBzZXJ2ZXJzIGlzIHVz ZWZ1bCBmb3INCnJlc3RyaWN0aW5nIHRoZSBleHBvc3VyZSBvZiBsb25nLXRlcm0gc2VjcmV0cy4g SXQgaXMgbm90IG5lY2Vzc2FyeSwgaG93ZXZlciwNCmZvciB0aGUgZGVsaXZlcnkgb2YgZGlzY292 ZXJ5IGluZm9ybWF0aW9uLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg== From oleg_gryb@yahoo.com Tue Aug 3 20:55:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A19FB3A6A0C for ; Tue, 3 Aug 2010 20:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.194 X-Spam-Level: X-Spam-Status: No, score=-1.194 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79d0DpoUddbH for ; Tue, 3 Aug 2010 20:55:57 -0700 (PDT) Received: from web37603.mail.mud.yahoo.com (web37603.mail.mud.yahoo.com [209.191.87.86]) by core3.amsl.com (Postfix) with SMTP id 720363A696F for ; Tue, 3 Aug 2010 20:55:57 -0700 (PDT) Received: (qmail 90450 invoked by uid 60001); 4 Aug 2010 03:56:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280894183; bh=6O2D6VXW/agAkH4v3QIxH519FfJLJ9t55DhKySZEdp0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=0z/hKlU43GOVWbLqn9WtK/vHzL6smRU0b9kepLnmcprqV3BUSs9pLqO0Jd4TK6pLQE/rUA41Tw2RXWGxHrjtwcg3VNUHPc2hN2VU0MNuHmeEjm+nA/2A/YvLNuYbN6MsZb7Fwdr9x/8JSszUoQHEwFbxiqRM8eSLBWTDZZre0bY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=vaHubnobmNkQSb4sG06WiFktTg6jIVZrWEQog95dFNL76AiXCuWBl85gOH8vXeARbdW3bJwT37tUTW55Qi4pE7K+8Uj8y5FkJ0H9pi+Z6KRFbdQL62ZB1KcqaEcfJQz9DSbout9kg/uWEJ2c6DJ8UJX+zYY1vl+PUxTnHeqIEE4=; Message-ID: <771758.85209.qm@web37603.mail.mud.yahoo.com> X-YMail-OSG: PX2AA8gVM1kNLwsHZlJ0A0jqF4qxl1EEofwLgLTgBPs2Fu5 7uZ_FbhFK9FC3uj69RZ8YSd32xCuJrB610p407IOqOGAolwA4LqTfTMVYfLp PbQV_IPswM.9AQxoWTNnOfVLcvuD2PtkAxkah4nBFd6LLB5rHnzzcmFqaxWa 7F8TXv9VSuh6lixL2C0SfF_7aQxp7I8NAtNvuU_Eznma8pHLJM44PRMiBujD Lq1OwXmCBpiTw0tNf0zzrzp40ZOAADYroEdSIz65.AfTCfxSS3ekg_g97on. AiaX7BDDg.C_bX_QHbTAFg2gilVsb0oTWn3ld8LJeBidU3uGwpvVSiPEGsC7 AXoDAl3RbBzq. Received: from [67.119.192.108] by web37603.mail.mud.yahoo.com via HTTP; Tue, 03 Aug 2010 20:56:23 PDT X-Mailer: YahooMailRC/459 YahooMailWebService/0.8.105.279950 Date: Tue, 3 Aug 2010 20:56:23 -0700 (PDT) From: Oleg Gryb To: Brian Eaton MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 03:55:58 -0000 > From: Brian Eaton > HTTP/1.1 302 Moved Temporarily > Location: http://www.thirdparty.com/rpc_relay.html#access_token=12345 > > rpc_relay.html is highly cached in the browser, so instead of > incurring hundreds of ms to fetch a file, the data lands in the > third-party.com javascript in under a millisecond. I see your point, but let me try to eliminate the call to rpc_relay.html at all. After all, the ultimate goal is not to receive an access token, but a resource protected by that token. If there are mistakes in the suggestion below, please let me know what they are. Let us assume that the response contains this instead of the Location header:
Access token will be sent directly to the service provider. There is no need to call rpc_relay.html. There is no need to call that complicated cross domain communication logic described at FB. There is no need to create cookies. You can do Ajax as well: ... Is there anything wrong with either of these approaches? From lshepard@facebook.com Tue Aug 3 21:34:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1580A3A67FE for ; Tue, 3 Aug 2010 21:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_73=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7I3OT+UUjCH for ; Tue, 3 Aug 2010 21:34:11 -0700 (PDT) Received: from mx-out.facebook.com (outmail014.snc1.tfbnw.net [69.63.178.173]) by core3.amsl.com (Postfix) with ESMTP id 511A43A696F for ; Tue, 3 Aug 2010 21:34:10 -0700 (PDT) Received: from [10.18.255.137] ([10.18.255.137:34540] helo=mail.thefacebook.com) by mta013.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 90/FE-24416-FDDE85C4; Tue, 03 Aug 2010 21:34:39 -0700 Received: from SC-MBX06.TheFacebook.com ([169.254.5.44]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Tue, 3 Aug 2010 21:34:37 -0700 From: Luke Shepard To: Oleg Gryb Thread-Topic: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? Thread-Index: AQHLM4kAoYENziRykUS4BzB9KMheSJLRKwWA Date: Wed, 4 Aug 2010 04:34:49 +0000 Message-ID: <2D41DAFD-E972-49F9-8FA5-FACD2B3CB189@facebook.com> References: <771758.85209.qm@web37603.mail.mud.yahoo.com> In-Reply-To: <771758.85209.qm@web37603.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <02a5f62a-3863-4b68-8131-1d48b1ed8468> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 04:34:13 -0000 Hi Oleg, If you want to send an access token directly to the server, we have the web= server flow designed to do that. The JS redirect or Ajax call is just a mo= re complicated way to send the token to the server. The user-agent flow is = intended for use where the resource needs to be accessed directly from the = client - either in Javascript, or a mobile or desktop application. OAuth 2.0 merely codifies what is already standard industry practice - Face= book, Twitter, Google, OpenSocial, and others rely on this cross domain tec= hnique in order to transfer access tokens within a client-only context. On Aug 3, 2010, at 8:56 PM, Oleg Gryb wrote: >=20 >=20 >=20 >=20 >> From: Brian Eaton >> HTTP/1.1 302 Moved Temporarily >> Location: http://www.thirdparty.com/rpc_relay.html#access_token=3D12345 >=20 >>=20 >> rpc_relay.html is highly cached in the browser, so instead of >> incurring hundreds of ms to fetch a file, the data lands in the >> third-party.com javascript in under a millisecond. >=20 > I see your point, but let me try to eliminate the call to rpc_relay.html = at all.=20 > After all, the ultimate goal is not to receive an access token, but a res= ource=20 > protected by that token. If there are mistakes in the suggestion below, p= lease=20 > let me know what they are. >=20 > Let us assume that the response contains this instead of the Location hea= der: >=20 > > > > > onload=3D"process(document.params.access_token.value,document.params.url.= value)"> >
=20 > > value=3D"http://resourceserver.com/protected_resource.html"/> >
> > >=20 > Access token will be sent directly to the service provider. There is no n= eed to=20 > call rpc_relay.html. There is no need to call that complicated cross doma= in=20 > communication logic described at FB. There is no need to create cookies. >=20 > You can do Ajax as well: >=20 > > > > > ... >=20 > Is there anything wrong with either of these approaches? >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Tue Aug 3 22:02:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E3D03A6BD1 for ; Tue, 3 Aug 2010 22:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.431 X-Spam-Level: X-Spam-Status: No, score=-17.431 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gmc5kHripBZ for ; Tue, 3 Aug 2010 22:02:09 -0700 (PDT) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by core3.amsl.com (Postfix) with ESMTP id 114B03A6BCF for ; Tue, 3 Aug 2010 22:02:08 -0700 (PDT) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o7451cgq058321; Tue, 3 Aug 2010 22:01:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:from:to:cc:date:subject:thread-topic: thread-index:message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; b=WQRMZEzZvyiPch3IJxRnIyMFwDXOhgnW5ipKc60EATgzUB46fL2eU1mZ3rOnv2+A Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Wed, 4 Aug 2010 00:01:38 -0500 From: William Mills To: "Manger, James H" , Torsten Lodderstedt Date: Wed, 4 Aug 2010 00:01:36 -0500 Thread-Topic: [OAUTH-WG] OAuth & Protected feeds Thread-Index: AcszAnec9C6ByrgpTlWZ3biNEqVjtAAfEDTwAAS2DOA= Message-ID: References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> <4C58031B.60206@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11268028567@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11268028567@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 05:02:10 -0000 At the very least we need to minimize the hoops the client needs to jump th= rough. The resource server advertising enpoints allows a simple way to min= imize on one path. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Manger, James H > Sent: Tuesday, August 03, 2010 8:01 PM > To: Torsten Lodderstedt > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth & Protected feeds >=20 > Torsten, >=20 > >> This example illustrates that OAuth2 discovery needs to=20 > let a service=20 > >> explicitly indicate whether a direct and/or=20 > user-delegation flow is required. > >> For instance, a "WWW-Authenticate: OAuth2" response could=20 > define 2 parameters: > >> 'user-uri' and 'token-uri'. If only one is present, only the=20 > >> corresponding mode is useful in this interaction. >=20 > > In my opinion, this decision is up to the authorization=20 > server and not=20 > > the resource server. Or should both be possible? What do you think? >=20 > Theoretically, the decision should probably be up to the=20 > authorization server. > In practise, however, the decision should be *delivered* from=20 > the resource server. >=20 > It is resources that apps are ultimately interested in. > It is at a resource where an app should start (unless it can=20 > skip some steps by using some service-specific knowledge). > Consequently, delivering the decision from the resource=20 > server is more efficient. > It avoids an extra step (resource server -> authz server -> answer). >=20 > Separating the authorization server from resource servers is=20 > useful for restricting the exposure of long-term secrets. It=20 > is not necessary, however, for the delivery of discovery information. >=20 > -- > James Manger >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > = From eran@hueniverse.com Tue Aug 3 22:21:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0D243A6BDD for ; Tue, 3 Aug 2010 22:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Czp9DN9k4qya for ; Tue, 3 Aug 2010 22:21:27 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 566BA3A6BDB for ; Tue, 3 Aug 2010 22:21:26 -0700 (PDT) Received: (qmail 8719 invoked from network); 4 Aug 2010 05:21:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Aug 2010 05:21:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 3 Aug 2010 22:21:54 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , Brian Campbell Date: Tue, 3 Aug 2010 22:21:47 -0700 Thread-Topic: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft Thread-Index: AQHLJF9rSVp55J5Ts06rNhaRHOhU75LOx+iQgAB+84D//40ukIAB6L4A//+wD7CAAHPc8A== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A9D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 05:21:29 -0000 The single assertion use case is well defined. If you need to support multi= ple assertions in a single request, you will need to define a way to group = them together and include them using the single assertion parameter or defi= ne an extension for additional assertions. Either way, this sounds like som= ething that belongs in its own spec. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Anthony Nadalin > Sent: Tuesday, August 03, 2010 3:29 PM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 > draft >=20 > This is a use case we are seeing from the various government agencies (UK= , > USA, BC), I agree it add complexity but with having to satisfy several cl= aims > (i.e. over 21 and being a resident of sate) this seems to be pretty commo= n > these days. >=20 > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Tuesday, August 03, 2010 1:12 PM > To: Anthony Nadalin > Cc: oauth > Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 > draft >=20 > Seems like a much more complicated scenario. Allowing more than one > assertion, off the top of my head, would necessitate some major changes t= o > this profile: >=20 > * Define how multiple assertions are encoded into the single "assertion" > form control (samlp:Response, concatenated, something > else?) > * Deal with subject equality across the assertions > * Define the processing rules for multiple assertion (from different > issuers) and the expected behavior when some but not all are valid. >=20 > That seems like it would add significant complexity to the existing draft= (that > I'm trying to keep simple) for a particular scenario that I'm not sure is= very > common. But maybe I'm wrong. Is this something > that others anticipate needing? If so, does it belong here? >=20 >=20 > On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin > wrote: > > So the scenario we have is where there are multiple tokens from attribu= te > and identity providers need to be delivered to an OAuth authorization ser= ver > to satisfy the resource owner's policy of required claims. So this is a c= ase > where a single SAML token/assertion is not enough to satisfy the claim, w= e > still expect that the signature verification is out of scope. > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Brian Campbell > > Sent: Monday, August 02, 2010 2:53 PM > > To: oauth > > Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth > > 2.0 draft > > > > I guess I'd need to understand the scenario better before I'd have an > > opinion one way or the other. =A0 However, I will say that In this > > profile I was specifically looking to avoid the complexity that exists = in SAML > Web SSO by allowing for multiple assertions and multiple subject > confirmations. > > > > On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin > wrote: > >> There are many cases where we need to have more than 1 SAML > assertion be used to represent the authorization token, so would want a > provision for multiple SAML tokens and not sure it makes sense to have a > separate profile for that or add it as an option here. > >> > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Brian Campbell > >> Sent: Thursday, July 15, 2010 1:50 PM > >> To: oauth > >> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 > >> draft > >> > >> I'm gong to join the growing list of people attaching a potential I-D > >> to an email due to he cut off time for the I-D submissions. =A0Attache= d > >> is a draft that aims to tightly define the particular format of a > >> SAML > >> 2.0 bearer assertion in requesting an access token using the > >> assertion grant_type. =A0 I've been working with Chuck at > >> Salesforce.com on this and the primary goal is to have some > >> documentation or specification that is sufficient to facilitate > >> interoperability between independently developed implementations or > products. =A0 =A0This, of course, wouldn't preclude using SAML in other w= ays - it > would only provide one concrete definition to implement against. > >> > >> I intend to submit this as an I-D when the submission process reopens. > >> =A0Any feedback from this group would be appreciated as well as though= ts > about this eventually becoming a working group draft. > >> > >> Thanks, > >> Brian Campbell > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Aug 3 22:26:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867703A6819 for ; Tue, 3 Aug 2010 22:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuB3loOtbry6 for ; Tue, 3 Aug 2010 22:26:23 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0708E3A67FE for ; Tue, 3 Aug 2010 22:26:23 -0700 (PDT) Received: (qmail 28508 invoked from network); 4 Aug 2010 05:26:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Aug 2010 05:26:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 3 Aug 2010 22:26:50 -0700 From: Eran Hammer-Lahav To: Oleg Gryb , John Kemp Date: Tue, 3 Aug 2010 22:26:44 -0700 Thread-Topic: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? Thread-Index: AcszWBVZ+Dft+6W1TdGfNgjulwTsEwAPPgOw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A9D5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <450348.22430.qm@web37605.mail.mud.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A80F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C00A9C-3F1D-47D7-9FFF-4F235B856847@jkemp.net> <826575.70974.qm@web37603.mail.mud.yahoo.com> <3963E15F-1889-40C5-A0B2-AB044CBA4DC1@jkemp.net> <146472.48925.qm@web37602.mail.mud.yahoo.com> In-Reply-To: <146472.48925.qm@web37602.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 05:26:24 -0000 The HTTPbis WG is tasked with cleaning up the HTTP 1.1 specification and ma= king corrections where needed to reflect how the protocol is actually deplo= yed. Allowing fragments in the Location header is one such adjustment. HTTPbis is considered the authority on HTTP and even though the work is sti= ll a draft, OAuth will align itself with it because that is the best reflec= tion of current IETF thinking. Note that this isn't new. RFC 2616 replaced = 2068 which also defined HTTP 1.1 and made changes as well as dropped featur= es due to lack of deployment experience (e.g Link header, LINK and UNLINK m= ethods). Standards are not the word of god, just the best reflection of how interop = is best accomplished in practice. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Oleg Gryb > Sent: Tuesday, August 03, 2010 3:06 PM > To: John Kemp > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? >=20 >=20 >=20 >=20 >=20 > ----- Original Message ---- >=20 > > From: John Kemp > > And I guess that actually the URI spec itself has been updated since > >RFC2616 (see RFC3986) and now has the fragment part included in the > >generic syntax ;) >=20 > I don't see it in RFC3986: >=20 > absolute-URI =3D scheme ":" hier-part [ "?" query ] >=20 > Where is the fragment? The answer is: it's still in URI-reference: >=20 > URI-reference =3D URI / relative-ref > relative-ref =3D relative-part [ "?" query ] [ "#" fragment ] >=20 > > Well, things are a bit confusing, certainly, but it seems to me that > > a) in 2616bis, fragment in Location seems to be explicitly legal >=20 > Unlike RFC2616, 2616bis is still a draft, right? > > b) in 2616, it is not, but if, for example, an implementation were > >attempting to conform to both the newer URI spec (RFC3986) and > >RFC2616, there might be confusion, but the fragment might well be > >parsed anyway, depending on the implementation I would guess. > > > > >=20 > I don't understand why they didn't bump the HTTP version in 2616bis. > Apparently, they've changed the definition of very important HTTP header= . > If existing HTTP clients implement strict syntax validation for the respo= nse > header, they can easily fail with the new syntax. >=20 >=20 > I think, the right approach would be to declare 2616bis as HTTP 2.0 and s= tate > in OAuth 2.0 specification that it works with HTTP 2.0 only (if we really= can't > get rid of passing access token in a URL's fragment). Otherwise it's very > confusing. >=20 >=20 >=20 >=20 >=20 >=20 > > >> - johnk > > >> > > >> On Aug 3, 2010, at 1:39 PM, Eran Hammer-Lahav wrote: > > >> > > >>> Fragments are perfectly valid in the Location header URI: > > >>> > > >>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-10#sect > > >>> ion-9.4 > > >>> > > >>> EHL > > >>> > > >>>> -----Original Message----- > > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > >>>> Of Oleg Gryb > > >>>> Sent: Tuesday, August 03, 2010 10:34 AM > > >>>> To: John Kemp; Brian Eaton > > >>>> Cc: oauth@ietf.org > > >>>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth > 2.0? > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> ----- Original Message ---- > > >>>>> From: John Kemp > > >>>>> To: Brian Eaton > > >>>>> Cc: oleg@gryb.info; oauth@ietf.org > > >>>>> Sent: Tue, August 3, 2010 10:24:19 AM > > >>>>> Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth > 2.0? > > >>>>> HTTP URIs should not, when participating in the HTTP protocol, > send > > >>>>> the fragment, as this is not included in HTTP implementation > > >>>>> parsing of the URI (according to the specification). > > >>>> > > >>>> That's interesting, so if somebody puts a fragment to Location > > >>>> header, >=20 > > >> which > > >>>> is a part of HTTP protocol, it will be a violation of the > > >>>> protocol and > >can > > > > >> be > > >>>> considered as a server side bug? > > >>>> > > >>>> See 14.2 in http://www.w3.org/Protocols/rfc2616/rfc2616- > sec14.html. > > >>>> > > >>>> > > >>>> Location =3D "Location" ":" absoluteURI > > >>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> OAuth mailing list > > >>>> OAuth@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/oauth > > >> > > >> _______________________________________________ > > >> OAuth mailing list > > >> OAuth@ietf.org > > >> https://www.ietf.org/mailman/listinfo/oauth > > >> > > > > > > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From michael.d.adams@gmail.com Tue Aug 3 22:30:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A389D3A6BD9 for ; Tue, 3 Aug 2010 22:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HvhA5bcEJ-k for ; Tue, 3 Aug 2010 22:30:27 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4CC763A6819 for ; Tue, 3 Aug 2010 22:30:26 -0700 (PDT) Received: by iwn3 with SMTP id 3so1906391iwn.31 for ; Tue, 03 Aug 2010 22:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=ilqj5JwDnxzXNsJBmuV8yfl3eQ51PGuilAcS9UtXRGI=; b=TP9wg2LY6tyDlivtvYuvHrwiILRnhod6yRbCfSoR31ThPzjWQaKhmlYaylDGRPRRw2 Z8sVIuv9BIHuKssWgBhvLt8Jqm1JvsnWHi4/fYkppJlpr0tBz3Z7SOBhJR2BW2Nonlte /wdyDHK+FNthkAt+vVcP2tm+JBuNvhQI4VJmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=dHaexraQPYUTS3aPV30MO+QlySFlU/zoajnF6XjhpptQYYtACoqnDvEJPCBpKd+DMa JAm8yTun3KipZdErinA1zON1Qj9/V85cfbAjdun+Hvo561ivKieO9SH1E29DTViFgAgp tr0KrSvqNViWaaScuCv0VTUMSH6w4a6KYdkXk= Received: by 10.231.182.201 with SMTP id cd9mr10056520ibb.21.1280899854247; Tue, 03 Aug 2010 22:30:54 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Tue, 3 Aug 2010 22:30:34 -0700 (PDT) In-Reply-To: <771758.85209.qm@web37603.mail.mud.yahoo.com> References: <771758.85209.qm@web37603.mail.mud.yahoo.com> From: Michael D Adams Date: Tue, 3 Aug 2010 22:30:34 -0700 X-Google-Sender-Auth: rP9TrFjfQtrSCYP4KUAG_C7fDV0 Message-ID: To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 05:30:28 -0000 On Tue, Aug 3, 2010 at 8:56 PM, Oleg Gryb wrote: > I see your point, but let me try to eliminate the call to rpc_relay.html at all. > After all, the ultimate goal is not to receive an access token, but a resource > protected by that token. The goal is to allow the user to delegate to thirdparty.com her authorization for the protected resources on resourceserver.com. If thirdparty.com never gets the access token, thirdparty.com can never do anything on behalf of the user. Mike From torsten@lodderstedt.net Wed Aug 4 00:02:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB8F3A6801 for ; Wed, 4 Aug 2010 00:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McQxWAlO8siA for ; Wed, 4 Aug 2010 00:02:05 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by core3.amsl.com (Postfix) with ESMTP id 25E543A6A50 for ; Wed, 4 Aug 2010 00:02:04 -0700 (PDT) Received: from [80.187.108.16] (helo=[10.164.37.224]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OgXzc-0005HK-UU; Wed, 04 Aug 2010 09:02:26 +0200 References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> <4C58031B.60206@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11268028567@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11268028567@WSMSG3153V.srv.dir.telstra.com> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 4 Aug 2010 09:01:35 +0200 To: "Manger, James H" X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 07:02:06 -0000 >=20 >> In my opinion, this decision is up to the authorization server and not=20= >> the resource server. Or should both be possible? What do you think? >=20 > Theoretically, the decision should probably be up to the authorization ser= ver. > In practise, however, the decision should be *delivered* from the resource= server. >=20 > It is resources that apps are ultimately interested in. > It is at a resource where an app should start > (unless it can skip some steps by using some service-specific knowledge). > Consequently, delivering the decision from the resource server is more eff= icient. > It avoids an extra step (resource server -> authz server -> answer). >=20 > Separating the authorization server from resource servers is useful for > restricting the exposure of long-term secrets. It is not necessary, howeve= r, > for the delivery of discovery information. >=20 > -- > James=20 So your idea is to use the resource server as discovery Proxy of the authz s= erver? Interesting idea! Would you mind to contribute it to the "Discovery R= equirements" thread? Regards, Torsten.= From torsten@lodderstedt.net Wed Aug 4 00:07:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6499A3A6A53 for ; Wed, 4 Aug 2010 00:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.693 X-Spam-Level: X-Spam-Status: No, score=-0.693 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBlquvgT1waI for ; Wed, 4 Aug 2010 00:07:53 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id 085E43A6820 for ; Wed, 4 Aug 2010 00:07:52 -0700 (PDT) Received: from [80.187.108.16] (helo=[10.164.37.224]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OgY5D-0007ig-O9; Wed, 04 Aug 2010 09:08:13 +0200 References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> <4C58031B.60206@lodderstedt.net> <255B9BB34FB7D647A506DC292726F6E11268028567@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 4 Aug 2010 09:07:25 +0200 To: William Mills X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 07:07:54 -0000 Please see my reply to James's posting and contribute to the Discovery requi= rements thread. One think I want to point out: proxying the authz server may help during the= initial discovery. Once the Client obtained a refresh token, directly disco= vering the tokens endpoint (or a revocation endpoint) is as efficient then a= sking the resource server. But it appears more natural to me. regards, Torsten. Am 04.08.2010 um 07:01 schrieb William Mills : > At the very least we need to minimize the hoops the client needs to jump t= hrough. The resource server advertising enpoints allows a simple way to min= imize on one path. >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 >> On Behalf Of Manger, James H >> Sent: Tuesday, August 03, 2010 8:01 PM >> To: Torsten Lodderstedt >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] OAuth & Protected feeds >>=20 >> Torsten, >>=20 >>>> This example illustrates that OAuth2 discovery needs to=20 >> let a service=20 >>>> explicitly indicate whether a direct and/or=20 >> user-delegation flow is required. >>>> For instance, a "WWW-Authenticate: OAuth2" response could=20 >> define 2 parameters: >>>> 'user-uri' and 'token-uri'. If only one is present, only the=20 >>>> corresponding mode is useful in this interaction. >>=20 >>> In my opinion, this decision is up to the authorization=20 >> server and not=20 >>> the resource server. Or should both be possible? What do you think? >>=20 >> Theoretically, the decision should probably be up to the=20 >> authorization server. >> In practise, however, the decision should be *delivered* from=20 >> the resource server. >>=20 >> It is resources that apps are ultimately interested in. >> It is at a resource where an app should start (unless it can=20 >> skip some steps by using some service-specific knowledge). >> Consequently, delivering the decision from the resource=20 >> server is more efficient. >> It avoids an extra step (resource server -> authz server -> answer). >>=20 >> Separating the authorization server from resource servers is=20 >> useful for restricting the exposure of long-term secrets. It=20 >> is not necessary, however, for the delivery of discovery information. >>=20 >> -- >> James Manger >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 From torsten@lodderstedt.net Wed Aug 4 00:39:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07B103A693D for ; Wed, 4 Aug 2010 00:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.705 X-Spam-Level: X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6XL07nhtREm for ; Wed, 4 Aug 2010 00:39:39 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id 7BFF03A6405 for ; Wed, 4 Aug 2010 00:39:38 -0700 (PDT) Received: from [80.187.108.16] (helo=[10.164.37.224]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OgYa2-000228-9J; Wed, 04 Aug 2010 09:40:06 +0200 References: <4C572883.7020302@lodderstedt.net> In-Reply-To: <4C572883.7020302@lodderstedt.net> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9517276C-A806-4630-84D1-6B3F1F6A7754@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 4 Aug 2010 09:39:09 +0200 To: Torsten Lodderstedt X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 07:39:40 -0000 Would it make sense to support two scenarios? (1) Discovery as described in m= y original posting independent of "functional" requests. (2) Discovery for u= nauthorized requests (WWW-Authenticate header). The later might be a lightweight variant of the first scenario. regards, Torsten. Am 02.08.2010 um 22:20 schrieb Torsten Lodderstedt = : > In the WG meeting at Maastricht, I have been asked to write down my requir= ements regarding Discovery. And here they are: >=20 > Assumptions: Discovery allows a compliant client to automatically obtain a= ll deployment specific data required to securely access a particular resourc= e servers as well as its respective authorization server for the purpose of o= btaining access tokens. >=20 > Starting point of the discovery process is a resource URL. This URL can be= hard-coded into the client, bundled with the applications resources or manu= ally configured by the end-user at runtime. >=20 > 1) Client -> Resource > The client uses the resource URL to obtain resource-specific data, such as= > a) one URI refering to its authorization server > b) a definition of all scopes of the resource > c) additional data, e.g. supported signature methods and algorithms >=20 > I do not make any assumption about how many requests are processed in orde= r to gather this information and whether there will be any levels of indirec= tions (e.g. from resource to resource server). >=20 > 2) Client -> Authz Server > The authz server URI obtained in step 1 is used to gather the following da= ta from the authz server: > a) endpoint URLs (end-user authorization, tokens, ...) > b) information about the server's capabilities, e.g. the supported respons= e (end-user authorization endpoint) and grant types (tokens endpoint) >=20 > The client stores the authz server's discovery URL along with the token(s)= it obtains for further use. >=20 > And that's it from my point of view. I would very much appreciate if we co= uld have a discussion towards a consensus about discovery requirements. >=20 > regards, > Torsten. >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Aug 4 01:55:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 425513A68C7 for ; Wed, 4 Aug 2010 01:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.715 X-Spam-Level: X-Spam-Status: No, score=-0.715 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M1-fZb0MEIr for ; Wed, 4 Aug 2010 01:55:14 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id A78483A695A for ; Wed, 4 Aug 2010 01:55:13 -0700 (PDT) Received: from [80.187.108.16] (helo=[10.164.37.224]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OgZkx-00018A-QM; Wed, 04 Aug 2010 10:55:40 +0200 References: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A9D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A9D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 4 Aug 2010 10:54:34 +0200 To: Eran Hammer-Lahav X-Df-Sender: 141509 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 08:55:15 -0000 +1 Brian's profile serves a distinct purpose. I don't see a problem with differ= ent assertion profiles for using SAML with OAuth, especcially given the wide= usage of SAML. Regards, Torsten. Am 04.08.2010 um 07:21 schrieb Eran Hammer-Lahav : > The single assertion use case is well defined. If you need to support mult= iple assertions in a single request, you will need to define a way to group t= hem together and include them using the single assertion parameter or define= an extension for additional assertions. Either way, this sounds like someth= ing that belongs in its own spec. >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Anthony Nadalin >> Sent: Tuesday, August 03, 2010 3:29 PM >> To: Brian Campbell >> Cc: oauth >> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >> draft >>=20 >> This is a use case we are seeing from the various government agencies (UK= , >> USA, BC), I agree it add complexity but with having to satisfy several cl= aims >> (i.e. over 21 and being a resident of sate) this seems to be pretty commo= n >> these days. >>=20 >> -----Original Message----- >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> Sent: Tuesday, August 03, 2010 1:12 PM >> To: Anthony Nadalin >> Cc: oauth >> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >> draft >>=20 >> Seems like a much more complicated scenario. Allowing more than one >> assertion, off the top of my head, would necessitate some major changes t= o >> this profile: >>=20 >> * Define how multiple assertions are encoded into the single "assertion" >> form control (samlp:Response, concatenated, something >> else?) >> * Deal with subject equality across the assertions >> * Define the processing rules for multiple assertion (from different >> issuers) and the expected behavior when some but not all are valid. >>=20 >> That seems like it would add significant complexity to the existing draft= (that >> I'm trying to keep simple) for a particular scenario that I'm not sure is= very >> common. But maybe I'm wrong. Is this something >> that others anticipate needing? If so, does it belong here? >>=20 >>=20 >> On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin >> wrote: >>> So the scenario we have is where there are multiple tokens from attribut= e >> and identity providers need to be delivered to an OAuth authorization ser= ver >> to satisfy the resource owner's policy of required claims. So this is a c= ase >> where a single SAML token/assertion is not enough to satisfy the claim, w= e >> still expect that the signature verification is out of scope. >>>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Brian Campbell >>> Sent: Monday, August 02, 2010 2:53 PM >>> To: oauth >>> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth >>> 2.0 draft >>>=20 >>> I guess I'd need to understand the scenario better before I'd have an >>> opinion one way or the other. However, I will say that In this >>> profile I was specifically looking to avoid the complexity that exists i= n SAML >> Web SSO by allowing for multiple assertions and multiple subject >> confirmations. >>>=20 >>> On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin >> wrote: >>>> There are many cases where we need to have more than 1 SAML >> assertion be used to represent the authorization token, so would want a >> provision for multiple SAML tokens and not sure it makes sense to have a >> separate profile for that or add it as an option here. >>>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Brian Campbell >>>> Sent: Thursday, July 15, 2010 1:50 PM >>>> To: oauth >>>> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >>>> draft >>>>=20 >>>> I'm gong to join the growing list of people attaching a potential I-D >>>> to an email due to he cut off time for the I-D submissions. Attached >>>> is a draft that aims to tightly define the particular format of a >>>> SAML >>>> 2.0 bearer assertion in requesting an access token using the >>>> assertion grant_type. I've been working with Chuck at >>>> Salesforce.com on this and the primary goal is to have some >>>> documentation or specification that is sufficient to facilitate >>>> interoperability between independently developed implementations or >> products. This, of course, wouldn't preclude using SAML in other ways -= it >> would only provide one concrete definition to implement against. >>>>=20 >>>> I intend to submit this as an I-D when the submission process reopens. >>>> Any feedback from this group would be appreciated as well as thoughts >> about this eventually becoming a working group draft. >>>>=20 >>>> Thanks, >>>> Brian Campbell >>>>=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 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From prateek.mishra@oracle.com Wed Aug 4 08:08:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B263A6855 for ; Wed, 4 Aug 2010 08:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgugcZffYDBN for ; Wed, 4 Aug 2010 08:08:46 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6C42A3A67FA for ; Wed, 4 Aug 2010 08:08:46 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o74F9DBv003644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Aug 2010 15:09:15 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o7431Fg8022722; Wed, 4 Aug 2010 15:09:12 GMT Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 465490871280934543; Wed, 04 Aug 2010 08:09:03 -0700 Received: from [192.168.1.3] (/209.6.179.100) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Aug 2010 08:09:03 -0700 Message-ID: <4C598270.1050304@oracle.com> Date: Wed, 04 Aug 2010 11:08:32 -0400 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brian Campbell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C598299.00C5:SCFMA4539814,ss=1,fgs=0 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:08:48 -0000 Brian, it would probably help to clarify that you are proposing this as a additional or follow-on step to SSO implemented via the SAML web browser profiles (right?). Maybe some text could be added to the draft to make that explicit. This is in contrast to more general token exchange scenarios - here are bunch of SAML /XYZ tokens, now give me an OAuth token for for a certain purpose. I agree with you that the latter would require quite a bit of additional work. Here is my understanding of the current use-case - The user delivers a SAML bearer token (issued at an IdP) via a browser profile to an SP. The SP, performs some business service for the user and at some point requires access to user resources at the IdP or at some third-party site. Switching to OAuth terminology, the Client (SP) exchanges the said SAML bearer token to the Authorization server (could be at the IdP - this would be a common case I think) for an OAuth token. This is the exchange you are describing in your draft. Once the client obtains the OAuth token, it can bind it to a request for the user resource. I have some mild SAMology concerns about this - historically the SAML bearer token has been constrained to have a short life-time and the general advice is not to forward it beyond the SP. I am aware that in practice this isnt the case - often the token is bound to some subsequent flows - somewhat along the lines you are proposing. I will follow up with these concerns on the SAML list. - prateek > Seems like a much more complicated scenario. Allowing more than one > assertion, off the top of my head, would necessitate some major > changes to this profile: > > * Define how multiple assertions are encoded into the single > "assertion" form control (samlp:Response, concatenated, something > else?) > * Deal with subject equality across the assertions > * Define the processing rules for multiple assertion (from different > issuers) and the expected behavior when some but not all are valid. > > That seems like it would add significant complexity to the existing > draft (that I'm trying to keep simple) for a particular scenario that > I'm not sure is very common. But maybe I'm wrong. Is this something > that others anticipate needing? If so, does it belong here? > > > On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin wrote: > >> So the scenario we have is where there are multiple tokens from attribute and identity providers need to be delivered to an OAuth authorization server to satisfy the resource owner's policy of required claims. So this is a case where a single SAML token/assertion is not enough to satisfy the claim, we still expect that the signature verification is out of scope. >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell >> Sent: Monday, August 02, 2010 2:53 PM >> To: oauth >> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft >> >> I guess I'd need to understand the scenario better before I'd have an >> opinion one way or the other. However, I will say that In this >> profile I was specifically looking to avoid the complexity that exists in SAML Web SSO by allowing for multiple assertions and multiple subject confirmations. >> >> On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin wrote: >> >>> There are many cases where we need to have more than 1 SAML assertion be used to represent the authorization token, so would want a provision for multiple SAML tokens and not sure it makes sense to have a separate profile for that or add it as an option here. >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Brian Campbell >>> Sent: Thursday, July 15, 2010 1:50 PM >>> To: oauth >>> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >>> draft >>> >>> I'm gong to join the growing list of people attaching a potential I-D >>> to an email due to he cut off time for the I-D submissions. Attached >>> is a draft that aims to tightly define the particular format of a SAML >>> 2.0 bearer assertion in requesting an access token using the assertion >>> grant_type. I've been working with Chuck at Salesforce.com on this >>> and the primary goal is to have some documentation or specification >>> that is sufficient to facilitate interoperability between >>> independently developed implementations or products. This, of course, wouldn't preclude using SAML in other ways - it would only provide one concrete definition to implement against. >>> >>> I intend to submit this as an I-D when the submission process reopens. >>> Any feedback from this group would be appreciated as well as thoughts about this eventually becoming a working group draft. >>> >>> Thanks, >>> Brian Campbell >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From mscurtescu@google.com Wed Aug 4 08:13:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8323A6B0C for ; Wed, 4 Aug 2010 08:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.843 X-Spam-Level: X-Spam-Status: No, score=-101.843 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJIPfKL+VPSC for ; Wed, 4 Aug 2010 08:13:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 3C41F3A6B9E for ; Wed, 4 Aug 2010 08:13:41 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o74FE9FB031298 for ; Wed, 4 Aug 2010 08:14:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280934850; bh=hWbHlNrHhWHsnpqE+eVAog0nW88=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=n1GR5W2dS6a/rUR2cwfh8kfjAziJoxyTZqJZy7/ps3xILm2j5fg2qgtzxXzTtLB17 69XvL8c+x+Q0Q7F445QOw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=c3vvJIVsKwhktR14uATQ96uB0Jb3Z8kJ9cjvoyzz8YMOlUhfhfjizawxOFdl30Wxw nZSncrwzS8Pvb3rtCD10A== Received: from gyc15 (gyc15.prod.google.com [10.243.49.143]) by wpaz29.hot.corp.google.com with ESMTP id o74FE8Qf022793 for ; Wed, 4 Aug 2010 08:14:08 -0700 Received: by gyc15 with SMTP id 15so2014019gyc.9 for ; Wed, 04 Aug 2010 08:14:08 -0700 (PDT) Received: by 10.101.164.25 with SMTP id r25mr10119931ano.254.1280934848185; Wed, 04 Aug 2010 08:14:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.143.4 with HTTP; Wed, 4 Aug 2010 08:13:48 -0700 (PDT) In-Reply-To: <2D41DAFD-E972-49F9-8FA5-FACD2B3CB189@facebook.com> References: <771758.85209.qm@web37603.mail.mud.yahoo.com> <2D41DAFD-E972-49F9-8FA5-FACD2B3CB189@facebook.com> From: Marius Scurtescu Date: Wed, 4 Aug 2010 08:13:48 -0700 Message-ID: To: Luke Shepard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Oleg Gryb , "" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:13:42 -0000 On Tue, Aug 3, 2010 at 9:34 PM, Luke Shepard wrote: > Hi Oleg, > > If you want to send an access token directly to the server, we have the w= eb server flow designed to do that. The JS redirect or Ajax call is just a = more complicated way to send the token to the server. The user-agent flow i= s intended for use where the resource needs to be accessed directly from th= e client - either in Javascript, or a mobile or desktop application. Nitpick: in most cases the user-agent flow gives the client only a short lived access token, mobile or desktop apps most likely want a long lived refresh token. Marius From paul.madsen@gmail.com Wed Aug 4 08:13:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A3A3A6BD7 for ; Wed, 4 Aug 2010 08:13:46 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImwFh15lYK1Y for ; Wed, 4 Aug 2010 08:13:44 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 55D983A6B61 for ; Wed, 4 Aug 2010 08:13:44 -0700 (PDT) Received: by qwe5 with SMTP id 5so3398022qwe.31 for ; Wed, 04 Aug 2010 08:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=VXA6oXp0U+eOdm1Z2zdKcxwcZOkPNV4PFYosTZco6kg=; b=OgDFWPZsDQCjuGHox1HTmz2+paw1jP4sfZ+5+0UYtihvZJpmyA43LUKQ5fWka13yDR JQEimRorJ4qci29LXjJIUkMCZnPW6DElWkHWfzARdmJWhslAnBbzzc7iuBT1yv1rXvdg FH9ADJlhU3LnNc1ZStSIi00XxUuoX8zO+El00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=un3jVBlXaMAugtaJ8O+769sIwbasuOuApGvtPm/ahl+Z5sJSxfaYckcOI5nLT+wDWw d97bQIuh1Ev+t4GntzQs73MYFW/qVoaR/dbqJY2l4bZ2hbczuOInFc6qzVSGyJUXO56U kk+aUXCct7RjvI43lUF/u1tUjCOppNXJo+A64= Received: by 10.224.28.203 with SMTP id n11mr3921374qac.71.1280934853593; Wed, 04 Aug 2010 08:14:13 -0700 (PDT) Received: from [192.168.0.168] (CPE0022b0cb82b4-CM0012256eb4b4.cpe.net.cable.rogers.com [99.224.152.177]) by mx.google.com with ESMTPS id r29sm3036478qcs.37.2010.08.04.08.14.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 08:14:12 -0700 (PDT) Message-ID: <4C5983C7.6070006@gmail.com> Date: Wed, 04 Aug 2010 11:14:15 -0400 From: Paul Madsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: oauth@ietf.org References: <4C598270.1050304@oracle.com> In-Reply-To: <4C598270.1050304@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:13:47 -0000 Prateek, I believe that here it is the SAML IdP that acts as OAuth Client, not SAML SP - the point of the flow is to get the Assertion (that the IDP would normally send through the browser) over to the SP through an OAuth request/response exchange (in order to get an OAuth token) paul On 04/08/2010 11:08 AM, Prateek Mishra wrote: > Brian, > > it would probably help to clarify that you are proposing this as a > additional or follow-on step to SSO implemented via the SAML web > browser profiles (right?). > > Maybe some text could be added to the draft to make that explicit. > This is in contrast to more general token exchange scenarios - here > are bunch of SAML /XYZ tokens, now give me an OAuth token for for a > certain purpose. I agree with you that the latter would require quite > a bit of additional work. > > Here is my understanding of the current use-case - > > The user delivers a SAML bearer token (issued at an IdP) via a browser > profile to an SP. The SP, performs some business service for the user > and at some point > requires access to user resources at the IdP or at some third-party > site. Switching to OAuth terminology, the Client (SP) exchanges the > said SAML bearer token to the Authorization server (could be at the > IdP - this would be a common case I think) for an OAuth token. This is > the exchange you are describing in your draft. > > Once the client obtains the OAuth token, it can bind it to a request > for the user resource. > > I have some mild SAMology concerns about this - historically the SAML > bearer token has been constrained to have a short life-time and the > general advice is not to forward it beyond the SP. I am aware that in > practice this isnt the case - often the token is bound to some > subsequent flows - somewhat along the lines you are proposing. I will > follow up with these concerns on the SAML list. > > - prateek >> Seems like a much more complicated scenario. Allowing more than one >> assertion, off the top of my head, would necessitate some major >> changes to this profile: >> >> * Define how multiple assertions are encoded into the single >> "assertion" form control (samlp:Response, concatenated, something >> else?) >> * Deal with subject equality across the assertions >> * Define the processing rules for multiple assertion (from different >> issuers) and the expected behavior when some but not all are valid. >> >> That seems like it would add significant complexity to the existing >> draft (that I'm trying to keep simple) for a particular scenario that >> I'm not sure is very common. But maybe I'm wrong. Is this something >> that others anticipate needing? If so, does it belong here? >> >> >> On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin >> wrote: >>> So the scenario we have is where there are multiple tokens from >>> attribute and identity providers need to be delivered to an OAuth >>> authorization server to satisfy the resource owner's policy of >>> required claims. So this is a case where a single SAML >>> token/assertion is not enough to satisfy the claim, we still expect >>> that the signature verification is out of scope. >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>> Behalf Of Brian Campbell >>> Sent: Monday, August 02, 2010 2:53 PM >>> To: oauth >>> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth >>> 2.0 draft >>> >>> I guess I'd need to understand the scenario better before I'd have an >>> opinion one way or the other. However, I will say that In this >>> profile I was specifically looking to avoid the complexity that >>> exists in SAML Web SSO by allowing for multiple assertions and >>> multiple subject confirmations. >>> >>> On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin >>> wrote: >>>> There are many cases where we need to have more than 1 SAML >>>> assertion be used to represent the authorization token, so would >>>> want a provision for multiple SAML tokens and not sure it makes >>>> sense to have a separate profile for that or add it as an option here. >>>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>>> Of Brian Campbell >>>> Sent: Thursday, July 15, 2010 1:50 PM >>>> To: oauth >>>> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >>>> draft >>>> >>>> I'm gong to join the growing list of people attaching a potential I-D >>>> to an email due to he cut off time for the I-D submissions. Attached >>>> is a draft that aims to tightly define the particular format of a SAML >>>> 2.0 bearer assertion in requesting an access token using the assertion >>>> grant_type. I've been working with Chuck at Salesforce.com on this >>>> and the primary goal is to have some documentation or specification >>>> that is sufficient to facilitate interoperability between >>>> independently developed implementations or products. This, of >>>> course, wouldn't preclude using SAML in other ways - it would only >>>> provide one concrete definition to implement against. >>>> >>>> I intend to submit this as an I-D when the submission process reopens. >>>> Any feedback from this group would be appreciated as well as >>>> thoughts about this eventually becoming a working group draft. >>>> >>>> Thanks, >>>> Brian Campbell >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From cmortimore@salesforce.com Wed Aug 4 08:43:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD293A67B2 for ; Wed, 4 Aug 2010 08:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOYXpee86bpm for ; Wed, 4 Aug 2010 08:43:32 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by core3.amsl.com (Postfix) with SMTP id 9E1423A6C00 for ; Wed, 4 Aug 2010 08:43:25 -0700 (PDT) Received: from source ([204.14.239.239]) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKTFmKuefijq1BDNYyf3Vb0cmMwv8IS2En@postini.com; Wed, 04 Aug 2010 08:43:55 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Wed, 4 Aug 2010 08:43:52 -0700 From: Chuck Mortimore To: Prateek Mishra , Brian Campbell Date: Wed, 4 Aug 2010 08:43:52 -0700 Thread-Topic: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft Thread-Index: Acsz5wU7HgaHiKQ+TlSGIMCL+ZFgGwAAxLMB Message-ID: <77AEC44D4DA08A46ADAA723286626BC19D02169549@EXSFM-MB01.internal.salesforce.com> References: , <4C598270.1050304@oracle.com> In-Reply-To: <4C598270.1050304@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:43:33 -0000 Hi Prateek The use-case we were going for here is really more like a classic 2-legged = oauth scenario. A company has an existing SAML web federation establishe= d with a service provider which is providing SSO to it's users. They now= want to perform API based integration with the service provider to perform= some data integration on-behalf of the user, for instance sync their calen= dar. This function needs to execute as that user account, and the company= does not wish to establish or use passwords at the service provider. The= y have 10000 users, and do not wish for each of them to go through a classi= c 3 legged delegation flow; there are too many users to coordinate and 1 si= ngle trust decision by a privileged admin will suffice. So - the company= / service provider decide to reuse their existing SAML configuration for A= PI federation. (note that nothing about the profile dictates you need to h= ave web sso in place, nor reuse the metadata exchange...just and example ) = =20 The company acts as both the IDP and OAuth2 client. Their integration cli= ent obtains the assertion and posts it to the token endpoint. The token e= ndpoint generates an access token for the subject of the SAML assertion and= the integration client can now execute as that user. The assertion is di= scarded. So - this is intended to be very much like web sso and use short lived bear= er assertions that are exchanged for API sessions. Hope that helps clarify. -cmort ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Prateek = Mishra [prateek.mishra@oracle.com] Sent: Wednesday, August 04, 2010 8:08 AM To: Brian Campbell Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 dra= ft Brian, it would probably help to clarify that you are proposing this as a additional or follow-on step to SSO implemented via the SAML web browser profiles (right?). Maybe some text could be added to the draft to make that explicit. This is in contrast to more general token exchange scenarios - here are bunch of SAML /XYZ tokens, now give me an OAuth token for for a certain purpose. I agree with you that the latter would require quite a bit of additional work. Here is my understanding of the current use-case - The user delivers a SAML bearer token (issued at an IdP) via a browser profile to an SP. The SP, performs some business service for the user and at some point requires access to user resources at the IdP or at some third-party site. Switching to OAuth terminology, the Client (SP) exchanges the said SAML bearer token to the Authorization server (could be at the IdP - this would be a common case I think) for an OAuth token. This is the exchange you are describing in your draft. Once the client obtains the OAuth token, it can bind it to a request for the user resource. I have some mild SAMology concerns about this - historically the SAML bearer token has been constrained to have a short life-time and the general advice is not to forward it beyond the SP. I am aware that in practice this isnt the case - often the token is bound to some subsequent flows - somewhat along the lines you are proposing. I will follow up with these concerns on the SAML list. - prateek > Seems like a much more complicated scenario. Allowing more than one > assertion, off the top of my head, would necessitate some major > changes to this profile: > > * Define how multiple assertions are encoded into the single > "assertion" form control (samlp:Response, concatenated, something > else?) > * Deal with subject equality across the assertions > * Define the processing rules for multiple assertion (from different > issuers) and the expected behavior when some but not all are valid. > > That seems like it would add significant complexity to the existing > draft (that I'm trying to keep simple) for a particular scenario that > I'm not sure is very common. But maybe I'm wrong. Is this something > that others anticipate needing? If so, does it belong here? > > > On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin w= rote: > >> So the scenario we have is where there are multiple tokens from attribut= e and identity providers need to be delivered to an OAuth authorization ser= ver to satisfy the resource owner's policy of required claims. So this is a= case where a single SAML token/assertion is not enough to satisfy the clai= m, we still expect that the signature verification is out of scope. >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf O= f Brian Campbell >> Sent: Monday, August 02, 2010 2:53 PM >> To: oauth >> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 = draft >> >> I guess I'd need to understand the scenario better before I'd have an >> opinion one way or the other. However, I will say that In this >> profile I was specifically looking to avoid the complexity that exists i= n SAML Web SSO by allowing for multiple assertions and multiple subject con= firmations. >> >> On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin = wrote: >> >>> There are many cases where we need to have more than 1 SAML assertion b= e used to represent the authorization token, so would want a provision for = multiple SAML tokens and not sure it makes sense to have a separate profile= for that or add it as an option here. >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Brian Campbell >>> Sent: Thursday, July 15, 2010 1:50 PM >>> To: oauth >>> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >>> draft >>> >>> I'm gong to join the growing list of people attaching a potential I-D >>> to an email due to he cut off time for the I-D submissions. Attached >>> is a draft that aims to tightly define the particular format of a SAML >>> 2.0 bearer assertion in requesting an access token using the assertion >>> grant_type. I've been working with Chuck at Salesforce.com on this >>> and the primary goal is to have some documentation or specification >>> that is sufficient to facilitate interoperability between >>> independently developed implementations or products. This, of course= , wouldn't preclude using SAML in other ways - it would only provide one co= ncrete definition to implement against. >>> >>> I intend to submit this as an I-D when the submission process reopens. >>> Any feedback from this group would be appreciated as well as thoughts = about this eventually becoming a working group draft. >>> >>> Thanks, >>> Brian Campbell >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Wed Aug 4 08:45:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606753A6BB2 for ; Wed, 4 Aug 2010 08:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OA-9M1HqeFn2 for ; Wed, 4 Aug 2010 08:45:04 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id D3BEB3A6C08 for ; Wed, 4 Aug 2010 08:44:59 -0700 (PDT) Received: from source ([209.85.215.44]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTFmLFOQRizAQGovYAjpx7jVxLXsBJ7oI@postini.com; Wed, 04 Aug 2010 08:45:29 PDT Received: by mail-ew0-f44.google.com with SMTP id 22so2480250ewy.17 for ; Wed, 04 Aug 2010 08:45:24 -0700 (PDT) Received: by 10.216.164.9 with SMTP id b9mr2233953wel.35.1280936724289; Wed, 04 Aug 2010 08:45:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Wed, 4 Aug 2010 08:44:54 -0700 (PDT) In-Reply-To: <4C598270.1050304@oracle.com> References: <4C598270.1050304@oracle.com> From: Brian Campbell Date: Wed, 4 Aug 2010 09:44:54 -0600 Message-ID: To: Prateek Mishra Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:45:06 -0000 On Wed, Aug 4, 2010 at 9:08 AM, Prateek Mishra wrote: > Brian, > > it would probably help to clarify that you are proposing this as a > additional or follow-on step to SSO implemented via the SAML web browser > profiles (right?). Actually no. The similarities to SSO are mostly in the assertion format and general processing rules. And I did that in hopes of leveraging the thinking that went into that as well as hopefully facilitating some reuse of concepts, patterns and maybe even code/infrastructure. > Maybe some text could be added to the draft to make that explicit. This is > in contrast to more general token exchange scenarios - here > are bunch of SAML /XYZ tokens, now give me an OAuth token for for a certain > purpose. I agree with you that the latter would require quite a bit of > additional work. This is indented to be a general token exchange. Where the inbound token is a SAML token with bearer semantics and the outbound token is an OAuth access token. I'd constrained the inbound token to be a single SAML assertion and I believe Anthony was asking if it would be possible/reasonable to relax that constraint and allow for multiple SAML tokens inbound. I was initially pretty against the idea but I'm thinking maybe it could be accommodated without introducing as much complexity as I first thought. More on that later in a different email. > Here is my understanding of the current use-case - > > The user delivers a SAML bearer token (issued at an IdP) via a browser > profile to an SP. The SP, performs some business service for the user and at > some point > requires access to user resources at the IdP or at some third-party site. > Switching to OAuth terminology, the Client (SP) exchanges the said SAML > bearer token to the Authorization server (could be at the IdP - this would > be a common case I think) for an OAuth token. This is the exchange you are > describing in your draft. That's a very different exchange than what I'm describing. Paul describes this use case well in a follow up email to this thread: "I believe that here it is the SAML IdP that acts as OAuth Client, not SAML SP - the point of the flow is to get the Assertion (that the IDP would normally send through the browser) over to the SP through an OAuth request/response exchange (in order to get an OAuth token)." Exactly *how* that client gets the assertion in the first place is undefined but likely involves some kind of STS style exchange between the client (at the IdP) and whatever SAML infrastructure the IdP has in place. Though, of course, it's not limited to that - I just envision that as a common pattern. For the case you are describing, if the restriction on a single SubjectConfirmation were relaxed, this flow could perhaps be used in the case where the Web SSO assertion is used by the SP to request an access token from a 3rd party (the assertion would need at least two SubjectConfirmations - one targeted for the SP via web SSO and one targted for the authz server at the 3rd party. Relaxing the single SubjectConfirmation constraint was something that Scott suggested on the SAML SSTC list and another item I'm considering - I'll follow up with a separate thread about that as well. In the case of wanting to make some service call back to the IdP after SSO there is some thinking/work being done that would simplify things by embedding the access token or authorization code in the SSO assertion (likely as a specifically named attribute). > I have some mild SAMology concerns about this - historically the SAML bearer > token has been constrained to have a short life-time and the general advice > is not to forward it beyond the SP. I am aware that in practice this isnt > the case - often the token is bound to some subsequent flows - somewhat > along the lines you are proposing. I will follow up with these concerns on > the SAML list. By all means, raise any concerns you have here or with the SSTC or both. But let's make sure we are talking about the same things first :) From oleg_gryb@yahoo.com Wed Aug 4 08:45:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2333A6BF1 for ; Wed, 4 Aug 2010 08:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wv389D1U0YKz for ; Wed, 4 Aug 2010 08:45:19 -0700 (PDT) Received: from web37602.mail.mud.yahoo.com (web37602.mail.mud.yahoo.com [209.191.87.85]) by core3.amsl.com (Postfix) with SMTP id 062553A6BF8 for ; Wed, 4 Aug 2010 08:45:14 -0700 (PDT) Received: (qmail 2835 invoked by uid 60001); 4 Aug 2010 15:45:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280936741; bh=NwcENMGPvRPlEZhNmpB6XSUEprp7IT7NFOF3lQxLK60=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HqOdTre+o19/m2tjUoe3+5pqAdjUfhFIMLO0alNILCOdhz/ByhBdnh2bF+rq1NP4xUS51RicyQ1HBfEDBU0EQt50+BtZ1Wtc571UdKZioMgYHu4yzhB9XaJQUdxDVNVPqMz2ION+ZPCa1L1fmUA+GvyXm/bhL3fd4LVnKemwGBw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tS9dvtJKL38Jhg5xVijyOlanBIjhpH7UuxfiU1TIiezj0wRbys5bTDMao2Z/bcHg4shHBtqTJxYuGUV6wCfZhD0MKfWoRxFcIjgfVopjq/LfZCepO2w6rnudGLPy7tg8SuIajogx4WV/V2y0AmO6oH/RpK4VOa8S28tQtHp9+lM=; Message-ID: <92530.680.qm@web37602.mail.mud.yahoo.com> X-YMail-OSG: uQL3WjQVM1mV0Ux8LFgmMram8laHXgBkjZWes5_OSqS5fkS hEow4OMNvKuNpfGSi.vW29h1gY3Kl.DW_I.wmvV6kwMm_UxJ0auXFmqbyR2v saeP5j4LjayZ8ShjflBsYZGxSUp.lWOrUNgupovydo2Y7BXi3WLseNYdePHm fHj8Y_8d3LIyZnGPrewFktYwdbY4jEiJRQE3VqEDyxzKQUz6MJx2g5ZhgakO w_XbeE3GpnBrF6jDMl9gn.T3wGG3WyHzzzhcDnnxKEdXhBwilgJdmud35Wr0 Pp4V_ZI01LrMDRAG7KanRFYiG9.Lz.ls2iJr4obpdWB0oB9jdMYv3YUlWd83 xpn9z7ty6A7OMXrjaMbdWBA-- Received: from [208.240.243.170] by web37602.mail.mud.yahoo.com via HTTP; Wed, 04 Aug 2010 08:45:40 PDT X-Mailer: YahooMailRC/459 YahooMailWebService/0.8.105.279950 References: <771758.85209.qm@web37603.mail.mud.yahoo.com> Date: Wed, 4 Aug 2010 08:45:40 -0700 (PDT) From: Oleg Gryb To: Michael D Adams In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:45:20 -0000 ----- Original Message ---- > From: Michael D Adams > If> thirdparty.com never gets the access token, thirdparty.com can never > do anything on behalf of the user. > thirdparty.com never gets the access token in the scenario that Brian has described, becuase fragment that was sent by a service provider in Location header is not going to travel to the thirdparty.com server. From bcampbell@pingidentity.com Wed Aug 4 08:48:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B433A688F for ; Wed, 4 Aug 2010 08:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gjrvoZtLO6h for ; Wed, 4 Aug 2010 08:48:38 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id BB76D3A6B7A for ; Wed, 4 Aug 2010 08:48:29 -0700 (PDT) Received: from source ([209.85.215.47]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTFmL6yDkEZzsreI10TLJg2kz74DGgwA3@postini.com; Wed, 04 Aug 2010 08:49:02 PDT Received: by mail-ew0-f47.google.com with SMTP id 7so2171760ewy.20 for ; Wed, 04 Aug 2010 08:48:59 -0700 (PDT) Received: by 10.216.187.143 with SMTP id y15mr7902863wem.74.1280936938191; Wed, 04 Aug 2010 08:48:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Wed, 4 Aug 2010 08:48:28 -0700 (PDT) In-Reply-To: <77AEC44D4DA08A46ADAA723286626BC19D02169549@EXSFM-MB01.internal.salesforce.com> References: <4C598270.1050304@oracle.com> <77AEC44D4DA08A46ADAA723286626BC19D02169549@EXSFM-MB01.internal.salesforce.com> From: Brian Campbell Date: Wed, 4 Aug 2010 09:48:28 -0600 Message-ID: To: Chuck Mortimore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth , Prateek Mishra Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:48:39 -0000 Good explanation, thanks Chuck. On Wed, Aug 4, 2010 at 9:43 AM, Chuck Mortimore wrote: > Hi Prateek > > The use-case we were going for here is really more like a classic 2-legge= d oauth scenario. =A0 =A0A company has an existing SAML web federation esta= blished with a service provider which is providing SSO to it's users. =A0 = =A0They now want to perform API based integration with the service provider= to perform some data integration on-behalf of the user, for instance sync = their calendar. =A0 This function needs to execute as that user account, an= d the company does not wish to establish or use passwords at the service pr= ovider. =A0 They have 10000 users, and do not wish for each of them to go t= hrough a classic 3 legged delegation flow; there are too many users to coor= dinate and 1 single trust decision by a privileged admin will suffice. =A0 = =A0So - the company / service provider decide to reuse their existing SAML = configuration for API federation. =A0(note that nothing about the profile d= ictates you need to have web sso in place, nor reuse the metadata exchange.= ..just and example ) > > The company acts as both the IDP and OAuth2 client. =A0 Their integration= client obtains the assertion and posts it to the token endpoint. =A0 The t= oken endpoint generates an access token for the subject of the SAML asserti= on and the integration client can now execute as that user. =A0 The asserti= on is discarded. > > So - this is intended to be very much like web sso and use short lived be= arer assertions that are exchanged for API sessions. > > Hope that helps clarify. > > -cmort > > > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Pratee= k Mishra [prateek.mishra@oracle.com] > Sent: Wednesday, August 04, 2010 8:08 AM > To: Brian Campbell > Cc: oauth > Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 d= raft > > Brian, > > it would probably help to clarify that you are proposing this as a > additional or follow-on step to SSO implemented via the SAML web browser > profiles (right?). > > Maybe some text could be added to the draft to make that explicit. This > is in contrast to more general token exchange scenarios - here > are bunch of SAML /XYZ tokens, now give me an OAuth token for for a > certain purpose. I agree with you that the latter would require quite a > bit of additional work. > > Here is my understanding of the current use-case - > > The user delivers a SAML bearer token (issued at an IdP) via a browser > profile to an SP. The SP, performs some business service for the user > and at some point > requires access to user resources at the IdP or at some third-party > site. Switching to OAuth terminology, the Client (SP) exchanges the said > SAML bearer token to the Authorization server (could be at the IdP - > this would be a common case I think) for an OAuth token. This is the > exchange you are describing in your draft. > > Once the client obtains the OAuth token, it can bind it to a request for > the user resource. > > I have some mild SAMology concerns about this - historically the SAML > bearer token has been constrained to have a short life-time and the > general advice is not to forward it beyond the SP. I am aware that in > practice this isnt the case - often the token is bound to some > subsequent flows - somewhat along the lines you are proposing. I will > follow up with these concerns on the SAML list. > > - prateek >> Seems like a much more complicated scenario. =A0Allowing more than one >> assertion, off the top of my head, would necessitate some major >> changes to this profile: >> >> * Define how multiple assertions are encoded into the single >> "assertion" form control (samlp:Response, concatenated, something >> else?) >> * Deal with subject equality across the assertions >> * Define the processing rules for multiple assertion (from different >> issuers) and the expected behavior when some but not all are valid. >> >> That seems like it would add significant complexity to the existing >> draft (that I'm trying to keep simple) for a particular scenario that >> I'm not sure is very common. =A0But maybe I'm wrong. =A0Is this somethin= g >> that others anticipate needing? =A0 If so, does it belong here? >> >> >> On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin = wrote: >> >>> So the scenario we have is where there are multiple tokens from attribu= te and identity providers need to be delivered to an OAuth authorization se= rver to satisfy the resource owner's policy of required claims. So this is = a case where a single SAML token/assertion is not enough to satisfy the cla= im, we still expect that the signature verification is out of scope. >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Brian Campbell >>> Sent: Monday, August 02, 2010 2:53 PM >>> To: oauth >>> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0= draft >>> >>> I guess I'd need to understand the scenario better before I'd have an >>> opinion one way or the other. =A0 However, I will say that In this >>> profile I was specifically looking to avoid the complexity that exists = in SAML Web SSO by allowing for multiple assertions and multiple subject co= nfirmations. >>> >>> On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin = wrote: >>> >>>> There are many cases where we need to have more than 1 SAML assertion = be used to represent the authorization token, so would want a provision for= multiple SAML tokens and not sure it makes sense to have a separate profil= e for that or add it as an option here. >>>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>>> Of Brian Campbell >>>> Sent: Thursday, July 15, 2010 1:50 PM >>>> To: oauth >>>> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >>>> draft >>>> >>>> I'm gong to join the growing list of people attaching a potential I-D >>>> to an email due to he cut off time for the I-D submissions. =A0Attache= d >>>> is a draft that aims to tightly define the particular format of a SAML >>>> 2.0 bearer assertion in requesting an access token using the assertion >>>> grant_type. =A0 I've been working with Chuck at Salesforce.com on this >>>> and the primary goal is to have some documentation or specification >>>> that is sufficient to facilitate interoperability between >>>> independently developed implementations or products. =A0 =A0This, of c= ourse, wouldn't preclude using SAML in other ways - it would only provide o= ne concrete definition to implement against. >>>> >>>> I intend to submit this as an I-D when the submission process reopens. >>>> =A0Any feedback from this group would be appreciated as well as though= ts about this eventually becoming a working group draft. >>>> >>>> Thanks, >>>> Brian Campbell >>>> >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From darren@cliqset.com Wed Aug 4 09:01:41 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6B33A6894 for ; Wed, 4 Aug 2010 09:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.476 X-Spam-Level: X-Spam-Status: No, score=-0.476 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WzmHVKfK1Za for ; Wed, 4 Aug 2010 09:01:40 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 60DF43A6885 for ; Wed, 4 Aug 2010 09:01:40 -0700 (PDT) Received: by gxk20 with SMTP id 20so199408gxk.31 for ; Wed, 04 Aug 2010 09:02:09 -0700 (PDT) Received: by 10.100.108.8 with SMTP id g8mr10201569anc.174.1280937729175; Wed, 04 Aug 2010 09:02:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.123.11 with HTTP; Wed, 4 Aug 2010 09:01:49 -0700 (PDT) In-Reply-To: <4C58016C.8070403@lodderstedt.net> References: <255B9BB34FB7D647A506DC292726F6E11267E04D61@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E11267EC8194@WSMSG3153V.srv.dir.telstra.com> <4C58016C.8070403@lodderstedt.net> From: Darren Bounds Date: Wed, 4 Aug 2010 12:01:49 -0400 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=UTF-8 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth & Protected feeds X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 16:01:41 -0000 Absolutely, however, I believe the atomic units that make up the OAuth profile spectrum have not properly taken into account the tidal wave of DiSo interactions that are forth coming. Subsequently you can force them into place and say "they work" but IMO will have a hard time achieving adoption due to the impact they have on the UX. Also, seeing as you have James are having your own discussion on this topic, if you haven't already, you may want to read through this thread which is taking place concurrently. http://groups.google.com/group/federated-social-web/browse_thread/thread/842aa86bce762942 Darren On Tue, Aug 3, 2010 at 7:45 AM, Torsten Lodderstedt wrote: > Darren, >> >> As an OAuth 2 provider and consumer as well as someone who's preparing >> to build the DiSo interactions my proposal was based on, I would >> prefer a single flow that addresses what I feel will be a increasingly >> common set of requirements rather than combining two flows designed >> for two distinct purposes. >> >> > > I would rather put this the other way around. Your particular use case can > be implemented by utilizing the building blocks already built into the > specification. Great! That's what I expect from a _standard_. It provides > people with atomic building blocks, they can create their solutions from. I > don't think we should add every possible flow to the standard. > > Even regarding your proposal, much more is possible. You suggest to use the > web server flow for end-user authorization if the assertion flow failed. Why > not using the user agent or the username/password flow instead? Or any other > way of authenticating and authorizing an end-user? That way, clients can > choose the option matching their requirements and capabilities the most. > > Please also note your proposal has an significant impact on access token > lifecycle. In step 1 you propose to issue a none-authorized access token. > This means an authz server must be able to authorize access tokens after > issuance, which is not required currently. Additionally, resource servers > must be able to recognize none-authorized (invalid) access tokens and refuse > any attempt to access resources with an access token in that state. In my > opinion, this makes the tokens lifecycle much more complex and will not work > in all possible setups, especially if the authorization server issues > self-contained tokens. In such a setup, no direct communication takes place > during request processing on the resource server. > > regards, > Torsten. > > -- darren bounds darren@cliqset.com From beaton@google.com Wed Aug 4 09:03:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F96F3A685B for ; Wed, 4 Aug 2010 09:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.96 X-Spam-Level: X-Spam-Status: No, score=-101.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE1EHmHi96uI for ; Wed, 4 Aug 2010 09:03:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id BC9DD3A683A for ; Wed, 4 Aug 2010 09:03:40 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id o74G48th007361 for ; Wed, 4 Aug 2010 09:04:09 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280937849; bh=zL6AaFKIS0+GfPbBk1CPvjFLwa4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JUiCJI5yy8tqkCqveRoyzRld0dn3MYY8ySb9MwzEjFqgnQ1F6Wbk7nHWtwRh7F0Ib mox9XvI74bQ2SQlACpGXA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=EzUidfkiQhNByv5nEsBVPoXE+iR2b3mPXjYi1zo3rOUkOiLOMuUcbiuMjUbi+0cwg bfEV95j4knVfMRxTtQWlA== Received: from pzk30 (pzk30.prod.google.com [10.243.19.158]) by kpbe13.cbf.corp.google.com with ESMTP id o74G41uJ007948 for ; Wed, 4 Aug 2010 09:04:07 -0700 Received: by pzk30 with SMTP id 30so2224154pzk.29 for ; Wed, 04 Aug 2010 09:04:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.144.2 with SMTP id r2mr8365428wfd.262.1280937845937; Wed, 04 Aug 2010 09:04:05 -0700 (PDT) Received: by 10.143.46.3 with HTTP; Wed, 4 Aug 2010 09:04:05 -0700 (PDT) In-Reply-To: <92530.680.qm@web37602.mail.mud.yahoo.com> References: <771758.85209.qm@web37603.mail.mud.yahoo.com> <92530.680.qm@web37602.mail.mud.yahoo.com> Date: Wed, 4 Aug 2010 09:04:05 -0700 Message-ID: From: Brian Eaton To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 16:03:42 -0000 On Wed, Aug 4, 2010 at 8:45 AM, Oleg Gryb wrote: > thirdparty.com never gets the access token in the scenario that Brian has > described, becuase fragment that was sent by a service provider in Location > header is not going to travel to the thirdparty.com server. This is not quite true. thirdparty.com has a client-side and a server-side component. The thirdparty.com client-side component gets the access token and can use it immediately. The client-side component can then pass it up to the server-side component, if the token is useful there. From wmills@yahoo-inc.com Wed Aug 4 09:05:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3ECD28C0EC for ; Wed, 4 Aug 2010 09:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.514 X-Spam-Level: X-Spam-Status: No, score=-17.514 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EBmrb5567+6 for ; Wed, 4 Aug 2010 09:05:42 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 8C58828C0EB for ; Wed, 4 Aug 2010 09:05:42 -0700 (PDT) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o74G53WQ037822; Wed, 4 Aug 2010 09:05:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:from:to:cc:date:subject:thread-topic: thread-index:message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; b=wwzATIt0UR+ka3FCxg6MiXjL24MP/f2AjZON/9TaLT8n532YreD2Pl4sCX+ppvM+ Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Wed, 4 Aug 2010 09:05:03 -0700 From: William Mills To: Torsten Lodderstedt Date: Wed, 4 Aug 2010 09:05:02 -0700 Thread-Topic: [OAUTH-WG] OAuth Discovery Requirements Thread-Index: AcszqHj9uobISEvkQnmIdZRKXXHWPwARQm7w Message-ID: References: <4C572883.7020302@lodderstedt.net> <9517276C-A806-4630-84D1-6B3F1F6A7754@lodderstedt.net> In-Reply-To: <9517276C-A806-4630-84D1-6B3F1F6A7754@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 16:05:44 -0000 I'm assuming that the WWW-Authenticate style will also be supported (becaus= e I'm going to try to make sure it gets added). I specifically want this f= or SASL discovery. -bill > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=20 > On Behalf Of Torsten Lodderstedt > Sent: Wednesday, August 04, 2010 12:39 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements >=20 > Would it make sense to support two scenarios? (1) Discovery=20 > as described in my original posting independent of=20 > "functional" requests. (2) Discovery for unauthorized=20 > requests (WWW-Authenticate header). >=20 > The later might be a lightweight variant of the first scenario. >=20 > regards, > Torsten. >=20 >=20 >=20 > Am 02.08.2010 um 22:20 schrieb Torsten Lodderstedt=20 > : >=20 > > In the WG meeting at Maastricht, I have been asked to write=20 > down my requirements regarding Discovery. And here they are: > >=20 > > Assumptions: Discovery allows a compliant client to=20 > automatically obtain all deployment specific data required to=20 > securely access a particular resource servers as well as its=20 > respective authorization server for the purpose of obtaining=20 > access tokens. > >=20 > > Starting point of the discovery process is a resource URL.=20 > This URL can be hard-coded into the client, bundled with the=20 > applications resources or manually configured by the end-user=20 > at runtime. > >=20 > > 1) Client -> Resource > > The client uses the resource URL to obtain resource-specific data,=20 > > such as > > a) one URI refering to its authorization server > > b) a definition of all scopes of the resource > > c) additional data, e.g. supported signature methods and algorithms > >=20 > > I do not make any assumption about how many requests are=20 > processed in order to gather this information and whether=20 > there will be any levels of indirections (e.g. from resource=20 > to resource server). > >=20 > > 2) Client -> Authz Server > > The authz server URI obtained in step 1 is used to gather=20 > the following data from the authz server: > > a) endpoint URLs (end-user authorization, tokens, ...) > > b) information about the server's capabilities, e.g. the supported=20 > > response (end-user authorization endpoint) and grant types (tokens=20 > > endpoint) > >=20 > > The client stores the authz server's discovery URL along=20 > with the token(s) it obtains for further use. > >=20 > > And that's it from my point of view. I would very much=20 > appreciate if we could have a discussion towards a consensus=20 > about discovery requirements. > >=20 > > regards, > > Torsten. > >=20 > >=20 > >=20 > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > = From oleg_gryb@yahoo.com Wed Aug 4 09:26:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC01428C0DF for ; Wed, 4 Aug 2010 09:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d-evBM1LSwG for ; Wed, 4 Aug 2010 09:26:43 -0700 (PDT) Received: from web37605.mail.mud.yahoo.com (web37605.mail.mud.yahoo.com [209.191.87.88]) by core3.amsl.com (Postfix) with SMTP id 897373A6966 for ; Wed, 4 Aug 2010 09:26:43 -0700 (PDT) Received: (qmail 38283 invoked by uid 60001); 4 Aug 2010 16:27:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280939229; bh=17Jb2KtHWx20/uOGmRJGDwDEBvhDeAx7/LqUF0nmiHk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WueG/9fKWohNT7T5S6F12NDGL5NSMj9t5i7W0EoH2KRndh1cWzOttzDc8l66cPOrvShF+hQpy3OWCKyjjM7fsjFJSELotlgIVENvTy+jebBhdxUg8O1OvmsqxUoflQL2Ysl5XScwK2tiZ05OGZNzy6i+vb1GXoSPvos2CbrYU24= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gMP9YkhHXWlTqjKvNwdz4UlXtHKSkxd02yYshvoVAJEenmKRajOuaZSsXaEObY5eZLSGr9K3TBWcJXvydLLUNV1EFeDA0/28wYX+WhAnJUzWZKcIqmbEBxjwkmOQ4bv0KUxmOtmdhbBBvvgtcL7Vo+3K/OR02+Opki8CQyiv3es=; Message-ID: <818837.35640.qm@web37605.mail.mud.yahoo.com> X-YMail-OSG: UK1ki_IVM1lO6ma5eBoTEevLW1ciZvDApeS8DkYNQ0h5YxD 12MkQpWr1wERwRPrv4cBgCdrmj._mHlbua6bxBPM7goY8sGzECVoDJ2KVsQ7 p.ErIzHJU15YDI2nDZXpVTWmbbWJJkQnigCkmCKbaDBPjRDVc0m2yWv2sxsm QqcKm57VflDYTw_776oGRUzufVmTJHNBLSq_1OXvDIZOsTbp5iNj3hVyO34r S7eXRPSRAm3PaFwDUDehgiixnKjSMcPxsP.Y6LFoHYskCAdXMd.Bf3r9Xw28 6nN.dIywT6dlWKJn1P0GqS3MU7zqt2oezYW.8lM0kUhNHsd9ODD02PyAjQGx qyR1O5t.NG5c2 Received: from [208.240.243.170] by web37605.mail.mud.yahoo.com via HTTP; Wed, 04 Aug 2010 09:27:09 PDT X-Mailer: YahooMailRC/459 YahooMailWebService/0.8.105.279950 References: <771758.85209.qm@web37603.mail.mud.yahoo.com> <2D41DAFD-E972-49F9-8FA5-FACD2B3CB189@facebook.com> Date: Wed, 4 Aug 2010 09:27:09 -0700 (PDT) From: Oleg Gryb To: Luke Shepard In-Reply-To: <2D41DAFD-E972-49F9-8FA5-FACD2B3CB189@facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 16:26:45 -0000 ----- Original Message ---- > From: Luke Shepard > If you want to send an access token directly to the server, we have the web >server flow designed to do that. The JS redirect or Ajax call is just a more >complicated way to send the token to the server. The user-agent flow is >intended for use where the resource needs to be accessed directly from the >client - either in Javascript, or a mobile or desktop application. > We're not discussing web server profile here and my objective is not to send an "access token directly to the server", but to eliminate secrets in URL. > OAuth 2.0 merely codifies what is already standard industry practice - >Facebook, Twitter, Google, OpenSocial, and others rely on this cross domain >technique in order to transfer access tokens within a client-only context. > I would not mix the existing implementation and the standard. Standard could and should be more generic. The wording around UA flow is generic enough, but it has one implementation specific feature - sending access token in a URL's fragment. I don't understand why it should be there. I think nobody will argue, if I say that there are other ways of transferring access tokens between parties involved. I've even provided one example where URL's fragment is not used. I didn't hear yet why it wouldn't work. I might have missed some important steps in that example, but I think, if mistakes or omissions do exist, they can be easily fixed by adding extra steps and probably even extra round trips to a third party server (sorry, Brian). Here is my final proposal in regards of UA profile. Let me try to re-write steps C to E in a way that will not break the existing implementations, but at the same time will leave some room for other implementations: (C) If the end-user granted access, the authorization server will issue an access token and pass it to the user agent. (D) The user-agent will use the access token granted by the authorization server to get access to a protected resource on the resource server. > On Aug 3, 2010, at 8:56 PM, Oleg Gryb wrote: > > > > > > > > > > >> From: Brian Eaton > >> HTTP/1.1 302 Moved Temporarily > >> Location: http://www.thirdparty.com/rpc_relay.html#access_token=12345 > > > >> > >> rpc_relay.html is highly cached in the browser, so instead of > >> incurring hundreds of ms to fetch a file, the data lands in the > >> third-party.com javascript in under a millisecond. > > > > I see your point, but let me try to eliminate the call to rpc_relay.html at >all. > > > After all, the ultimate goal is not to receive an access token, but a >resource > > > protected by that token. If there are mistakes in the suggestion below, >please > > > let me know what they are. > > > > Let us assume that the response contains this instead of the Location >header: > > > > > > > > > > > > > >onload="process(document.params.access_token.value,document.params.url.value)"> > >
> > > > > value="http://resourceserver.com/protected_resource.html"/> > >
> > > > > > > > Access token will be sent directly to the service provider. There is no need >to > > > call rpc_relay.html. There is no need to call that complicated cross domain > > communication logic described at FB. There is no need to create cookies. > > > > You can do Ajax as well: > > > > > > > > > > > > ... > > > > Is there anything wrong with either of these approaches? > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From oleg_gryb@yahoo.com Wed Aug 4 09:41:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ECE13A6948 for ; Wed, 4 Aug 2010 09:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYPeDQjWFzQS for ; Wed, 4 Aug 2010 09:41:51 -0700 (PDT) Received: from web37604.mail.mud.yahoo.com (web37604.mail.mud.yahoo.com [209.191.87.87]) by core3.amsl.com (Postfix) with SMTP id A2DEB3A68FD for ; Wed, 4 Aug 2010 09:41:51 -0700 (PDT) Received: (qmail 38908 invoked by uid 60001); 4 Aug 2010 16:42:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280940138; bh=ByBUh7o+R9yemDC7CPhENfDKGhBbhRDfagh17pRoBao=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KgqNe4Qdq/f5gT8zMqNBIWquKQsHo36Dlve/Nqb6B65FWJ3bKWSnRGQENmonPVJk1SiMDUZmG9sX1M+Q+RW/XzcJcI/SZIkspSQYJ+9TQzoPT2Bkb5b+2gSCDfRRH1Ft2YqUbE5Bkma2C3KyuxGm9Dr3YgZCGicrzUDqBt37x2s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Fn0WoRjThxvHSVfFms2dlNlrT5H7GCnVM7ewUJKArVZCaZEmaRxhth459AZ75SrrvDr1VqMATML+UHerJwe92+ZAUXMO0bH6aN+C0Z35Pu+SGw8Wh99w0mC7wraq4+ZbCBFlzvyWDvLqgYWrAjGzOWHKjbwXRcDDT/4wtLqSET8=; Message-ID: <284036.38140.qm@web37604.mail.mud.yahoo.com> X-YMail-OSG: pofUk7QVM1l4jl1okH5RNt7QtdyD8Ikv0tS2f87_nVDFd0B BWfuPvNsTVw1icIHhgMat4E16.cnDKJp3hK2BxmCjtqxD9xYh5ZS0k68U5th 2gVBHUl2H7ZpxjN9HmWlYtgGrCyqQ77zlXNDxgz4cM5AlDIZUXDJxBzl8h4B GGywBHqWZNRn6ENd9LjgCVXvSSq0NG2E7RDPZWOOgwVmtMos1R1xn01hlm9M S2UMf.qcPjhWa0Q8rHEOcgxHK64dvL6MUNu0POW6knk3VnZsFxeiFIaLwQrJ xZ2MggHqwDq_KOG_HqYH_aBI9bH_ZkbuG11KbzaxdnTHpku.4hgnLrSHUBg7 .ZeCSKPlbQcpN_9OfLEYs Received: from [208.240.243.170] by web37604.mail.mud.yahoo.com via HTTP; Wed, 04 Aug 2010 09:42:18 PDT X-Mailer: YahooMailRC/459 YahooMailWebService/0.8.105.279950 References: <771758.85209.qm@web37603.mail.mud.yahoo.com> <92530.680.qm@web37602.mail.mud.yahoo.com> Date: Wed, 4 Aug 2010 09:42:18 -0700 (PDT) From: Oleg Gryb To: Brian Eaton In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 16:41:53 -0000 > From: Brian Eaton > To: Oleg Gryb > Cc: Michael D Adams ; oauth@ietf.org > Sent: Wed, August 4, 2010 9:04:05 AM > Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? > > On Wed, Aug 4, 2010 at 8:45 AM, Oleg Gryb wrote: > > thirdparty.com never gets the access token in the scenario that Brian has > > described, becuase fragment that was sent by a service provider in Location > > header is not going to travel to the thirdparty.com server. > > This is not quite true. > > thirdparty.com has a client-side and a server-side component. The > thirdparty.com client-side component gets the access token and can use > it immediately. > > The client-side component can then pass it up to the server-side > component, if the token is useful there. I don't see the secret sharing logic (with thirdparty.com server) in your example or even in UA flow spec. Everything looks like immediate redirects so far. Would you need to make an extra trip to the server for that? Please provide an example, then I'll try to change my example as well (to add secret sharing logic). From michael.d.adams@gmail.com Wed Aug 4 09:46:36 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BAB83A6898 for ; Wed, 4 Aug 2010 09:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7snrn3xiCHFp for ; Wed, 4 Aug 2010 09:46:35 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 2C8D73A696C for ; Wed, 4 Aug 2010 09:46:35 -0700 (PDT) Received: by pvd12 with SMTP id 12so2366902pvd.31 for ; Wed, 04 Aug 2010 09:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=Muzdk/nvsJrfg85M8OuQ3Ac0ytuPn1VPJ7kmIkZh4vo=; b=WbfvBu8W4nXelwTaPcPzkx2WRkURAF81KjXEUBq3TCTedysM0PvM2NwOLE7Tig/+aE oDNsteh99gkFS9dcDh2N1eRU0qomYCiZqkF4GKusIvjC/Ih2VtSgG77Qi0KyQJtIJNQm l3Yx1ywOUuu33T9BRuwezFHsurDSMRn+r4qJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=RW83jOJ7lWy1buVzLrvWWxdZnamxhxrPPcxF4VXpYHJ8d11az1+4TlzjgwiwJ13+Mv VSmPZ/+jXeNjSGHIa6KtWRkXvBQLX6wx6peiUmKM7zRae6aYzCc7mcbSyDpR2cUAyWLW j3YTOUTDChSPzqzrWS6aCPHCkHBmBY31Y1iiM= Received: by 10.143.45.14 with SMTP id x14mr7922435wfj.42.1280940424618; Wed, 04 Aug 2010 09:47:04 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Wed, 4 Aug 2010 09:46:44 -0700 (PDT) In-Reply-To: <92530.680.qm@web37602.mail.mud.yahoo.com> References: <771758.85209.qm@web37603.mail.mud.yahoo.com> <92530.680.qm@web37602.mail.mud.yahoo.com> From: Michael D Adams Date: Wed, 4 Aug 2010 09:46:44 -0700 X-Google-Sender-Auth: dGKId9PCieGL0pEwX4zmIP30e4o Message-ID: To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 16:46:36 -0000 On Wed, Aug 4, 2010 at 8:45 AM, Oleg Gryb wrote: > ----- Original Message ---- >> From: Michael D Adams >> If> thirdparty.com never gets the access token, thirdparty.com can never >> do =A0anything on behalf of the user. >> > thirdparty.com never gets the access token in the scenario that Brian has > described, becuase fragment that was sent by a service provider in Locati= on > header is not going to travel to the thirdparty.com server. As Brian mentioned, the client-side component hosted on thirdparty.com does get the access token in the User Agent flow. That means the client-side script can access multiple protected resources (upload a photo, update the user's profile, flag the user as "online", download a friends list, whatever) in the same page load. If I'm interpreting your idea correctly, only one protected resource can be accessed per access token since the thirdparty.com app never sees the token. For every resource it needs, thirdparty.com has to send the user through the authorization server again. Am I mistaken? From torsten@lodderstedt.net Wed Aug 4 10:01:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDEE23A69B3 for ; Wed, 4 Aug 2010 10:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=0.828, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShWMGrk9zSGX for ; Wed, 4 Aug 2010 10:01:30 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id 9DF9A3A69FC for ; Wed, 4 Aug 2010 10:01:29 -0700 (PDT) Received: from tmo-108-232.customers.d1-online.com ([80.187.108.232] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OghLn-0006ap-PN; Wed, 04 Aug 2010 19:01:57 +0200 Message-ID: <4C599CF7.9030107@lodderstedt.net> Date: Wed, 04 Aug 2010 19:01:43 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: William Mills References: <4C572883.7020302@lodderstedt.net> <9517276C-A806-4630-84D1-6B3F1F6A7754@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 17:01:31 -0000 I'm not familiar with SASL. So out of curiosity: What is the relation between HTTP WWW-Authenticate headers and SASL? regards, Torsten. Am 04.08.2010 18:05, schrieb William Mills: > I'm assuming that the WWW-Authenticate style will also be supported (because I'm going to try to make sure it gets added). I specifically want this for SASL discovery. > > -bill > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] >> On Behalf Of Torsten Lodderstedt >> Sent: Wednesday, August 04, 2010 12:39 AM >> To: Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] OAuth Discovery Requirements >> >> Would it make sense to support two scenarios? (1) Discovery >> as described in my original posting independent of >> "functional" requests. (2) Discovery for unauthorized >> requests (WWW-Authenticate header). >> >> The later might be a lightweight variant of the first scenario. >> >> regards, >> Torsten. >> >> >> >> Am 02.08.2010 um 22:20 schrieb Torsten Lodderstedt >> : >> >> >>> In the WG meeting at Maastricht, I have been asked to write >>> >> down my requirements regarding Discovery. And here they are: >> >>> Assumptions: Discovery allows a compliant client to >>> >> automatically obtain all deployment specific data required to >> securely access a particular resource servers as well as its >> respective authorization server for the purpose of obtaining >> access tokens. >> >>> Starting point of the discovery process is a resource URL. >>> >> This URL can be hard-coded into the client, bundled with the >> applications resources or manually configured by the end-user >> at runtime. >> >>> 1) Client -> Resource >>> The client uses the resource URL to obtain resource-specific data, >>> such as >>> a) one URI refering to its authorization server >>> b) a definition of all scopes of the resource >>> c) additional data, e.g. supported signature methods and algorithms >>> >>> I do not make any assumption about how many requests are >>> >> processed in order to gather this information and whether >> there will be any levels of indirections (e.g. from resource >> to resource server). >> >>> 2) Client -> Authz Server >>> The authz server URI obtained in step 1 is used to gather >>> >> the following data from the authz server: >> >>> a) endpoint URLs (end-user authorization, tokens, ...) >>> b) information about the server's capabilities, e.g. the supported >>> response (end-user authorization endpoint) and grant types (tokens >>> endpoint) >>> >>> The client stores the authz server's discovery URL along >>> >> with the token(s) it obtains for further use. >> >>> And that's it from my point of view. I would very much >>> >> appreciate if we could have a discussion towards a consensus >> about discovery requirements. >> >>> regards, >>> Torsten. >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> From torsten@lodderstedt.net Wed Aug 4 10:04:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FB363A6A70 for ; Wed, 4 Aug 2010 10:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0Sez9FDw1F8 for ; Wed, 4 Aug 2010 10:04:47 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by core3.amsl.com (Postfix) with ESMTP id 911A93A68B8 for ; Wed, 4 Aug 2010 10:04:46 -0700 (PDT) Received: from tmo-108-232.customers.d1-online.com ([80.187.108.232] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OghOx-00066h-FV; Wed, 04 Aug 2010 19:05:14 +0200 Message-ID: <4C599DBA.5070407@lodderstedt.net> Date: Wed, 04 Aug 2010 19:04:58 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A764@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A764@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 17:04:48 -0000 > >> ideas. I still hope to get the discovery spec finished in the same timeframe, >> but have no plans to author or edit any other draft. >> >> Just to get this clear. Do you plan to author the discovery spec? And what is >> the core spec's timeframe? >> > I have started to write the discovery spec, but work on the core spec has taken most of my free time to do this (OAuth is not part of my day job). > The same holds for me :-) Would you mind to share your thoughts regarding discovery with the group. I especially would like to know, whether you agree with the requirements I described in "OAuth Discovery Requirements" and how they can be met. > I have no idea what's the timeframe for the core spec. This groups isn't very good at providing timely feedback and staying focused. Good point. What might be the reasons for the missing focus? In my opinion, there are a couple of. First of all, what is the "thing" we shall be focusing on? That's not clear to me (probably also to others). I therefore asked for your plans to include several aspects in the core spec. Moreover, it's also not clear to me what complementary specs and sub-sequent versions of the core spec the WG will produce in the future. As an effect, everyone is afraid that his/her own ideas are not being considered and focuses on advocating them. If we find a WG consensus on the core spec or "first stage" and also the additional WG items, work will probably become more focused. My impression after attending IETF 78 is, bringing the core spec through the IETF approval process will be hard enough! Additionally, I think the WG lacks consensus on what OAuth 2.0 should be, especially regarding fundamental architectural questions and there consequences! Just to list a few: - supported use cases and client types (there is more than web clients :-)) - number of resource servers an authorization can handle (1:1 vs. 1:n) (resource server specific tokens + resource server addressing) - supported token types (self-contained vs. artifacts vs. session ids) - usage of scopes (resources vs. resource server vs. permissions vs. duration vs. ...) - role of signatures (none, authentication, prove of posession, message integrity, ...) + key management approaches - security level (none, relaxed, state-of-the-art, paranoid), probably there is a need for different OAuth security profiles This not only results in a spec difficult to understand for an "outsider". It also causes endless discussions around those or derived topics. > So far no one has offered to work on the security consideration section (Brian's draft is too far from the format I need to incorporate). > I could work on this topic, if Brian does not insist to do so. @Brian: What do you think? From my point of view, the security considerations could be worked out on a per flow/profile base by multiple contributers (anyone interested?). At least we should agree on a common set of threat agents and a template. > I am planning the next draft for early September which will include the few changes raised on the list, but will focus on finding a middle ground between detailed profiles and a generic architecture (editorial work). > Good luck! regards, Torsten. > EHL > > >>>> What about the following topics? >>>> - security considerations >>>> >>> That's part of core and someone has to write it. I'd like to see someone >>> >> take the security section from RFC 5849 and rework it to match 2.0, as well as >> add everything that is missing. I will incorporate it and take care of the >> editorial work but I am not writing it from scratch. >> >>> >>>> - token revocation (requested by several attendees during Maastricht >>>> WG meeting) >>>> >>> Someone needs to write a proposal and work to get WG consensus (to the >>> >> point where enough people say they like it and no one is objecting). Get it >> there, I'll do the rest. Feel free to ask the chairs to help out. >> >>> >>>> - signatures >>>> >>> I think Nat offered to take a stab at a first draft based on Dirk's work and >>> >> the WG discussions. I have offered to help with editorial work if requested. >> >>> EHL >>> >>> >>>> regards, >>>> Torsten. >>>> >>>> >>>> Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav >>>> : >>>> General discussions on the list and during the interim meeting. >>>> >>>> EHL >>>> >>>> >>>> -----Original Message----- >>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>>> Sent: Monday, August 02, 2010 1:20 PM >>>> To: Eran Hammer-Lahav >>>> Cc: OAuth WG (oauth@ietf.org) >>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>>> >>>> What consensus do you refer to? The WG charter? >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: >>>> No according to WG consensus. We took it all out because too many >>>> people considered it experimental, so while it may be a WG item, it >>>> is not part of the core spes. >>>> >>>> EHL >>>> >>>> >>>> -----Original Message----- >>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>>> Sent: Monday, August 02, 2010 1:07 PM >>>> To: Eran Hammer-Lahav >>>> Cc: OAuth WG (oauth@ietf.org) >>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>>> >>>> and discovery does not belong into the core? >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: >>>> >>>> This doesn't belong in core. A registry is used to avoid name >>>> collisions, not >>>> >>>> to provide an inventory. >>>> >>>> Maybe in discovery. >>>> >>>> EHL >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Torsten Lodderstedt >>>> Sent: Monday, August 02, 2010 12:54 PM >>>> To: OAuth WG (oauth@ietf.org) >>>> Subject: [OAUTH-WG] Extensibility: new endpoints >>>> >>>> the existing authorization server endpoints (end-user authorization >>>> and tokens endpoint) have a relatively clearly semantics and scope. >>>> Adding distinct new functions to an authorization server will (in my >>>> opionion) require the definition of new endpoints. For example, I'm >>>> working on an I-D for token revocation. Such a function does not fit >>>> into the tokens endpoint since it has become a "token issuance >>>> endpoint" rather than a general purpose client2server endpoint. >>>> >>>> I therefore would propose to include the option to define and >>>> register new endpoints into the Extensibility section of the spec. >>>> This would also facilitate the incorporation of additional endpoints >>>> (with well- defined names) into OAuth discovery. >>>> >>>> Any thoughts? >>>> >>>> regards, >>>> Torsten. >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>> From wmills@yahoo-inc.com Wed Aug 4 10:10:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2463728C0F0 for ; Wed, 4 Aug 2010 10:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.542 X-Spam-Level: X-Spam-Status: No, score=-17.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um6KtHLmdyQh for ; Wed, 4 Aug 2010 10:10:19 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id D01E228C0D8 for ; Wed, 4 Aug 2010 10:10:18 -0700 (PDT) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout2.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o74H9o6N002740; Wed, 4 Aug 2010 10:09:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=received:from:to:cc:date:subject:thread-topic: thread-index:message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; b=YivTFF3djuVsTOYMwT4eoTjXB7kKqlpfdwcdGLvbkSGUOafB0JdyPx48122p0W3D Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Wed, 4 Aug 2010 12:09:50 -0500 From: William Mills To: Torsten Lodderstedt Date: Wed, 4 Aug 2010 12:09:49 -0500 Thread-Topic: [OAUTH-WG] OAuth Discovery Requirements Thread-Index: Acsz9tMK9mZXgig/Q3WCC8LCoS+vggAAPBXg Message-ID: References: <4C572883.7020302@lodderstedt.net> <9517276C-A806-4630-84D1-6B3F1F6A7754@lodderstedt.net> <4C599CF7.9030107@lodderstedt.net> In-Reply-To: <4C599CF7.9030107@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 17:10:23 -0000 Only in my head. But I do want to use a consistent definition for discover= y within SASL. =20 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 > Sent: Wednesday, August 04, 2010 10:02 AM > To: William Mills > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements >=20 > I'm not familiar with SASL. So out of curiosity: What is the=20 > relation between HTTP WWW-Authenticate headers and SASL? >=20 > regards, > Torsten. >=20 > Am 04.08.2010 18:05, schrieb William Mills: > > I'm assuming that the WWW-Authenticate style will also be=20 > supported (because I'm going to try to make sure it gets=20 > added). I specifically want this for SASL discovery. > > > > -bill > > > > =20 > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > >> Behalf Of Torsten Lodderstedt > >> Sent: Wednesday, August 04, 2010 12:39 AM > >> To: Torsten Lodderstedt > >> Cc: OAuth WG (oauth@ietf.org) > >> Subject: Re: [OAUTH-WG] OAuth Discovery Requirements > >> > >> Would it make sense to support two scenarios? (1) Discovery as=20 > >> described in my original posting independent of "functional"=20 > >> requests. (2) Discovery for unauthorized requests=20 > (WWW-Authenticate=20 > >> header). > >> > >> The later might be a lightweight variant of the first scenario. > >> > >> regards, > >> Torsten. > >> > >> > >> > >> Am 02.08.2010 um 22:20 schrieb Torsten Lodderstedt > >> : > >> > >> =20 > >>> In the WG meeting at Maastricht, I have been asked to write > >>> =20 > >> down my requirements regarding Discovery. And here they are: > >> =20 > >>> Assumptions: Discovery allows a compliant client to > >>> =20 > >> automatically obtain all deployment specific data required to=20 > >> securely access a particular resource servers as well as its=20 > >> respective authorization server for the purpose of=20 > obtaining access=20 > >> tokens. > >> =20 > >>> Starting point of the discovery process is a resource URL. > >>> =20 > >> This URL can be hard-coded into the client, bundled with the=20 > >> applications resources or manually configured by the end-user at=20 > >> runtime. > >> =20 > >>> 1) Client -> Resource > >>> The client uses the resource URL to obtain=20 > resource-specific data,=20 > >>> such as > >>> a) one URI refering to its authorization server > >>> b) a definition of all scopes of the resource > >>> c) additional data, e.g. supported signature methods and=20 > algorithms > >>> > >>> I do not make any assumption about how many requests are > >>> =20 > >> processed in order to gather this information and whether=20 > there will=20 > >> be any levels of indirections (e.g. from resource to resource=20 > >> server). > >> =20 > >>> 2) Client -> Authz Server > >>> The authz server URI obtained in step 1 is used to gather > >>> =20 > >> the following data from the authz server: > >> =20 > >>> a) endpoint URLs (end-user authorization, tokens, ...) > >>> b) information about the server's capabilities, e.g. the=20 > supported=20 > >>> response (end-user authorization endpoint) and grant types (tokens > >>> endpoint) > >>> > >>> The client stores the authz server's discovery URL along > >>> =20 > >> with the token(s) it obtains for further use. > >> =20 > >>> And that's it from my point of view. I would very much > >>> =20 > >> appreciate if we could have a discussion towards a consensus about=20 > >> discovery requirements. > >> =20 > >>> regards, > >>> Torsten. > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > = From oleg_gryb@yahoo.com Wed Aug 4 10:19:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77073A6A00 for ; Wed, 4 Aug 2010 10:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpN0KL70M4uf for ; Wed, 4 Aug 2010 10:19:55 -0700 (PDT) Received: from web37601.mail.mud.yahoo.com (web37601.mail.mud.yahoo.com [209.191.87.84]) by core3.amsl.com (Postfix) with SMTP id D27A03A6878 for ; Wed, 4 Aug 2010 10:19:55 -0700 (PDT) Received: (qmail 23098 invoked by uid 60001); 4 Aug 2010 17:20:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280942419; bh=3RRsZEqFjUtpZvaTCLZIrVIX/vnM6WIbcIAxvLc7gQo=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=y9HqZDUphSfzi3ySJEc7wAUztVSpgVIV/v7exAcunpgM/lcSYFX+daAZnLs4R5khJhRPExhV2Hh+R8Kt/xU18ZNCUSLaMYwgm3tSdQEhljKFALR2uTBsueIcYNxNIFp8cYYQzLy/4Ue5diBOd7cOr2v6qrV/LZpwA9SMe+cCfSk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Kuqd65ZQpZO7jo9btzf6Uys0F3sJDFnZPlxBi4lC9fbFdZwnF8hy/e7Ks9cGGz83ZQjjdN1r70zRtfbP92ItyRs93DLFGR1NnkrGDH+vwkJllo6CSszwkQxGBzAjSI/5GHVb5VCM/eNw7Rh7mHiZftREDUV/9nStwXz/9NWEszQ=; Message-ID: <297523.22901.qm@web37601.mail.mud.yahoo.com> X-YMail-OSG: MbbQwVoVM1mGfk7xzU5YbSliYcaZS0vX8eG3e5OllTP36jJ AVMYTqih7DgYWU8UQN3ya1X7FsWqdBgFZXbeN8bFomjYsxOd7ZHhjO7epGgs 2y_86LO1MhCsBbtulm9B4vJULCSotxGL3EzSh9W2s5T2BYu5k8_RhQBeaw_x 9xZPwL7XXT.5HXA76roS.WTd5XTx_fgJnsqL9R9G1LwEnonoGwcHt0Z5MIvm Qzex3kMXN5GzeTkgm.ubN1oNO47eX0zIgSFEy7gxUQXKJad7mhqx4U4JwoPu XbecpZMvaf8RH6pmeRhseLvKSi1KAwq.PtKiqv8eHmuFFTCt9P1k9RjsAcCc FG2wZje5u7MHBE0eIdEvb Received: from [208.240.243.170] by web37601.mail.mud.yahoo.com via HTTP; Wed, 04 Aug 2010 10:20:18 PDT X-Mailer: YahooMailRC/459 YahooMailWebService/0.8.105.279950 References: <771758.85209.qm@web37603.mail.mud.yahoo.com> <92530.680.qm@web37602.mail.mud.yahoo.com> Date: Wed, 4 Aug 2010 10:20:18 -0700 (PDT) From: Oleg Gryb To: Michael D Adams In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 17:19:57 -0000 ----- Original Message ---- > From: Michael D Adams > As Brian mentioned, the client-side component hosted on thirdparty.com > does get the access token in the User Agent flow. That means the > client-side script can access multiple protected resources (upload a > photo, update the user's profile, flag the user as "online", download > a friends list, whatever) in the same page load. > > If I'm interpreting your idea correctly, only one protected resource > can be accessed per access token since the thirdparty.com app never > sees the token. For every resource it needs, thirdparty.com has to > send the user through the authorization server again. Am I mistaken? in my example, after: document.params.setAttribute("action", url); you can add: document.cookie="access_token=... Theoretically, it'll create a cookie in the resource server domain (I'm saying theoretically, becuase didn't test it). Next time when UA goes to the same resource server, the latter can use the cookie to do authentication. It means that you don't need to go to authz server again until token is expired. If this is correct, why would you need to share the secret with thirdparty.com server? It actually makes the solution more secure, if you don't, becuase access token is known to UA only. In my Ajax example you don't even need a cookie, becuase access_token can be stored in a JavaScript variable. From michael.d.adams@gmail.com Wed Aug 4 10:55:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03BF3A691B for ; Wed, 4 Aug 2010 10:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JteCUzEyrAnx for ; Wed, 4 Aug 2010 10:55:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id A130B3A657C for ; Wed, 4 Aug 2010 10:55:01 -0700 (PDT) Received: by pzk6 with SMTP id 6so2450815pzk.31 for ; Wed, 04 Aug 2010 10:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=QgWzeJjX8ixYChFsJC+qH7tYTDFpPF48LQj8AwzU8Gk=; b=WubSytJFJlFBrNHMFMKGSLTgCO1eWwFEdykpclDpgC9RtoGsXTWVHFKQxwe4RYvjCT HTLIB8nKWugD4SR0lxYzapYUBRplm5QHvtA+TZNHwfpcfXcpvt3nxUNkv9YBgXlvbu80 qGjQF2/QPCfeK3MhVfalILSdWHLvhx9SdyOr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=n8M+4rkYsmbLFhnpdbSz+UFg2UHtc/8r8auWuijzn5JnbxjeYprIXcPTSkyeyHx0Cw TKlj52/8HpyG5eH/fTjZM+aRYFf6DHOrrpAjbsgHGk2BQnA1Jb/fMei1i5DZjwJQpq4m gXXIzxkiAW1ft+GGEBA788SUbcmZ1vMXX9p0A= Received: by 10.114.39.18 with SMTP id m18mr11084436wam.225.1280944528754; Wed, 04 Aug 2010 10:55:28 -0700 (PDT) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.231.179.143 with HTTP; Wed, 4 Aug 2010 10:55:08 -0700 (PDT) In-Reply-To: <297523.22901.qm@web37601.mail.mud.yahoo.com> References: <771758.85209.qm@web37603.mail.mud.yahoo.com> <92530.680.qm@web37602.mail.mud.yahoo.com> <297523.22901.qm@web37601.mail.mud.yahoo.com> From: Michael D Adams Date: Wed, 4 Aug 2010 10:55:08 -0700 X-Google-Sender-Auth: dvrxyaE57N_NXII2JRcI-1wHGiw Message-ID: To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 17:55:03 -0000 On Wed, Aug 4, 2010 at 10:20 AM, Oleg Gryb wrote: > ----- Original Message ---- >> From: Michael D Adams >> As Brian mentioned, the client-side component =A0hosted on thirdparty.co= m >> does get the access token in the User Agent =A0flow. =A0That means the >> client-side script can access multiple protected =A0resources (upload a >> photo, update the user's profile, flag the user as =A0"online", download >> a friends list, whatever) in the same page load. >> >> If =A0I'm interpreting your idea correctly, only one protected resource >> can be =A0accessed per access token since the thirdparty.com app never >> sees the =A0token. =A0For every resource it needs, thirdparty.com has to >> send the user =A0through the authorization server again. =A0Am I =A0mist= aken? > > in my example, after: > document.params.setAttribute("action", url); > > you can add: > document.cookie=3D"access_token=3D... > > Theoretically, it'll create a cookie in the resource server domain (I'm s= aying > theoretically, becuase didn't test it). Next time when UA goes to the sam= e > resource server, the latter can use the cookie to do authentication. It m= eans > that you don't need to go to authz server again until token is expired. I thought that page in your idea was being served from the Authorization Server (not the Resource Server). If that's true, the cookie would be on the wrong domain. Mike From oleg_gryb@yahoo.com Wed Aug 4 11:07:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441AB3A6A1C for ; Wed, 4 Aug 2010 11:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5xVCwqtjLyt for ; Wed, 4 Aug 2010 11:07:27 -0700 (PDT) Received: from web37603.mail.mud.yahoo.com (web37603.mail.mud.yahoo.com [209.191.87.86]) by core3.amsl.com (Postfix) with SMTP id 84FCC3A6A8D for ; Wed, 4 Aug 2010 11:07:21 -0700 (PDT) Received: (qmail 93706 invoked by uid 60001); 4 Aug 2010 18:07:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1280945267; bh=C3LKZvvZ/YP+/6rhG/9xb4GtKGDjpw/8VcSvGRJoWMw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GU+JnaD/RyQiYB8hifAczhPLXAp37cA2tf5AWOSr99tZ75uTOlUuiT6NxYjVDwrZTQb/ZxzZWkI+FZjhvbkcO9zlkta5AgTXGmKmQ2D1cPW4a9uSZ7xU983WZ+7/K8nJWXk6NO/ZYyje6U1atUM4bfjz517KMlcp6fRhXTBK/ZY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=x2UClF9p73xVVMv1RrxKwfGrFJNKMcbNRo+MEG/eMK1B43oisuZWj0k4lps74Qla9wPztf56xLTmY8VifpcUzLN13nZEZj9jVhzUTkGWuXniHk3Cgoyn41M6jqAYvuvIu6fukMOs6M2NWEfd1oRRM3rAjvi7Q2gQ4i1CpjvIIqQ=; Message-ID: <312956.93696.qm@web37603.mail.mud.yahoo.com> X-YMail-OSG: 0sBwzQsVM1kswIynhm911YyZXNa0ik09gzCBpRxx2UstpdL Dvbh0PAbyfYSjvsaYrsaHfvQNKCAGVWj.qyM89eBv3FZZTBqouBer0A3NTWJ wiOJ5Gp9U808_gbJjzu2AVMHGHi6BkDV7fcjzGzoKPR7ucY5UkJq8v3Mc_IY qSbnSQX67EEheTi07IaDjUh7rEPZ40bnpqRmuDuftlD5D7boAEMQvQaAqwF4 cIXmzH1xABbQDWNi5ZdqWoeDIeiuwrOKXo_9kgtYkNCpCE4cEBnW8jzdQ3pr z_747xfdDbbaEu7IvX7iQi7vjNYgewZMqjuPHPNhWt4eMzG6BTUYVQVRxWZz 0qZZndVRsNlCpf487rHc- Received: from [208.240.243.170] by web37603.mail.mud.yahoo.com via HTTP; Wed, 04 Aug 2010 11:07:46 PDT X-Mailer: YahooMailRC/459 YahooMailWebService/0.8.105.279950 References: <771758.85209.qm@web37603.mail.mud.yahoo.com> <92530.680.qm@web37602.mail.mud.yahoo.com> <297523.22901.qm@web37601.mail.mud.yahoo.com> Date: Wed, 4 Aug 2010 11:07:46 -0700 (PDT) From: Oleg Gryb To: Michael D Adams , Oleg Gryb In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 18:07:29 -0000 ----- Original Message ---- > From: Michael D Adams > I thought that page in your idea was being served from the > Authorization Server (not the Resource Server). If that's true, the > cookie would be on the wrong domain. It might be a problem if resource and authz servers are in different domains, but in all discussions with Brian we used that "service provider" term and I've assumed that service provider acts like authz server and resource server or at least latter two are in the same domain. I think it's a common scenario for web apps when authentication logic resides on the same web server where protected resources are. It's not the major point though. The hypothesis that I'm trying to prove is that access token doesn't need to be transferred in a URL. From prateek.mishra@oracle.com Wed Aug 4 14:00:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E483A6A0D for ; Wed, 4 Aug 2010 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWKX+8nKuY63 for ; Wed, 4 Aug 2010 14:00:55 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 6CCD33A6861 for ; Wed, 4 Aug 2010 14:00:55 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o74L1KHS008801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 Aug 2010 21:01:21 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o74KMRuF006101 for ; Wed, 4 Aug 2010 21:01:18 GMT Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 485698161280955676; Wed, 04 Aug 2010 14:01:16 -0700 Received: from [10.159.11.221] (/10.159.11.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Aug 2010 14:01:16 -0700 Message-ID: <4C59D4FC.3070700@oracle.com> Date: Wed, 04 Aug 2010 17:00:44 -0400 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: oauth References: <4C598270.1050304@oracle.com> <77AEC44D4DA08A46ADAA723286626BC19D02169549@EXSFM-MB01.internal.salesforce.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4C59D51F.011F:SCFMA4539814,ss=1,fgs=0 Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 21:00:57 -0000 Thanks for the clarification (Paul, Chuck and Brian), re-reading the=20 most recent draft makes the use-case pretty clear, not sure how I came=20 up with my own personal use-case in this instance (not enough coffee=20 probably...) To me it seems that this is an instance of a SAML --> OAuth token=20 mapping service, which seems a pretty useful service. One question is=20 whether there needs to be a general framework for its use; I guess this=20 was the substance of interaction between Brian and Tony earlier in the=20 thread. I guess I need to research the issue some more before joining=20 that discussion. Here is a simpler question: is there a requirement that the Client/IdP=20 authenticate to the Authorization server when presenting the SAML bearer = token? I didnt see it in the current draft - or is that taken care of in = the base OAuth 2.0 protocol? - prateek > Good explanation, thanks Chuck. > > On Wed, Aug 4, 2010 at 9:43 AM, Chuck Mortimore > wrote: > =20 >> Hi Prateek >> >> The use-case we were going for here is really more like a classic 2-le= gged oauth scenario. A company has an existing SAML web federation est= ablished with a service provider which is providing SSO to it's users. = They now want to perform API based integration with the service provider= to perform some data integration on-behalf of the user, for instance syn= c their calendar. This function needs to execute as that user account, = and the company does not wish to establish or use passwords at the servic= e provider. They have 10000 users, and do not wish for each of them to = go through a classic 3 legged delegation flow; there are too many users t= o coordinate and 1 single trust decision by a privileged admin will suffi= ce. So - the company / service provider decide to reuse their existing= SAML configuration for API federation. (note that nothing about the pro= file dictates you need to have web sso in place, nor reuse the metadata e= xchange...just and example ) >> >> The company acts as both the IDP and OAuth2 client. Their integratio= n client obtains the assertion and posts it to the token endpoint. The = token endpoint generates an access token for the subject of the SAML asse= rtion and the integration client can now execute as that user. The asse= rtion is discarded. >> >> So - this is intended to be very much like web sso and use short lived= bearer assertions that are exchanged for API sessions. >> >> Hope that helps clarify. >> >> -cmort >> >> >> ________________________________________ >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Pra= teek Mishra [prateek.mishra@oracle.com] >> Sent: Wednesday, August 04, 2010 8:08 AM >> To: Brian Campbell >> Cc: oauth >> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.= 0 draft >> >> Brian, >> >> it would probably help to clarify that you are proposing this as a >> additional or follow-on step to SSO implemented via the SAML web brows= er >> profiles (right?). >> >> Maybe some text could be added to the draft to make that explicit. Thi= s >> is in contrast to more general token exchange scenarios - here >> are bunch of SAML /XYZ tokens, now give me an OAuth token for for a >> certain purpose. I agree with you that the latter would require quite = a >> bit of additional work. >> >> Here is my understanding of the current use-case - >> >> The user delivers a SAML bearer token (issued at an IdP) via a browser= >> profile to an SP. The SP, performs some business service for the user >> and at some point >> requires access to user resources at the IdP or at some third-party >> site. Switching to OAuth terminology, the Client (SP) exchanges the sa= id >> SAML bearer token to the Authorization server (could be at the IdP - >> this would be a common case I think) for an OAuth token. This is the >> exchange you are describing in your draft. >> >> Once the client obtains the OAuth token, it can bind it to a request f= or >> the user resource. >> >> I have some mild SAMology concerns about this - historically the SAML >> bearer token has been constrained to have a short life-time and the >> general advice is not to forward it beyond the SP. I am aware that in >> practice this isnt the case - often the token is bound to some >> subsequent flows - somewhat along the lines you are proposing. I will >> follow up with these concerns on the SAML list. >> >> - prateek >> =20 >>> Seems like a much more complicated scenario. Allowing more than one >>> assertion, off the top of my head, would necessitate some major >>> changes to this profile: >>> >>> * Define how multiple assertions are encoded into the single >>> "assertion" form control (samlp:Response, concatenated, something >>> else?) >>> * Deal with subject equality across the assertions >>> * Define the processing rules for multiple assertion (from different >>> issuers) and the expected behavior when some but not all are valid. >>> >>> That seems like it would add significant complexity to the existing >>> draft (that I'm trying to keep simple) for a particular scenario that= >>> I'm not sure is very common. But maybe I'm wrong. Is this something= >>> that others anticipate needing? If so, does it belong here? >>> >>> >>> On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin wrote: >>> >>> =20 >>>> So the scenario we have is where there are multiple tokens from attr= ibute and identity providers need to be delivered to an OAuth authorizati= on server to satisfy the resource owner's policy of required claims. So t= his is a case where a single SAML token/assertion is not enough to satisf= y the claim, we still expect that the signature verification is out of sc= ope. >>>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf Of Brian Campbell >>>> Sent: Monday, August 02, 2010 2:53 PM >>>> To: oauth >>>> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth = 2.0 draft >>>> >>>> I guess I'd need to understand the scenario better before I'd have a= n >>>> opinion one way or the other. However, I will say that In this >>>> profile I was specifically looking to avoid the complexity that exis= ts in SAML Web SSO by allowing for multiple assertions and multiple subje= ct confirmations. >>>> >>>> On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin wrote: >>>> >>>> =20 >>>>> There are many cases where we need to have more than 1 SAML asserti= on be used to represent the authorization token, so would want a provisio= n for multiple SAML tokens and not sure it makes sense to have a separate= profile for that or add it as an option here. >>>>> >>>>> -----Original Message----- >>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beh= alf >>>>> Of Brian Campbell >>>>> Sent: Thursday, July 15, 2010 1:50 PM >>>>> To: oauth >>>>> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0= >>>>> draft >>>>> >>>>> I'm gong to join the growing list of people attaching a potential I= -D >>>>> to an email due to he cut off time for the I-D submissions. Attach= ed >>>>> is a draft that aims to tightly define the particular format of a S= AML >>>>> 2.0 bearer assertion in requesting an access token using the assert= ion >>>>> grant_type. I've been working with Chuck at Salesforce.com on thi= s >>>>> and the primary goal is to have some documentation or specification= >>>>> that is sufficient to facilitate interoperability between >>>>> independently developed implementations or products. This, of co= urse, wouldn't preclude using SAML in other ways - it would only provide = one concrete definition to implement against. >>>>> >>>>> I intend to submit this as an I-D when the submission process reope= ns. >>>>> Any feedback from this group would be appreciated as well as thoug= hts about this eventually becoming a working group draft. >>>>> >>>>> Thanks, >>>>> Brian Campbell >>>>> >>>>> >>>>> =20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> =20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > =20 From eran@hueniverse.com Wed Aug 4 15:39:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 928AA3A69ED for ; Wed, 4 Aug 2010 15:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PaHrPqnrG-f for ; Wed, 4 Aug 2010 15:39:14 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EDA0D3A683F for ; Wed, 4 Aug 2010 15:39:13 -0700 (PDT) Received: (qmail 16105 invoked from network); 4 Aug 2010 22:39:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 4 Aug 2010 22:39:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 4 Aug 2010 15:39:42 -0700 From: Eran Hammer-Lahav To: William Mills , Torsten Lodderstedt Date: Wed, 4 Aug 2010 15:39:38 -0700 Thread-Topic: [OAUTH-WG] OAuth Discovery Requirements Thread-Index: AcszqHj9uobISEvkQnmIdZRKXXHWPwARQm7wAA4Z6WA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03AC4D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C572883.7020302@lodderstedt.net> <9517276C-A806-4630-84D1-6B3F1F6A7754@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:39:16 -0000 Yes. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Wednesday, August 04, 2010 9:05 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements >=20 > I'm assuming that the WWW-Authenticate style will also be supported > (because I'm going to try to make sure it gets added). I specifically wa= nt this > for SASL discovery. >=20 > -bill >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Torsten Lodderstedt > > Sent: Wednesday, August 04, 2010 12:39 AM > > To: Torsten Lodderstedt > > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] OAuth Discovery Requirements > > > > Would it make sense to support two scenarios? (1) Discovery as > > described in my original posting independent of "functional" requests. > > (2) Discovery for unauthorized requests (WWW-Authenticate header). > > > > The later might be a lightweight variant of the first scenario. > > > > regards, > > Torsten. > > > > > > > > Am 02.08.2010 um 22:20 schrieb Torsten Lodderstedt > > : > > > > > In the WG meeting at Maastricht, I have been asked to write > > down my requirements regarding Discovery. And here they are: > > > > > > Assumptions: Discovery allows a compliant client to > > automatically obtain all deployment specific data required to securely > > access a particular resource servers as well as its respective > > authorization server for the purpose of obtaining access tokens. > > > > > > Starting point of the discovery process is a resource URL. > > This URL can be hard-coded into the client, bundled with the > > applications resources or manually configured by the end-user at > > runtime. > > > > > > 1) Client -> Resource > > > The client uses the resource URL to obtain resource-specific data, > > > such as > > > a) one URI refering to its authorization server > > > b) a definition of all scopes of the resource > > > c) additional data, e.g. supported signature methods and algorithms > > > > > > I do not make any assumption about how many requests are > > processed in order to gather this information and whether there will > > be any levels of indirections (e.g. from resource to resource server). > > > > > > 2) Client -> Authz Server > > > The authz server URI obtained in step 1 is used to gather > > the following data from the authz server: > > > a) endpoint URLs (end-user authorization, tokens, ...) > > > b) information about the server's capabilities, e.g. the supported > > > response (end-user authorization endpoint) and grant types (tokens > > > endpoint) > > > > > > The client stores the authz server's discovery URL along > > with the token(s) it obtains for further use. > > > > > > And that's it from my point of view. I would very much > > appreciate if we could have a discussion towards a consensus about > > discovery requirements. > > > > > > regards, > > > Torsten. > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Aug 4 15:44:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BCD3A69ED for ; Wed, 4 Aug 2010 15:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf2KfDmOS-1H for ; Wed, 4 Aug 2010 15:44:57 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id F02133A6849 for ; Wed, 4 Aug 2010 15:44:56 -0700 (PDT) Received: (qmail 13195 invoked from network); 4 Aug 2010 22:45:25 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 4 Aug 2010 22:45:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 4 Aug 2010 15:45:24 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Wed, 4 Aug 2010 15:45:20 -0700 Thread-Topic: [OAUTH-WG] Extensibility: new endpoints Thread-Index: Acsz9ze1X07C/5QuQyW6EEpL13ztsgALuxBA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F03AC54@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A764@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C599DBA.5070407@lodderstedt.net> In-Reply-To: <4C599DBA.5070407@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:44:58 -0000 I hope to have some discovery draft to share shortly after the next core dr= aft. It would be very much in line with the discovery stuff from previous c= ore drafts before I took it out (-05). As for WG process/focus, that's the job of the chairs to figure out. I have= no intention of drafting or editing any additional specs beyond core and d= iscovery. The only practical approach I have found is to simply ask people to express= their views and request in the form of feedback for the latest draft. If y= ou think something is missing or needs to change, the way to address it is = as feedback. I will add or change the spec based on my best sense of WG consensus since = that's all I have to work with. If you don't like this, please talk to the = chairs. EHL > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Wednesday, August 04, 2010 10:05 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org); Brian Eaton > Subject: Re: [OAUTH-WG] Extensibility: new endpoints >=20 > > > >> ideas. I still hope to get the discovery spec finished in the same > >> timeframe, but have no plans to author or edit any other draft. > >> > >> Just to get this clear. Do you plan to author the discovery spec? And > >> what is the core spec's timeframe? > >> > > I have started to write the discovery spec, but work on the core spec h= as > taken most of my free time to do this (OAuth is not part of my day job). > > >=20 > The same holds for me :-) Would you mind to share your thoughts regarding > discovery with the group. I especially would like to know, whether you ag= ree > with the requirements I described in "OAuth Discovery Requirements" and > how they can be met. >=20 > > I have no idea what's the timeframe for the core spec. This groups isn'= t > very good at providing timely feedback and staying focused. >=20 > Good point. What might be the reasons for the missing focus? In my opinio= n, > there are a couple of. >=20 > First of all, what is the "thing" we shall be focusing on? That's not cle= ar to me > (probably also to others). I therefore asked for your plans to include se= veral > aspects in the core spec. Moreover, it's also not clear to me what > complementary specs and sub-sequent versions of the core spec the WG will > produce in the future. As an effect, everyone is afraid that his/her own = ideas > are not being considered and focuses on advocating them. If we find a WG > consensus on the core spec or "first stage" and also the additional WG it= ems, > work will probably become more focused. My impression after attending > IETF 78 is, bringing the core spec through the IETF approval process will= be > hard enough! >=20 > Additionally, I think the WG lacks consensus on what OAuth 2.0 should be, > especially regarding fundamental architectural questions and there > consequences! Just to list a few: > - supported use cases and client types (there is more than web clients :-= )) > - number of resource servers an authorization can handle (1:1 vs. 1:n) > (resource server specific tokens + resource server addressing) > - supported token types (self-contained vs. artifacts vs. session ids) > - usage of scopes (resources vs. resource server vs. permissions vs. > duration vs. ...) > - role of signatures (none, authentication, prove of posession, message > integrity, ...) + key management approaches > - security level (none, relaxed, state-of-the-art, paranoid), probably th= ere is > a need for different OAuth security profiles >=20 > This not only results in a spec difficult to understand for an "outsider"= . It also > causes endless discussions around those or derived topics. >=20 > > So far no one has offered to work on the security consideration section > (Brian's draft is too far from the format I need to incorporate). > > >=20 > I could work on this topic, if Brian does not insist to do so. > @Brian: What do you think? >=20 > From my point of view, the security considerations could be worked out o= n a > per flow/profile base by multiple contributers (anyone interested?). At l= east > we should agree on a common set of threat agents and a template. >=20 > > I am planning the next draft for early September which will include the= few > changes raised on the list, but will focus on finding a middle ground bet= ween > detailed profiles and a generic architecture (editorial work). > > >=20 > Good luck! >=20 > regards, > Torsten. >=20 > > EHL > > > > > >>>> What about the following topics? > >>>> - security considerations > >>>> > >>> That's part of core and someone has to write it. I'd like to see > >>> someone > >>> > >> take the security section from RFC 5849 and rework it to match 2.0, > >> as well as add everything that is missing. I will incorporate it and > >> take care of the editorial work but I am not writing it from scratch. > >> > >>> > >>>> - token revocation (requested by several attendees during > >>>> Maastricht WG meeting) > >>>> > >>> Someone needs to write a proposal and work to get WG consensus (to > >>> the > >>> > >> point where enough people say they like it and no one is objecting). > >> Get it there, I'll do the rest. Feel free to ask the chairs to help ou= t. > >> > >>> > >>>> - signatures > >>>> > >>> I think Nat offered to take a stab at a first draft based on Dirk's > >>> work and > >>> > >> the WG discussions. I have offered to help with editorial work if > requested. > >> > >>> EHL > >>> > >>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> > >>>> Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav > >>>> : > >>>> General discussions on the list and during the interim meeting. > >>>> > >>>> EHL > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >>>> Sent: Monday, August 02, 2010 1:20 PM > >>>> To: Eran Hammer-Lahav > >>>> Cc: OAuth WG (oauth@ietf.org) > >>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints > >>>> > >>>> What consensus do you refer to? The WG charter? > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: > >>>> No according to WG consensus. We took it all out because too many > >>>> people considered it experimental, so while it may be a WG item, it > >>>> is not part of the core spes. > >>>> > >>>> EHL > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > >>>> Sent: Monday, August 02, 2010 1:07 PM > >>>> To: Eran Hammer-Lahav > >>>> Cc: OAuth WG (oauth@ietf.org) > >>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints > >>>> > >>>> and discovery does not belong into the core? > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: > >>>> > >>>> This doesn't belong in core. A registry is used to avoid name > >>>> collisions, not > >>>> > >>>> to provide an inventory. > >>>> > >>>> Maybe in discovery. > >>>> > >>>> EHL > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf Of Torsten Lodderstedt > >>>> Sent: Monday, August 02, 2010 12:54 PM > >>>> To: OAuth WG (oauth@ietf.org) > >>>> Subject: [OAUTH-WG] Extensibility: new endpoints > >>>> > >>>> the existing authorization server endpoints (end-user authorization > >>>> and tokens endpoint) have a relatively clearly semantics and scope. > >>>> Adding distinct new functions to an authorization server will (in > >>>> my > >>>> opionion) require the definition of new endpoints. For example, I'm > >>>> working on an I-D for token revocation. Such a function does not > >>>> fit into the tokens endpoint since it has become a "token issuance > >>>> endpoint" rather than a general purpose client2server endpoint. > >>>> > >>>> I therefore would propose to include the option to define and > >>>> register new endpoints into the Extensibility section of the spec. > >>>> This would also facilitate the incorporation of additional > >>>> endpoints (with well- defined names) into OAuth discovery. > >>>> > >>>> Any thoughts? > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > >>>> > >>>> > >>>> > >>>> > >>> From beaton@google.com Wed Aug 4 17:08:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84363A6AC0 for ; Wed, 4 Aug 2010 17:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.848 X-Spam-Level: X-Spam-Status: No, score=-105.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsJLgJB5fpZ1 for ; Wed, 4 Aug 2010 17:08:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C06B53A681D for ; Wed, 4 Aug 2010 17:08:50 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id o7509KKT029518 for ; Wed, 4 Aug 2010 17:09:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1280966960; bh=QKv9O02GnoQFPWHdFPoXpab9caM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=V/vOnOrdzFjcqbwzj9rhr02CxqjNSlpR36qpjU5TyD3tQHMwI6gt8tdcEX2MBvadj Q9w6YsVWpcPCwHbWMhsxQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=OemskBMj47RQuIdsrzjDjsglcBlqXBKTkwQFs7g65V9pZGESul65G/jdN5MErnixJ LCYbXPlvKybbXwyE2ZJWg== Received: from pzk7 (pzk7.prod.google.com [10.243.19.135]) by hpaq14.eem.corp.google.com with ESMTP id o7509IYM009794 for ; Wed, 4 Aug 2010 17:09:18 -0700 Received: by pzk7 with SMTP id 7so2563109pzk.13 for ; Wed, 04 Aug 2010 17:09:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.172.6 with SMTP id u6mr8281452wfe.52.1280966957592; Wed, 04 Aug 2010 17:09:17 -0700 (PDT) Received: by 10.143.46.3 with HTTP; Wed, 4 Aug 2010 17:09:17 -0700 (PDT) In-Reply-To: <4C599DBA.5070407@lodderstedt.net> References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A764@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C599DBA.5070407@lodderstedt.net> Date: Wed, 4 Aug 2010 17:09:17 -0700 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 00:08:51 -0000 On Wed, Aug 4, 2010 at 10:04 AM, Torsten Lodderstedt wrote: >> So far no one has offered to work on the security consideration section >> (Brian's draft is too far from the format I need to incorporate). >> > > I could work on this topic, if Brian does not insist to do so. > @Brian: What do you think? Go for it. > From my point of view, the security considerations could be worked out on a > per flow/profile base by multiple contributers (anyone interested?). At > least we should agree on a common set of threat agents and a template. Yeah, the security considerations are different for different profiles. From torsten@lodderstedt.net Thu Aug 5 01:07:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CA183A6868 for ; Thu, 5 Aug 2010 01:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.815 X-Spam-Level: X-Spam-Status: No, score=-0.815 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhqsX1J5sz3y for ; Thu, 5 Aug 2010 01:07:38 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id B928D3A67A1 for ; Thu, 5 Aug 2010 01:07:37 -0700 (PDT) Received: from [80.187.108.100] (helo=[10.167.87.68]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OgvUh-0001HE-5G; Thu, 05 Aug 2010 10:08:06 +0200 References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A764@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C599DBA.5070407@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03AC54@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03AC54@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <949D90AE-FFC9-485C-A382-E7F9A173E883@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Thu, 5 Aug 2010 10:07:09 +0200 To: Eran Hammer-Lahav X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:07:39 -0000 Am 05.08.2010 um 00:45 schrieb Eran Hammer-Lahav : > I hope to have some discovery draft to share shortly after the next core d= raft. It would be very much in line with the discovery stuff from previous c= ore drafts before I took it out (-05). >=20 > As for WG process/focus, that's the job of the chairs to figure out. I hav= e no intention of drafting or editing any additional specs beyond core and d= iscovery. >=20 > The only practical approach I have found is to simply ask people to expres= s their views and request in the form of feedback for the latest draft. If y= ou think something is missing or needs to change, the way to address it is a= s feedback. >=20 > I will add or change the spec based on my best sense of WG consensus since= that's all I have to work with. If you don't like this, please talk to the c= hairs. >=20 I didn't intend to criticize you, I think you do a terrible good job as an e= ditor. I just offered my opinion of why this WG is not as focused as you wou= ld expect it. regards, Torsten. > EHL >=20 >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Wednesday, August 04, 2010 10:05 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org); Brian Eaton >> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>=20 >>>=20 >>>> ideas. I still hope to get the discovery spec finished in the same >>>> timeframe, but have no plans to author or edit any other draft. >>>>=20 >>>> Just to get this clear. Do you plan to author the discovery spec? And >>>> what is the core spec's timeframe? >>>>=20 >>> I have started to write the discovery spec, but work on the core spec ha= s >> taken most of my free time to do this (OAuth is not part of my day job). >>>=20 >>=20 >> The same holds for me :-) Would you mind to share your thoughts regarding= >> discovery with the group. I especially would like to know, whether you ag= ree >> with the requirements I described in "OAuth Discovery Requirements" and >> how they can be met. >>=20 >>> I have no idea what's the timeframe for the core spec. This groups isn't= >> very good at providing timely feedback and staying focused. >>=20 >> Good point. What might be the reasons for the missing focus? In my opinio= n, >> there are a couple of. >>=20 >> First of all, what is the "thing" we shall be focusing on? That's not cle= ar to me >> (probably also to others). I therefore asked for your plans to include se= veral >> aspects in the core spec. Moreover, it's also not clear to me what >> complementary specs and sub-sequent versions of the core spec the WG will= >> produce in the future. As an effect, everyone is afraid that his/her own i= deas >> are not being considered and focuses on advocating them. If we find a WG >> consensus on the core spec or "first stage" and also the additional WG it= ems, >> work will probably become more focused. My impression after attending >> IETF 78 is, bringing the core spec through the IETF approval process will= be >> hard enough! >>=20 >> Additionally, I think the WG lacks consensus on what OAuth 2.0 should be,= >> especially regarding fundamental architectural questions and there >> consequences! Just to list a few: >> - supported use cases and client types (there is more than web clients :-= )) >> - number of resource servers an authorization can handle (1:1 vs. 1:n) >> (resource server specific tokens + resource server addressing) >> - supported token types (self-contained vs. artifacts vs. session ids) >> - usage of scopes (resources vs. resource server vs. permissions vs. >> duration vs. ...) >> - role of signatures (none, authentication, prove of posession, message >> integrity, ...) + key management approaches >> - security level (none, relaxed, state-of-the-art, paranoid), probably th= ere is >> a need for different OAuth security profiles >>=20 >> This not only results in a spec difficult to understand for an "outsider"= . It also >> causes endless discussions around those or derived topics. >>=20 >>> So far no one has offered to work on the security consideration section >> (Brian's draft is too far from the format I need to incorporate). >>>=20 >>=20 >> I could work on this topic, if Brian does not insist to do so. >> @Brian: What do you think? >>=20 >> =46rom my point of view, the security considerations could be worked out o= n a >> per flow/profile base by multiple contributers (anyone interested?). At l= east >> we should agree on a common set of threat agents and a template. >>=20 >>> I am planning the next draft for early September which will include the f= ew >> changes raised on the list, but will focus on finding a middle ground bet= ween >> detailed profiles and a generic architecture (editorial work). >>>=20 >>=20 >> Good luck! >>=20 >> regards, >> Torsten. >>=20 >>> EHL >>>=20 >>>=20 >>>>>> What about the following topics? >>>>>> - security considerations >>>>>>=20 >>>>> That's part of core and someone has to write it. I'd like to see >>>>> someone >>>>>=20 >>>> take the security section from RFC 5849 and rework it to match 2.0, >>>> as well as add everything that is missing. I will incorporate it and >>>> take care of the editorial work but I am not writing it from scratch. >>>>=20 >>>>>=20 >>>>>> - token revocation (requested by several attendees during >>>>>> Maastricht WG meeting) >>>>>>=20 >>>>> Someone needs to write a proposal and work to get WG consensus (to >>>>> the >>>>>=20 >>>> point where enough people say they like it and no one is objecting). >>>> Get it there, I'll do the rest. Feel free to ask the chairs to help out= . >>>>=20 >>>>>=20 >>>>>> - signatures >>>>>>=20 >>>>> I think Nat offered to take a stab at a first draft based on Dirk's >>>>> work and >>>>>=20 >>>> the WG discussions. I have offered to help with editorial work if >> requested. >>>>=20 >>>>> EHL >>>>>=20 >>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>> Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav >>>>>> : >>>>>> General discussions on the list and during the interim meeting. >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>>>>> Sent: Monday, August 02, 2010 1:20 PM >>>>>> To: Eran Hammer-Lahav >>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>>>>>=20 >>>>>> What consensus do you refer to? The WG charter? >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>> Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: >>>>>> No according to WG consensus. We took it all out because too many >>>>>> people considered it experimental, so while it may be a WG item, it >>>>>> is not part of the core spes. >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>>>>> Sent: Monday, August 02, 2010 1:07 PM >>>>>> To: Eran Hammer-Lahav >>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>>>>>=20 >>>>>> and discovery does not belong into the core? >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: >>>>>>=20 >>>>>> This doesn't belong in core. A registry is used to avoid name >>>>>> collisions, not >>>>>>=20 >>>>>> to provide an inventory. >>>>>>=20 >>>>>> Maybe in discovery. >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf Of Torsten Lodderstedt >>>>>> Sent: Monday, August 02, 2010 12:54 PM >>>>>> To: OAuth WG (oauth@ietf.org) >>>>>> Subject: [OAUTH-WG] Extensibility: new endpoints >>>>>>=20 >>>>>> the existing authorization server endpoints (end-user authorization >>>>>> and tokens endpoint) have a relatively clearly semantics and scope. >>>>>> Adding distinct new functions to an authorization server will (in >>>>>> my >>>>>> opionion) require the definition of new endpoints. For example, I'm >>>>>> working on an I-D for token revocation. Such a function does not >>>>>> fit into the tokens endpoint since it has become a "token issuance >>>>>> endpoint" rather than a general purpose client2server endpoint. >>>>>>=20 >>>>>> I therefore would propose to include the option to define and >>>>>> register new endpoints into the Extensibility section of the spec. >>>>>> This would also facilitate the incorporation of additional >>>>>> endpoints (with well- defined names) into OAuth discovery. >>>>>>=20 >>>>>> Any thoughts? >>>>>>=20 >>>>>> regards, >>>>>> Torsten. >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >=20 From torsten@lodderstedt.net Thu Aug 5 01:13:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD9EF3A680C for ; Thu, 5 Aug 2010 01:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVlGUdvZw4+O for ; Thu, 5 Aug 2010 01:13:26 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by core3.amsl.com (Postfix) with ESMTP id 1BBB03A68E4 for ; Thu, 5 Aug 2010 01:13:23 -0700 (PDT) Received: from [80.187.108.100] (helo=[10.167.87.68]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OgvaJ-0005EB-TG; Thu, 05 Aug 2010 10:13:53 +0200 References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A764@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C599DBA.5070407@lodderstedt.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5DD0697B-A93F-44D6-A447-70D888B5E868@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Thu, 5 Aug 2010 10:13:07 +0200 To: Brian Eaton X-Df-Sender: 141509 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 08:13:30 -0000 Brian, I would like to start from your security considerations document. Do you hav= e a documented threat model (attackers, attacks, propabilities) motivating t= he choosen counter-measures? regards, Torsten. Am 05.08.2010 um 02:09 schrieb Brian Eaton : > On Wed, Aug 4, 2010 at 10:04 AM, Torsten Lodderstedt > wrote: >>> So far no one has offered to work on the security consideration section >>> (Brian's draft is too far from the format I need to incorporate). >>>=20 >>=20 >> I could work on this topic, if Brian does not insist to do so. >> @Brian: What do you think? >=20 > Go for it. >=20 >> =46rom my point of view, the security considerations could be worked out o= n a >> per flow/profile base by multiple contributers (anyone interested?). At >> least we should agree on a common set of threat agents and a template. >=20 > Yeah, the security considerations are different for different profiles. From bcampbell@pingidentity.com Thu Aug 5 06:22:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72EB83A6B23 for ; Thu, 5 Aug 2010 06:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.853 X-Spam-Level: X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvQ00-B2wh0L for ; Thu, 5 Aug 2010 06:22:23 -0700 (PDT) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with SMTP id 5A23B3A6B22 for ; Thu, 5 Aug 2010 06:22:22 -0700 (PDT) Received: from source ([209.85.215.181]) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTFq7LDRXvNKRAKmjrtUuzaH1vjkUG4Gl@postini.com; Thu, 05 Aug 2010 06:22:54 PDT Received: by eydd26 with SMTP id d26so2508220eyd.26 for ; Thu, 05 Aug 2010 06:22:51 -0700 (PDT) Received: by 10.216.28.213 with SMTP id g63mr3442721wea.71.1281014567316; Thu, 05 Aug 2010 06:22:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Thu, 5 Aug 2010 06:22:17 -0700 (PDT) In-Reply-To: <4C59D4FC.3070700@oracle.com> References: <4C598270.1050304@oracle.com> <77AEC44D4DA08A46ADAA723286626BC19D02169549@EXSFM-MB01.internal.salesforce.com> <4C59D4FC.3070700@oracle.com> From: Brian Campbell Date: Thu, 5 Aug 2010 07:22:17 -0600 Message-ID: To: Prateek Mishra Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 13:22:25 -0000 On Wed, Aug 4, 2010 at 3:00 PM, Prateek Mishra wrote: > Thanks for the clarification (Paul, Chuck and Brian), re-reading the most > recent draft makes the use-case pretty clear, not sure how I came up with my > own personal use-case in this instance (not enough coffee probably...) If you think there's anything that could be added or removed to make it more clear, please let me know and I'll try and incorporate it. > To me it seems that this is an instance of a SAML --> OAuth token mapping > service, which seems a pretty useful service. One question is whether there > needs to be a general framework for its use; I guess this was the substance > of interaction between Brian and Tony earlier in the thread. I guess I need > to research the issue some more before joining that discussion. I'm not sure there was that much substance to Tony and I's interaction - we were just discussing the merits of allowing for more than one assertion in this profile. I guess that does generalize it somewhat but I don't know that it makes it a 'general framework its use.' Honestly, I'm not even sure what that would involve. To some extent, the assertion grant type in OAuth is the general framework for exchanging a token/assertion for a OAuth access token. And, as you point out, this profile is an instance of that that does SAML --> OAuth. Do you think there needs to be something more generalized somewhere? > Here is a simpler question: is there a requirement that the Client/IdP > authenticate to the Authorization server when presenting the SAML bearer > token? I didnt see it in the current draft - or is that taken care of in the > base OAuth 2.0 protocol? Client authentication is in the core OAuth spec but it is optional. So I'd imagine it will end up as a policy decision at deployment time. From eran@hueniverse.com Thu Aug 5 08:39:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C784F3A69F9 for ; Thu, 5 Aug 2010 08:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9kjFPMbWzSf for ; Thu, 5 Aug 2010 08:39:44 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 3ED703A69A9 for ; Thu, 5 Aug 2010 08:39:43 -0700 (PDT) Received: (qmail 16112 invoked from network); 5 Aug 2010 15:40:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 5 Aug 2010 15:40:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 5 Aug 2010 08:40:01 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Thu, 5 Aug 2010 08:39:12 -0700 Thread-Topic: [OAUTH-WG] Extensibility: new endpoints Thread-Index: Acs0tHcfpp6aDCmSQSadXKn8pWgF9Q== Message-ID: <359DBA78-9AA5-4D1E-A9DF-62EE52832B34@hueniverse.com> References: <4C57224C.5000401@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5BF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C572562.8050003@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C57287C.1090105@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A5E2@P3PW5EX1MB01.EX1.SECURESERVER.NET> <69C1E085-F8EB-494C-9BB7-DDE48488A202@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A74E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3F03A764@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C599DBA.5070407@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F03AC54@P3PW5EX1MB01.EX1.SECURESERVER.NET> <949D90AE-FFC9-485C-A382-E7F9A173E883@lodderstedt.net> In-Reply-To: <949D90AE-FFC9-485C-A382-E7F9A173E883@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] Extensibility: new endpoints X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 15:39:45 -0000 Didn't take it as criticism. I just like to be done.=20 EHL On Aug 5, 2010, at 1:08, Torsten Lodderstedt wrot= e: >=20 >=20 >=20 >=20 > Am 05.08.2010 um 00:45 schrieb Eran Hammer-Lahav : >=20 >> I hope to have some discovery draft to share shortly after the next core= draft. It would be very much in line with the discovery stuff from previou= s core drafts before I took it out (-05). >>=20 >> As for WG process/focus, that's the job of the chairs to figure out. I h= ave no intention of drafting or editing any additional specs beyond core an= d discovery. >>=20 >> The only practical approach I have found is to simply ask people to expr= ess their views and request in the form of feedback for the latest draft. I= f you think something is missing or needs to change, the way to address it = is as feedback. >>=20 >> I will add or change the spec based on my best sense of WG consensus sin= ce that's all I have to work with. If you don't like this, please talk to t= he chairs. >>=20 >=20 > I didn't intend to criticize you, I think you do a terrible good job as a= n editor. I just offered my opinion of why this WG is not as focused as you= would expect it. >=20 > regards, > Torsten. >=20 >=20 >> EHL >>=20 >>> -----Original Message----- >>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>> Sent: Wednesday, August 04, 2010 10:05 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG (oauth@ietf.org); Brian Eaton >>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>>=20 >>>>=20 >>>>> ideas. I still hope to get the discovery spec finished in the same >>>>> timeframe, but have no plans to author or edit any other draft. >>>>>=20 >>>>> Just to get this clear. Do you plan to author the discovery spec? And >>>>> what is the core spec's timeframe? >>>>>=20 >>>> I have started to write the discovery spec, but work on the core spec = has >>> taken most of my free time to do this (OAuth is not part of my day job)= . >>>>=20 >>>=20 >>> The same holds for me :-) Would you mind to share your thoughts regardi= ng >>> discovery with the group. I especially would like to know, whether you = agree >>> with the requirements I described in "OAuth Discovery Requirements" and >>> how they can be met. >>>=20 >>>> I have no idea what's the timeframe for the core spec. This groups isn= 't >>> very good at providing timely feedback and staying focused. >>>=20 >>> Good point. What might be the reasons for the missing focus? In my opin= ion, >>> there are a couple of. >>>=20 >>> First of all, what is the "thing" we shall be focusing on? That's not c= lear to me >>> (probably also to others). I therefore asked for your plans to include = several >>> aspects in the core spec. Moreover, it's also not clear to me what >>> complementary specs and sub-sequent versions of the core spec the WG wi= ll >>> produce in the future. As an effect, everyone is afraid that his/her ow= n ideas >>> are not being considered and focuses on advocating them. If we find a W= G >>> consensus on the core spec or "first stage" and also the additional WG = items, >>> work will probably become more focused. My impression after attending >>> IETF 78 is, bringing the core spec through the IETF approval process wi= ll be >>> hard enough! >>>=20 >>> Additionally, I think the WG lacks consensus on what OAuth 2.0 should b= e, >>> especially regarding fundamental architectural questions and there >>> consequences! Just to list a few: >>> - supported use cases and client types (there is more than web clients = :-)) >>> - number of resource servers an authorization can handle (1:1 vs. 1:n) >>> (resource server specific tokens + resource server addressing) >>> - supported token types (self-contained vs. artifacts vs. session ids) >>> - usage of scopes (resources vs. resource server vs. permissions vs. >>> duration vs. ...) >>> - role of signatures (none, authentication, prove of posession, message >>> integrity, ...) + key management approaches >>> - security level (none, relaxed, state-of-the-art, paranoid), probably = there is >>> a need for different OAuth security profiles >>>=20 >>> This not only results in a spec difficult to understand for an "outside= r". It also >>> causes endless discussions around those or derived topics. >>>=20 >>>> So far no one has offered to work on the security consideration sectio= n >>> (Brian's draft is too far from the format I need to incorporate). >>>>=20 >>>=20 >>> I could work on this topic, if Brian does not insist to do so. >>> @Brian: What do you think? >>>=20 >>> From my point of view, the security considerations could be worked out = on a >>> per flow/profile base by multiple contributers (anyone interested?). At= least >>> we should agree on a common set of threat agents and a template. >>>=20 >>>> I am planning the next draft for early September which will include th= e few >>> changes raised on the list, but will focus on finding a middle ground b= etween >>> detailed profiles and a generic architecture (editorial work). >>>>=20 >>>=20 >>> Good luck! >>>=20 >>> regards, >>> Torsten. >>>=20 >>>> EHL >>>>=20 >>>>=20 >>>>>>> What about the following topics? >>>>>>> - security considerations >>>>>>>=20 >>>>>> That's part of core and someone has to write it. I'd like to see >>>>>> someone >>>>>>=20 >>>>> take the security section from RFC 5849 and rework it to match 2.0, >>>>> as well as add everything that is missing. I will incorporate it and >>>>> take care of the editorial work but I am not writing it from scratch. >>>>>=20 >>>>>>=20 >>>>>>> - token revocation (requested by several attendees during >>>>>>> Maastricht WG meeting) >>>>>>>=20 >>>>>> Someone needs to write a proposal and work to get WG consensus (to >>>>>> the >>>>>>=20 >>>>> point where enough people say they like it and no one is objecting). >>>>> Get it there, I'll do the rest. Feel free to ask the chairs to help o= ut. >>>>>=20 >>>>>>=20 >>>>>>> - signatures >>>>>>>=20 >>>>>> I think Nat offered to take a stab at a first draft based on Dirk's >>>>>> work and >>>>>>=20 >>>>> the WG discussions. I have offered to help with editorial work if >>> requested. >>>>>=20 >>>>>> EHL >>>>>>=20 >>>>>>=20 >>>>>>> regards, >>>>>>> Torsten. >>>>>>>=20 >>>>>>>=20 >>>>>>> Am 02.08.2010 um 22:33 schrieb Eran Hammer-Lahav >>>>>>> : >>>>>>> General discussions on the list and during the interim meeting. >>>>>>>=20 >>>>>>> EHL >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>>>>>> Sent: Monday, August 02, 2010 1:20 PM >>>>>>> To: Eran Hammer-Lahav >>>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>>>>>>=20 >>>>>>> What consensus do you refer to? The WG charter? >>>>>>>=20 >>>>>>> regards, >>>>>>> Torsten. >>>>>>>=20 >>>>>>> Am 02.08.2010 22:18, schrieb Eran Hammer-Lahav: >>>>>>> No according to WG consensus. We took it all out because too many >>>>>>> people considered it experimental, so while it may be a WG item, it >>>>>>> is not part of the core spes. >>>>>>>=20 >>>>>>> EHL >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >>>>>>> Sent: Monday, August 02, 2010 1:07 PM >>>>>>> To: Eran Hammer-Lahav >>>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>>> Subject: Re: [OAUTH-WG] Extensibility: new endpoints >>>>>>>=20 >>>>>>> and discovery does not belong into the core? >>>>>>>=20 >>>>>>> regards, >>>>>>> Torsten. >>>>>>>=20 >>>>>>> Am 02.08.2010 22:05, schrieb Eran Hammer-Lahav: >>>>>>>=20 >>>>>>> This doesn't belong in core. A registry is used to avoid name >>>>>>> collisions, not >>>>>>>=20 >>>>>>> to provide an inventory. >>>>>>>=20 >>>>>>> Maybe in discovery. >>>>>>>=20 >>>>>>> EHL >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>>> Behalf Of Torsten Lodderstedt >>>>>>> Sent: Monday, August 02, 2010 12:54 PM >>>>>>> To: OAuth WG (oauth@ietf.org) >>>>>>> Subject: [OAUTH-WG] Extensibility: new endpoints >>>>>>>=20 >>>>>>> the existing authorization server endpoints (end-user authorization >>>>>>> and tokens endpoint) have a relatively clearly semantics and scope. >>>>>>> Adding distinct new functions to an authorization server will (in >>>>>>> my >>>>>>> opionion) require the definition of new endpoints. For example, I'm >>>>>>> working on an I-D for token revocation. Such a function does not >>>>>>> fit into the tokens endpoint since it has become a "token issuance >>>>>>> endpoint" rather than a general purpose client2server endpoint. >>>>>>>=20 >>>>>>> I therefore would propose to include the option to define and >>>>>>> register new endpoints into the Extensibility section of the spec. >>>>>>> This would also facilitate the incorporation of additional >>>>>>> endpoints (with well- defined names) into OAuth discovery. >>>>>>>=20 >>>>>>> Any thoughts? >>>>>>>=20 >>>>>>> regards, >>>>>>> Torsten. >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> OAuth@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>=20 From ynir@checkpoint.com Sun Aug 8 01:09:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F943A6358 for ; Sun, 8 Aug 2010 01:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=-1.346, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKv7YRwv5xAy for ; Sun, 8 Aug 2010 01:09:17 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id DD2EC3A6946 for ; Sun, 8 Aug 2010 01:09:16 -0700 (PDT) X-CheckPoint: {4C5E7189-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o7889bDr003212; Sun, 8 Aug 2010 11:09:37 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 8 Aug 2010 11:10:07 +0300 From: Yoav Nir To: Brian Eaton Date: Sun, 8 Aug 2010 11:10:07 +0300 Thread-Topic: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? Thread-Index: Acs20Rz4pxgaw3QfSb28UgMHMJfgvQ== Message-ID: <425A6479-6994-4F26-A5D3-622FA47FFB41@checkpoint.com> References: <583401.18530.qm@web37601.mail.mud.yahoo.com> <635529.20547.qm@web37602.mail.mud.yahoo.com> <204869.37310.qm@web37602.mail.mud.yahoo.com> <983904.30885.qm@web37607.mail.mud.yahoo.com> <5B1DD06D-DF6E-4F51-8BF8-A59EDE31E0DB@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Oleg Gryb , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Is User Agent Profile Secure in OAuth 2.0? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 08:09:18 -0000 Looks good, except for two things. - The user agent profile, that is the subject of this thread is not there. - I'm missing the part about what we need to trust each party to do. For ex= ample, we trust thirdparty.com to provide a javascript that only sends the = token to the resource provider, not to any other party, and not even to thi= rdparty.com itself. There's the whole question of who I trust to keep my passwords safe, who I = trust with temporary access to a resource, and who I trust with long-term a= ccess to a resource. On Aug 3, 2010, at 11:45 PM, Brian Eaton wrote: > Yoav - >=20 > You can take a look at this as a starting point: >=20 > http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityCons= iderations/OAuthWRAP2.0SecurityConsiderations.pdf >=20 > On Tue, Aug 3, 2010 at 1:38 PM, Marius Scurtescu = wrote: >> On Tue, Aug 3, 2010 at 1:28 PM, Yoav Nir wrote: >>>=20 >>> On Aug 3, 2010, at 11:18 PM, Marius Scurtescu wrote: >>>=20 >>>> On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir wrote: >>>>>=20 >>>>> On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote: >>>>>=20 >>>>> Please provide an example of code that you would put to thirdparty.co= m and >>>>> that >>>>>=20 >>>>> would not break the use cases. >>>>>=20 >>>>> Take a look at the facebook APIs, in particular the cross-domain >>>>> communication schemes: >>>>>=20 >>>>> http://wiki.developers.facebook.com/index.php/Cross_Domain_Communicat= ion_Channel >>>>>=20 >>>>> Please also provide an example of response from >>>>>=20 >>>>> serviceprovider.com with an access token in it (wherever it is - as I >>>>> understand >>>>>=20 >>>>> you want to put it to the Location header, but probably I'm wrong). >>>>>=20 >>>>> HTTP/1.1 302 Moved Temporarily >>>>>=20 >>>>> Location: http://www.thirdparty.com/rpc_relay.html#access_token=3D123= 45 >>>>>=20 >>>>> rpc_relay.html is highly cached in the browser, so instead of >>>>> incurring hundreds of ms to fetch a file, the data lands in the >>>>> third-party.com javascript in under a millisecond. >>>>>=20 >>>>> So if the browser works correctly (instead of what the python library= does, >>>>> then thirdparty.com sees only "GET rpc_relay.html", while the javascr= ipt >>>>> also gets the "access_token=3D12345". >>>>> What I'm not getting is why this matters. Is this supposed to be abou= t >>>>> security? It can't be any good at that, because the javascript is co= ming >>>>> from thirdparty.com. If the good people at thirdparty.com want to kno= w the >>>>> access token, they can make their javascript send it to them. So wha= t is >>>>> the purpose of this funky use of HTTP? Is the access token a secret? = From >>>>> who? >>>>=20 >>>> Passing the access toke through the URL is insecure and prone to >>>> leaking. >>>=20 >>> Insecure against what? Prone to leaking of what to whom? >>>=20 >>>> If in the query string then the access token my leak through: >>>> - log files, web server at thirdparty.com and any number of proxies >>>> - browser history >>>> - referer header >>>=20 >>> You're counting a lot on the javascript. That Javascript is coming from= thirdparty.com. So we have to assume both trustworthiness and competence o= f the people in thirdparty. >>=20 >> Yes, definitely, thirdparty.com must be trusted, it is the client that >> the end user is authorizing. >>=20 >>=20 >>>> Putting the access token into the fragment, and also using JavaScript >>>> to clean the URL as soon as the token is extracted, mitigates most of >>>> these issues. >>>=20 >>> I think a security considerations section (different for each profile) = is desperately needed. >>=20 >> True. >>=20 >>=20 >> Marius >>=20 >=20 > Scanned by Check Point Total Security Gateway. From bcampbell@pingidentity.com Mon Aug 9 09:30:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B883A6B03 for ; Mon, 9 Aug 2010 09:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.047 X-Spam-Level: X-Spam-Status: No, score=-5.047 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyTtMrbdlztb for ; Mon, 9 Aug 2010 09:30:18 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id 244E43A6AFD for ; Mon, 9 Aug 2010 09:30:17 -0700 (PDT) Received: from source ([74.125.82.175]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTGAtN0/OSMWBt8Lbb9GaZ41JFFcLldH2@postini.com; Mon, 09 Aug 2010 09:30:53 PDT Received: by wyb38 with SMTP id 38so10831127wyb.20 for ; Mon, 09 Aug 2010 09:30:46 -0700 (PDT) Received: by 10.216.179.137 with SMTP id h9mr8068745wem.39.1281371446361; Mon, 09 Aug 2010 09:30:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Mon, 9 Aug 2010 09:30:11 -0700 (PDT) From: Brian Campbell Date: Mon, 9 Aug 2010 10:30:11 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] SAML profile comments/questions from the SAML people X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 16:30:21 -0000 I received some feedback on the SAML profile from a cross posting on the OASIS SSTC (SAML) list. Links to the thread topic index are below[1], if you are interested, but I'll try and summarize the two primary issues here. First, concern was expressed that restricting the assertion to only allow for a single element was too limiting. The restriction basically limits the ability of a single assertion to be issued for use across multiple use-cases/profiles. A good example is the use-case that Prateek recently brought up in a different thread on this list[2] where the assertion is delivered to an SP via Web SSO and then that SP uses that same assertion to acquire an access token for data services at a 3rd party site. As currently written, draft-campbell-oauth-saml-00[3], wouldn't allow for that use-case. I'm starting to think that my attempt at simplification was is indeed too restrictive. Allowing for more than one will make the wording in the profile a bit more complicated (as well as implementing validation) but I think, in the longer term, it's probably the right thing to do from a spec perspective. At this point I'm planning on loosening that restriction in the next draft. I'm curious, however, if anyone has any strong opinions on it one way or the other? The second issue involves my assumption and requirement in the profile that the subject of the assertion be the resource owner. To me, it seemed like a reasonable and useful constraint that was generally inline with the spirit of the assertion flow, however, the comments from Scott (editor of the core SAML specifications) suggest that it's too constraining and/or inappropriate. I'm honestly not sure where to go with this one and am reaching out to this list for ideas/suggestions/opinions. I guess I see where he's coming from but I'm kind of partial to the restriction/guidance as I have it. Also, I'm thinking that perhaps the counter example cases he describes would be better captured by use of the "none" access grant type and a client assertion (coming in draft -11, I think?). Thanks, Brian C [1] Discussion Thread on SSTC list http://lists.oasis-open.org/archives/security-services/201008/threads.html#00000 http://lists.oasis-open.org/archives/security-services/201007/threads.html#00034 [2] Discussion Thread with use-case on OAuth list http://www.ietf.org/mail-archive/web/oauth/current/msg04118.html [3] draft-campbell-oauth-saml-00 / SAML 2.0 Bearer Assertion Profile for OAuth 2.0 http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt From recordond@gmail.com Mon Aug 9 11:32:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2540D3A67B3 for ; Mon, 9 Aug 2010 11:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2cPgYfUHdwc for ; Mon, 9 Aug 2010 11:32:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A06C33A6896 for ; Mon, 9 Aug 2010 11:32:19 -0700 (PDT) Received: by ywa8 with SMTP id 8so4248931ywa.31 for ; Mon, 09 Aug 2010 11:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9v1hsb8Bxfr9v/hhoHlXviToj+n6No27+AF8yzVgq+Q=; b=UPuOkpbQqjBRIyZe1Rku1IQ9ua4DIPX1AK4hLZB602Ohnuf7xpEftQ5F9HNMSCsBQN 5+yRlvW5ywDRQ+9VnyysNEP/jdPTMGhypqzPOLaZ0JDhnpCpWBgY/arBJ52F+b0w/OJW QkdlNSR6kk1fRTB5LpRcEAqTc8fr9U4xepN2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N97J00t05b2/IQkvr13LcSZGxzkLocMUzbiNjfMlYhJCgR2U6w9BxTySJx0+vbkMjh bwtxn45smj/bWdtl0rAaP06FFiGCIMz/kmBbooDM78XMLtW6lewHeMeRMqbB0QH4Nfos AUHLUx5DACjohgXKCQkTYudv7zMJl3Ruf4r20= MIME-Version: 1.0 Received: by 10.101.143.38 with SMTP id v38mr18268779ann.56.1281378773825; Mon, 09 Aug 2010 11:32:53 -0700 (PDT) Received: by 10.101.46.2 with HTTP; Mon, 9 Aug 2010 11:32:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Aug 2010 11:32:53 -0700 Message-ID: From: David Recordon To: Eran Hammer-Lahav , Brian Eaton , Naitik Shah , Luke Shepard Content-Type: multipart/alternative; boundary=0016e6d278e4a2fa5a048d683ea6 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:32:26 -0000 --0016e6d278e4a2fa5a048d683ea6 Content-Type: text/plain; charset=ISO-8859-1 The thread wondered a bit but Brian's summary here seems to be what most people were advocating for. Is there enough consensus to have Draft 11 reflect it? Thanks, --David On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton wrote: > I can't parse this diagam, but here's my take: > > - web server flow should always return just a code. > parameter always goes in the query string > it would be sort of reasonable to have the code exchange return > just an access token, instead of a refresh token and an access token. > Or a refresh token with a shorter lifetime than indefinite. > > - user-agent flow can reasonably return either just a token, or a > token and a code > both parameters always go in the fragment, to avoid busting the browser > cache > same comments about lifetime of refresh tokens... > > Cheers, > Brian > > On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav > wrote: > > Please answer this based on actual use cases. When returning parameters > > using the redirection URI call, which of these combinations make sense? > > > > | Code | Token | Code & Token > > ---------+------+-------+-------------- > > Fragment | a | 1 | 3 > > Query | 2 | b | c > > Split* | n/a | n/a | d > > > > * token in fragment, code in query > > > > Known use cases: > > > > 1 - current user-agent flow > > 2 - current web-server flow > > 3 - as described by Brian and Naitik > > > > Do you need any of these? > > > > a - > > b - > > c - > > d - current -10 code-and-token proposal > > > > EHL > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0016e6d278e4a2fa5a048d683ea6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The thread wondered a bit but Brian's summary here seems to be what mos= t people were advocating for. Is there enough consensus to have Draft 11 re= flect it?

Thanks,
--David


On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton <beaton@google.com<= /a>> wrote:
I can't parse this diagam, but here's my take:

- web server flow should always return just a code.
=A0 parameter always goes in the query string
=A0 it would be sort of reasonable to have the code exchange return
just an access token, instead of a refresh token and an access token.
Or a refresh token with a shorter lifetime than indefinite.

- user-agent flow can reasonably return either just a token, or a
token and a code
=A0 both parameters always go in the fragment, to avoid busting the browse= r cache
=A0 same comments about lifetime of refresh tokens...

Cheers,
Brian

On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Please answer this based on actual use cases. When returning parameter= s
> using the redirection URI call, which of these combinations make sense= ?
>
> =A0 =A0 =A0 =A0 | Code | Token | Code & Token
> ---------+------+-------+--------------
> Fragment | =A0a =A0 | =A0 1 =A0 | =A0 3
> Query =A0 =A0| =A02 =A0 | =A0 b =A0 | =A0 c
> Split* =A0 | n/a =A0| =A0n/a =A0| =A0 d
>
> * token in fragment, code in query
>
> Known use cases:
>
> 1 - current user-agent flow
> 2 - current web-server flow
> 3 - as described by Brian and Naitik
>
> Do you need any of these?
>
> a -
> b -
> c -
> d - current -10 code-and-token proposal
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0016e6d278e4a2fa5a048d683ea6-- From recordond@gmail.com Mon Aug 9 11:40:34 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2AE93A6B2E for ; Mon, 9 Aug 2010 11:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtvPWRJrB+4o for ; Mon, 9 Aug 2010 11:40:33 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 9F5303A69D1 for ; Mon, 9 Aug 2010 11:40:33 -0700 (PDT) Received: by ywa8 with SMTP id 8so4252686ywa.31 for ; Mon, 09 Aug 2010 11:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=6Ynzv5pdd8KYfIjuuH6CFj1B16l1+V+RdPMqTwO64F8=; b=HH/JUHNQzMCEJZTT6FQ2+JeRpvOfJnWt6FShtkQLx8o1tJTsTlqDy4/jzXbaINr7Ph PHkKXkcvRfl7inLB266FYfQpGzwzpuWiFbdtXc5uJVP0TDS+TKS6ZJyPQbsnAy+KyPDW pFKGNu4gcRrZOSgz1zxUa2/GxQMRLE6AxYXwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kY8ugazAhrJow/4jIq5Vx7EhTmRlFiZk0HcaykzFRjqBYmJ24BTNqUj6zc5eAgedLe pDL/PheY+Q4j4kx3eGvt2mM5k7G2VD107GQTjmX01+speIriQ7O6yC6oOeSBiVQEaklb E4aE9mGWn5ARlLsU+CvGj4o1VGLg9PvbiDz+c= MIME-Version: 1.0 Received: by 10.100.49.28 with SMTP id w28mr18290385anw.75.1281379267870; Mon, 09 Aug 2010 11:41:07 -0700 (PDT) Received: by 10.101.46.2 with HTTP; Mon, 9 Aug 2010 11:41:07 -0700 (PDT) Date: Mon, 9 Aug 2010 11:41:07 -0700 Message-ID: From: David Recordon To: OAuth WG Content-Type: multipart/alternative; boundary=0016e6471ada157f2d048d685c5d Subject: [OAUTH-WG] Gowalla ships an API using Draft 8 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 18:40:35 -0000 --0016e6471ada157f2d048d685c5d Content-Type: text/plain; charset=ISO-8859-1 http://gowalla.com/api/docs/oauth --0016e6471ada157f2d048d685c5d Content-Type: text/html; charset=ISO-8859-1 http://gowalla.com/api/docs/oauth --0016e6471ada157f2d048d685c5d-- From bcampbell@pingidentity.com Mon Aug 9 12:33:50 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 351153A69C0 for ; Mon, 9 Aug 2010 12:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.752 X-Spam-Level: X-Spam-Status: No, score=-4.752 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhpu7YlwGXdL for ; Mon, 9 Aug 2010 12:33:48 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id 792E53A6B21 for ; Mon, 9 Aug 2010 12:33:48 -0700 (PDT) Received: from source ([209.85.210.52]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTGBYPnJjRSb1xM6q8qwq8KPLmRxwOg3Y@postini.com; Mon, 09 Aug 2010 12:34:23 PDT Received: by pzk27 with SMTP id 27so6166944pzk.11 for ; Mon, 09 Aug 2010 12:34:22 -0700 (PDT) Received: by 10.114.132.18 with SMTP id f18mr19080037wad.97.1281382461385; Mon, 09 Aug 2010 12:34:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.152.16 with HTTP; Mon, 9 Aug 2010 12:33:51 -0700 (PDT) From: Brian Campbell Date: Mon, 9 Aug 2010 13:33:51 -0600 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 19:33:50 -0000 The question of allowing for multiple assertions in the SAML profile came up recently. See http://www.ietf.org/mail-archive/web/oauth/current/msg04068.html and several subsequent messages in the thread. I pushed back on the idea at first due to added complexity. There are a number of things that need to be addressed that aren't present in the single assertion case. One of the sticker ones, to me, was how to encode the assertions into the request. A SAML element is a nice container for multiple assertions but using it in this context seemed awkward at best. A new schema could be defined or a special deliminator character could be used but that seems excessive and kludgy respectively. What about pushing it up into the HTTP layer and allowing for multiple occurrences of the assertion=XXX parameter in the POST body? I don't see anything in core OAuth that would necessarily preclude doing this. It seems cleaner and more lightweight than some of the other options. And perhaps it could be a more general (not just SAML) method of sending multiple assertions in a single assertion grant type request? It'd look something like this: POST /token.oauth2 HTTP/1.1 Host: authz.example.net Content-Type: application/x-www-form-urlencoded grant_type=assertion&assertion_type=http%3A%2F%2Foauth.net%2Fasse rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=[...1st assertion...]&assertion= [...2nd assertion...]&assertion=[...3nd assertion...] From lshepard@facebook.com Mon Aug 9 12:59:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4856B3A6872 for ; Mon, 9 Aug 2010 12:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.23 X-Spam-Level: X-Spam-Status: No, score=-102.23 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTlsC24N73sH for ; Mon, 9 Aug 2010 12:59:07 -0700 (PDT) Received: from mx-out.facebook.com (outmail013.snc1.tfbnw.net [69.63.178.172]) by core3.amsl.com (Postfix) with ESMTP id 48F6E3A6842 for ; Mon, 9 Aug 2010 12:59:07 -0700 (PDT) Received: from [10.18.255.131] ([10.18.255.131:11727] helo=mail.thefacebook.com) by mta022.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 52/86-08737-B2E506C4; Mon, 09 Aug 2010 12:59:39 -0700 Received: from SC-MBX05.TheFacebook.com ([169.254.4.91]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Mon, 9 Aug 2010 12:59:38 -0700 From: Luke Shepard To: David Recordon Thread-Topic: [OAUTH-WG] Quick survey: fragment vs. query Thread-Index: AQHLI3bDAITbPXwcLEeVdwj3462ZcJLaEPmAgAAYU4A= Date: Mon, 9 Aug 2010 19:59:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A285138C374747019BC3F4986E1A99BCfacebookcom_" MIME-Version: 1.0 Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 19:59:08 -0000 --_000_A285138C374747019BC3F4986E1A99BCfacebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like Brian's solution. On Aug 9, 2010, at 11:32 AM, David Recordon wrote: The thread wondered a bit but Brian's summary here seems to be what most pe= ople were advocating for. Is there enough consensus to have Draft 11 reflec= t it? Thanks, --David On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton > wrote: I can't parse this diagam, but here's my take: - web server flow should always return just a code. parameter always goes in the query string it would be sort of reasonable to have the code exchange return just an access token, instead of a refresh token and an access token. Or a refresh token with a shorter lifetime than indefinite. - user-agent flow can reasonably return either just a token, or a token and a code both parameters always go in the fragment, to avoid busting the browser c= ache same comments about lifetime of refresh tokens... Cheers, Brian On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav > wrote: > Please answer this based on actual use cases. When returning parameters > using the redirection URI call, which of these combinations make sense? > > | Code | Token | Code & Token > ---------+------+-------+-------------- > Fragment | a | 1 | 3 > Query | 2 | b | c > Split* | n/a | n/a | d > > * token in fragment, code in query > > Known use cases: > > 1 - current user-agent flow > 2 - current web-server flow > 3 - as described by Brian and Naitik > > Do you need any of these? > > a - > b - > c - > d - current -10 code-and-token proposal > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_A285138C374747019BC3F4986E1A99BCfacebookcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1432f1fb-009f-458f-8170-5034613b19d3> Content-Transfer-Encoding: quoted-printable I like Brian's solution.

On Aug 9, 2010, at 11:32 AM, David Recordon wrote:

The thread wondered a = bit but Brian's summary here seems to be what most people were advocating f= or. Is there enough consensus to have Draft 11 reflect it?

Thanks,
--David


On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton <beaton@google.com<= /a>> wrote:
I can't parse this diagam, but here's my take:

- web server flow should always return just a code.
  parameter always goes in the query string
  it would be sort of reasonable to have the code exchange return
just an access token, instead of a refresh token and an access token.
Or a refresh token with a shorter lifetime than indefinite.

- user-agent flow can reasonably return either just a token, or a
token and a code
  both parameters always go in the fragment, to avoid busting the bro= wser cache
  same comments about lifetime of refresh tokens...

Cheers,
Brian

On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Please answer this based on actual use cases. When returning parameter= s
> using the redirection URI call, which of these combinations make sense= ?
>
>         | Code | Token | Code & Token
> ---------+------+-------+--------------
> Fragment |  a   |   1   |   3
> Query    |  2   |   b   |   c
> Split*   | n/a  |  n/a  |   d
>
> * token in fragment, code in query
>
> Known use cases:
>
> 1 - current user-agent flow
> 2 - current web-server flow
> 3 - as described by Brian and Naitik
>
> Do you need any of these?
>
> a -
> b -
> c -
> d - current -10 code-and-token proposal
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


= --_000_A285138C374747019BC3F4986E1A99BCfacebookcom_-- From yarong@microsoft.com Mon Aug 9 14:15:11 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26CA3A69B8 for ; Mon, 9 Aug 2010 14:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYN4pDR0rxgg for ; Mon, 9 Aug 2010 14:15:09 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 44A483A6969 for ; Mon, 9 Aug 2010 14:15:09 -0700 (PDT) Received: from TK5EX14CASC132.redmond.corp.microsoft.com (157.54.52.17) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 Aug 2010 14:15:43 -0700 Received: from TK5EX14MBXC115.redmond.corp.microsoft.com ([169.254.4.167]) by TK5EX14CASC132.redmond.corp.microsoft.com ([157.54.52.17]) with mapi id 14.01.0218.010; Mon, 9 Aug 2010 14:15:41 -0700 From: Yaron Goland To: Eran Hammer-Lahav , Brian Campbell , oauth Thread-Topic: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions Thread-Index: AQHLLaFrKvkKC0RiQEq67TG16TjkBJLZtKvg Date: Mon, 9 Aug 2010 21:15:41 +0000 Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C62A62B83@TK5EX14MBXC115.redmond.corp.microsoft.com> References: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EF900AE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EF90102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EF901EC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3EF901EC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 21:15:11 -0000 So how do we resolve if the language goes into the spec? Thanks, Yaron > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, July 27, 2010 8:36 AM > To: Brian Campbell; oauth > Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client > Assertions >=20 > Makes sense. Personally, I don't have any preference on including it or n= ot. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Brian Campbell > > Sent: Tuesday, July 27, 2010 5:49 AM > > To: oauth > > Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client > > Assertions > > > > A client_id parameter would still be presented in the end user > > authorization request. The text Brian E. quoted is what mandates any > > specifications/documents/agreements that define how to use client > > assertions must also define the association between the client_id and > > some > > field(s) in the assertion. > > > > If someone sees a cleaner way to deal with client identity on the user > > authorization request when using assertions to authenticate the client > > to the token endpoint, please speak up and lets discuss it. However, > > in general I do feel it's important to have better defined support in > > the core OAuth spec to allow for client authentication methods beyond > > just password. > > > > -Brian > > > > On Mon, Jul 26, 2010 at 5:18 PM, Brian Eaton wrote: > > > On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav > > wrote: > > >> How do you link the client_id using in the authorization endpoint > > >> with the > > client assertion using in the token endpoint? > > > > > > In theory: > > > > > > "any document that defines how to use an assertion of a particular > > > type with OAuth 2.0 MUST define how to map the value from the > > > client_id parameter in the authorization request to a value or > > > values in the assertion subsequently submitted with the code to > > > obtain an access token." > > > > > > In practice: you do it the same way you handle any kind of identity > > > assertion. =A0There is some combination of issuer and subject and > > > signature that ends up producing an identity that you trust. > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From naitik@facebook.com Mon Aug 9 13:01:02 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C70F3A69B8 for ; Mon, 9 Aug 2010 13:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.401 X-Spam-Level: X-Spam-Status: No, score=-102.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WolWQvwD-Vz0 for ; Mon, 9 Aug 2010 13:01:01 -0700 (PDT) Received: from mx-out.facebook.com (outmail004.snc1.tfbnw.net [69.63.178.163]) by core3.amsl.com (Postfix) with ESMTP id 5DD953A6982 for ; Mon, 9 Aug 2010 13:01:01 -0700 (PDT) Received: from [10.18.255.134] ([10.18.255.134:22431] helo=mail.thefacebook.com) by mta003.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id BE/C8-19885-F9E506C4; Mon, 09 Aug 2010 13:01:35 -0700 Received: from SC-MBX05.TheFacebook.com ([169.254.4.91]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Mon, 9 Aug 2010 13:00:22 -0700 From: Naitik Shah To: Luke Shepard Thread-Topic: [OAUTH-WG] Quick survey: fragment vs. query Thread-Index: AQHLN/FIrhpmvVB2L0uRkfTCOLcEl5LaAFeAgAAAHgA= Date: Mon, 9 Aug 2010 20:00:22 +0000 Message-ID: <6EE5F91A-42A0-41F1-B40D-313370C1807E@facebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <350b7de2-f44e-4046-9eee-6f802fa6d9c7> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Aug 2010 15:12:15 -0700 Cc: OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 20:01:02 -0000 me too On Aug 9, 2010, at 12:59 PM, Luke Shepard wrote: > I like Brian's solution. >=20 > On Aug 9, 2010, at 11:32 AM, David Recordon wrote: >=20 >> The thread wondered a bit but Brian's summary here seems to be what most= people were advocating for. Is there enough consensus to have Draft 11 ref= lect it? >>=20 >> Thanks, >> --David >>=20 >>=20 >> On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton wrote: >> I can't parse this diagam, but here's my take: >>=20 >> - web server flow should always return just a code. >> parameter always goes in the query string >> it would be sort of reasonable to have the code exchange return >> just an access token, instead of a refresh token and an access token. >> Or a refresh token with a shorter lifetime than indefinite. >>=20 >> - user-agent flow can reasonably return either just a token, or a >> token and a code >> both parameters always go in the fragment, to avoid busting the browse= r cache >> same comments about lifetime of refresh tokens... >>=20 >> Cheers, >> Brian >>=20 >> On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav = wrote: >> > Please answer this based on actual use cases. When returning parameter= s >> > using the redirection URI call, which of these combinations make sense= ? >> > >> > | Code | Token | Code & Token >> > ---------+------+-------+-------------- >> > Fragment | a | 1 | 3 >> > Query | 2 | b | c >> > Split* | n/a | n/a | d >> > >> > * token in fragment, code in query >> > >> > Known use cases: >> > >> > 1 - current user-agent flow >> > 2 - current web-server flow >> > 3 - as described by Brian and Naitik >> > >> > Do you need any of these? >> > >> > a - >> > b - >> > c - >> > d - current -10 code-and-token proposal >> > >> > EHL >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From eran@hueniverse.com Mon Aug 9 21:43:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52BF23A6849 for ; Mon, 9 Aug 2010 21:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZYAgTzoivCF for ; Mon, 9 Aug 2010 21:43:17 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 64DDD3A67B8 for ; Mon, 9 Aug 2010 21:43:16 -0700 (PDT) Received: (qmail 4401 invoked from network); 10 Aug 2010 04:43:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Aug 2010 04:43:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 9 Aug 2010 21:43:50 -0700 From: Eran Hammer-Lahav To: Brian Campbell , oauth Date: Mon, 9 Aug 2010 21:43:55 -0700 Thread-Topic: [OAUTH-WG] more than one assertion? Thread-Index: Acs3+emsqaTrzVNxTIWVzQDzqoXRaQATJExA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F1243FB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 04:43:18 -0000 Do we need to clarify 4.3.1 "repeats a parameter" description for "invalid_= request" error code does not preclude parameters from repeating? I'm not su= re. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Campbell > Sent: Monday, August 09, 2010 12:34 PM > To: oauth > Subject: [OAUTH-WG] more than one assertion? >=20 > The question of allowing for multiple assertions in the SAML profile came= up > recently. See http://www.ietf.org/mail- > archive/web/oauth/current/msg04068.html and several subsequent > messages in the thread. >=20 > I pushed back on the idea at first due to added complexity. There are a > number of things that need to be addressed that aren't present in > the single assertion case. One of the sticker ones, to me, was how > to encode the assertions into the request. A SAML element > is a nice container for multiple assertions but using it in this context = seemed > awkward at best. A new schema could be defined or a special deliminator > character could be used but that seems excessive and kludgy respectively. >=20 > What about pushing it up into the HTTP layer and allowing for multiple > occurrences of the assertion=3DXXX parameter in the POST body? I don't s= ee > anything in core OAuth that would necessarily preclude doing this. > It seems cleaner and more lightweight than some of the other options. > And perhaps it could be a more general (not just SAML) method of sending > multiple assertions in a single assertion grant type request? >=20 > It'd look something like this: >=20 > POST /token.oauth2 HTTP/1.1 > Host: authz.example.net > Content-Type: application/x-www-form-urlencoded >=20 > grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%2Fasse > rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st > assertion...]&assertion=3D > [...2nd assertion...]&assertion=3D[...3nd assertion...] > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Aug 9 21:45:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974193A68C0 for ; Mon, 9 Aug 2010 21:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qawhLlDci-p for ; Mon, 9 Aug 2010 21:45:46 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 67FC83A6A1E for ; Mon, 9 Aug 2010 21:45:46 -0700 (PDT) Received: (qmail 22522 invoked from network); 10 Aug 2010 04:46:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Aug 2010 04:46:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 9 Aug 2010 21:46:20 -0700 From: Eran Hammer-Lahav To: Yaron Goland , Brian Campbell , oauth Date: Mon, 9 Aug 2010 21:46:25 -0700 Thread-Topic: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions Thread-Index: AQHLLaFrKvkKC0RiQEq67TG16TjkBJLZtKvggAB91uA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F1243FC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <7C01E631FF4B654FA1E783F1C0265F8C6294F782@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343B3EF900AE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EF90102@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3EF901EC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <7C01E631FF4B654FA1E783F1C0265F8C62A62B83@TK5EX14MBXC115.redmond.corp.microsoft.com> In-Reply-To: <7C01E631FF4B654FA1E783F1C0265F8C62A62B83@TK5EX14MBXC115.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client Assertions X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 04:45:47 -0000 [Seems like the only way is for me to say this] I am going to include this text in -11 unless someone objects (and explains= why). EHL > -----Original Message----- > From: Yaron Goland [mailto:yarong@microsoft.com] > Sent: Monday, August 09, 2010 2:16 PM > To: Eran Hammer-Lahav; Brian Campbell; oauth > Subject: RE: [OAUTH-WG] Proposed language for section 2.2 on Client > Assertions >=20 > So how do we resolve if the language goes into the spec? > Thanks, > Yaron >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Tuesday, July 27, 2010 8:36 AM > > To: Brian Campbell; oauth > > Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client > > Assertions > > > > Makes sense. Personally, I don't have any preference on including it or= not. > > > > EHL > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf Of Brian Campbell > > > Sent: Tuesday, July 27, 2010 5:49 AM > > > To: oauth > > > Subject: Re: [OAUTH-WG] Proposed language for section 2.2 on Client > > > Assertions > > > > > > A client_id parameter would still be presented in the end user > > > authorization request. The text Brian E. quoted is what mandates any > > > specifications/documents/agreements that define how to use client > > > assertions must also define the association between the client_id > > > and some > > > field(s) in the assertion. > > > > > > If someone sees a cleaner way to deal with client identity on the > > > user authorization request when using assertions to authenticate the > client > > > to the token endpoint, please speak up and lets discuss it. However= , > > > in general I do feel it's important to have better defined support > > > in the core OAuth spec to allow for client authentication methods > > > beyond just password. > > > > > > -Brian > > > > > > On Mon, Jul 26, 2010 at 5:18 PM, Brian Eaton > wrote: > > > > On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav > > > wrote: > > > >> How do you link the client_id using in the authorization endpoint > > > >> with the > > > client assertion using in the token endpoint? > > > > > > > > In theory: > > > > > > > > "any document that defines how to use an assertion of a particular > > > > type with OAuth 2.0 MUST define how to map the value from the > > > > client_id parameter in the authorization request to a value or > > > > values in the assertion subsequently submitted with the code to > > > > obtain an access token." > > > > > > > > In practice: you do it the same way you handle any kind of > > > > identity assertion. =A0There is some combination of issuer and > > > > subject and signature that ends up producing an identity that you t= rust. > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Tue Aug 10 05:20:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF413A69B4 for ; Tue, 10 Aug 2010 05:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.818 X-Spam-Level: X-Spam-Status: No, score=-0.818 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpQSOFzgG8Wx for ; Tue, 10 Aug 2010 05:20:21 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id C49CD3A698C for ; Tue, 10 Aug 2010 05:20:20 -0700 (PDT) Received: from [80.187.108.230] (helo=[10.164.59.182]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Oinp3-00007q-Id; Tue, 10 Aug 2010 14:20:53 +0200 References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1-340419414 Message-Id: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Tue, 10 Aug 2010 14:20:03 +0200 To: David Recordon X-Df-Sender: 141509 Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 12:20:25 -0000 --Apple-Mail-1-340419414 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can someone pls. explain why code and token should both be returned in the f= ragment? regards, Torsten. Am 09.08.2010 um 20:32 schrieb David Recordon : > The thread wondered a bit but Brian's summary here seems to be what most p= eople were advocating for. Is there enough consensus to have Draft 11 reflec= t it? >=20 > Thanks, > --David >=20 >=20 > On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton wrote: > I can't parse this diagam, but here's my take: >=20 > - web server flow should always return just a code. > parameter always goes in the query string > it would be sort of reasonable to have the code exchange return > just an access token, instead of a refresh token and an access token. > Or a refresh token with a shorter lifetime than indefinite. >=20 > - user-agent flow can reasonably return either just a token, or a > token and a code > both parameters always go in the fragment, to avoid busting the browser c= ache > same comments about lifetime of refresh tokens... >=20 > Cheers, > Brian >=20 > On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav w= rote: > > Please answer this based on actual use cases. When returning parameters > > using the redirection URI call, which of these combinations make sense? > > > > | Code | Token | Code & Token > > ---------+------+-------+-------------- > > Fragment | a | 1 | 3 > > Query | 2 | b | c > > Split* | n/a | n/a | d > > > > * token in fragment, code in query > > > > Known use cases: > > > > 1 - current user-agent flow > > 2 - current web-server flow > > 3 - as described by Brian and Naitik > > > > Do you need any of these? > > > > a - > > b - > > c - > > d - current -10 code-and-token proposal > > > > EHL > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-1-340419414 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Can someone pls. explain why code and token should both be returned in the fragment?

regards,
Torsten.

Am 09.08.2010 um 20:32 schrieb David Recordon <recordond@gmail.com>:

The thread wondered a bit but Brian's summary here seems to be what most people were advocating for. Is there enough consensus to have Draft 11 reflect it?

Thanks,
--David


On Wed, Jul 14, 2010 at 10:04 AM, Brian Eaton <beaton@google.com> wrote:
I can't parse this diagam, but here's my take:

- web server flow should always return just a code.
  parameter always goes in the query string
  it would be sort of reasonable to have the code exchange return
just an access token, instead of a refresh token and an access token.
Or a refresh token with a shorter lifetime than indefinite.

- user-agent flow can reasonably return either just a token, or a
token and a code
  both parameters always go in the fragment, to avoid busting the browser cache
  same comments about lifetime of refresh tokens...

Cheers,
Brian

On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Please answer this based on actual use cases. When returning parameters
> using the redirection URI call, which of these combinations make sense?
>
>         | Code | Token | Code & Token
> ---------+------+-------+--------------
> Fragment |  a   |   1   |   3
> Query    |  2   |   b   |   c
> Split*   | n/a  |  n/a  |   d
>
> * token in fragment, code in query
>
> Known use cases:
>
> 1 - current user-agent flow
> 2 - current web-server flow
> 3 - as described by Brian and Naitik
>
> Do you need any of these?
>
> a -
> b -
> c -
> d - current -10 code-and-token proposal
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
_______________________________________________
OAuth mailing 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-1-340419414-- From bcampbell@pingidentity.com Tue Aug 10 09:02:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0EE3A695A for ; Tue, 10 Aug 2010 09:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.494 X-Spam-Level: X-Spam-Status: No, score=-5.494 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzfB3OY2w7S7 for ; Tue, 10 Aug 2010 09:02:56 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with SMTP id EAE993A695B for ; Tue, 10 Aug 2010 09:02:55 -0700 (PDT) Received: from source ([74.125.82.174]) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTGF4UhGJg+OafrGws2A71mdolmJxwGrU@postini.com; Tue, 10 Aug 2010 09:03:31 PDT Received: by mail-wy0-f174.google.com with SMTP id 32so1115186wyb.33 for ; Tue, 10 Aug 2010 09:03:30 -0700 (PDT) Received: by 10.216.179.20 with SMTP id g20mr15348941wem.45.1281456209250; Tue, 10 Aug 2010 09:03:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.71.5 with HTTP; Tue, 10 Aug 2010 09:02:56 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F1243FB@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3F1243FB@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Tue, 10 Aug 2010 10:02:56 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:02:57 -0000 To be honest, I somehow overlooked that particular text - my mistake and apologies. Reading it again, it probably does preclude parameters from repeating, however, I can see some room for varied interpretations as to if that's a strong normative requirement or a looser suggestion about an error code that could be used in that circumstance. Perhaps it could be made more clear by adding some wording about it to the end of the first part of sections 3&4 where it says: "Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server SHOULD ignore unrecognized request parameters."? That said, does it make sense to relax the ban on repeating parameters in some situations, like for the assertion parameter, to facilitate easy encoding of multiple assertions? Anthony (Tony?) Nadalin suggested that multiple assertions might be a common use case and I think allowing for that via repeating assertion parameters is a cleaner and more reusable way to do it. The text at the bottom of section for could say something like: "Parameters sent without a value MUST be treated as if they were omitted from the request. The authorization server SHOULD ignore unrecognized request parameters. Parameters MUST NOT repeat unless otherwise noted in the parameter definition." Then in 4.1.3. the assertion parameter could be something like this: "assertion REQUIRED. The assertion(s). This parameter MAY be repeated in the request, if more than one assertion is needed for the access grant" Obviously Eran could improve on the actual text but hopefully that gets the concept across? On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav wr= ote: > Do we need to clarify 4.3.1 "repeats a parameter" description for "invali= d_request" error code does not preclude parameters from repeating? I'm not = sure. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Campbell >> Sent: Monday, August 09, 2010 12:34 PM >> To: oauth >> Subject: [OAUTH-WG] more than one assertion? >> >> The question of allowing for multiple assertions in the SAML profile cam= e up >> recently. =A0See http://www.ietf.org/mail- >> archive/web/oauth/current/msg04068.html and several subsequent >> messages in the thread. >> >> I pushed back on the idea at first due to added complexity. =A0There are= a >> number of things that need to be addressed that aren't present in >> the single assertion case. =A0 One of the sticker ones, to me, was how >> to encode the assertions into the request. =A0 A SAML element >> is a nice container for multiple assertions but using it in this context= seemed >> awkward at best. =A0A new schema could be defined or a special deliminat= or >> character could be used but that seems excessive and kludgy respectively= . >> >> What about pushing it up into the HTTP layer and allowing for multiple >> occurrences of the assertion=3DXXX parameter in the POST body? =A0I don'= t see >> anything in core OAuth that would necessarily preclude doing this. >> =A0It seems cleaner and more lightweight than some of the other options. >> =A0And perhaps it could be a more general (not just SAML) method of send= ing >> multiple assertions in a single assertion grant type request? >> >> It'd look something like this: >> >> =A0 POST /token.oauth2 HTTP/1.1 >> =A0 Host: authz.example.net >> =A0 Content-Type: application/x-www-form-urlencoded >> >> =A0 =A0grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%2F= asse >> =A0 =A0rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st >> assertion...]&assertion=3D >> =A0 =A0[...2nd assertion...]&assertion=3D[...3nd assertion...] >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From eran@hueniverse.com Tue Aug 10 09:14:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041AB3A69A6 for ; Tue, 10 Aug 2010 09:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCmRRM5dZB49 for ; Tue, 10 Aug 2010 09:14:42 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B88D23A699C for ; Tue, 10 Aug 2010 09:14:42 -0700 (PDT) Received: (qmail 15732 invoked from network); 10 Aug 2010 16:15:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Aug 2010 16:15:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 10 Aug 2010 09:15:03 -0700 From: Eran Hammer-Lahav To: Brian Campbell Date: Tue, 10 Aug 2010 09:15:03 -0700 Thread-Topic: [OAUTH-WG] more than one assertion? Thread-Index: Acs4pZWLbX9cjC7QSa2+4aBv+Nh43QAAZixQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3F1243FB@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:14:44 -0000 WFM. > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Tuesday, August 10, 2010 9:03 AM > To: Eran Hammer-Lahav > Cc: oauth > Subject: Re: [OAUTH-WG] more than one assertion? >=20 > To be honest, I somehow overlooked that particular text - my mistake and > apologies. Reading it again, it probably does preclude parameters from > repeating, however, I can see some room for varied interpretations as to = if > that's a strong normative requirement or a looser suggestion about an err= or > code that could be used in that circumstance. >=20 > Perhaps it could be made more clear by adding some wording about it to th= e > end of the first part of sections 3&4 where it says: "Parameters sent wit= hout > a value MUST be treated as if they were omitted from the request. The > authorization server SHOULD ignore unrecognized request parameters."? >=20 > That said, does it make sense to relax the ban on repeating parameters in > some situations, like for the assertion parameter, to facilitate > easy encoding of multiple assertions? Anthony (Tony?) Nadalin > suggested that multiple assertions might be a common use case and I think > allowing for that via repeating assertion parameters is a cleaner and mor= e > reusable way to do it. >=20 > The text at the bottom of section for could say something like: >=20 > "Parameters sent without a value MUST be treated as if they were omitted > from the request. The authorization server SHOULD ignore unrecognized > request parameters. Parameters MUST NOT repeat unless otherwise noted > in the parameter definition." >=20 > Then in 4.1.3. the assertion parameter could be something like this: >=20 > "assertion > REQUIRED. The assertion(s). This parameter MAY be repeated in = the > request, if more than one > assertion is needed for the access grant" >=20 >=20 > Obviously Eran could improve on the actual text but hopefully that gets t= he > concept across? >=20 >=20 >=20 > On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav > wrote: > > Do we need to clarify 4.3.1 "repeats a parameter" description for > "invalid_request" error code does not preclude parameters from repeating? > I'm not sure. > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Brian Campbell > >> Sent: Monday, August 09, 2010 12:34 PM > >> To: oauth > >> Subject: [OAUTH-WG] more than one assertion? > >> > >> The question of allowing for multiple assertions in the SAML profile > >> came up recently. =A0See http://www.ietf.org/mail- > >> archive/web/oauth/current/msg04068.html and several subsequent > >> messages in the thread. > >> > >> I pushed back on the idea at first due to added complexity. =A0There > >> are a number of things that need to be addressed that aren't present > >> in the single assertion case. =A0 One of the sticker ones, to me, was > >> how to encode the assertions into the request. =A0 A SAML > >> element is a nice container for multiple assertions but using it in > >> this context seemed awkward at best. =A0A new schema could be defined > >> or a special deliminator character could be used but that seems excess= ive > and kludgy respectively. > >> > >> What about pushing it up into the HTTP layer and allowing for > >> multiple occurrences of the assertion=3DXXX parameter in the POST body= ? > >> I don't see anything in core OAuth that would necessarily preclude doi= ng > this. > >> =A0It seems cleaner and more lightweight than some of the other option= s. > >> =A0And perhaps it could be a more general (not just SAML) method of > >> sending multiple assertions in a single assertion grant type request? > >> > >> It'd look something like this: > >> > >> =A0 POST /token.oauth2 HTTP/1.1 > >> =A0 Host: authz.example.net > >> =A0 Content-Type: application/x-www-form-urlencoded > >> > >> =A0 =A0grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%= 2Fa > sse > >> =A0 =A0rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st > >> assertion...]&assertion=3D > >> =A0 =A0[...2nd assertion...]&assertion=3D[...3nd assertion...] > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > From oleg_gryb@yahoo.com Tue Aug 10 09:34:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62DFD3A6984 for ; Tue, 10 Aug 2010 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyDMZLn53Ueb for ; Tue, 10 Aug 2010 09:34:41 -0700 (PDT) Received: from web37602.mail.mud.yahoo.com (web37602.mail.mud.yahoo.com [209.191.87.85]) by core3.amsl.com (Postfix) with SMTP id 9D77B3A6888 for ; Tue, 10 Aug 2010 09:34:40 -0700 (PDT) Received: (qmail 77664 invoked by uid 60001); 10 Aug 2010 16:35:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1281458105; bh=1DyiPILA3ZOhadxlpbACmXectegzneDeL1rxiQ3NSP8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Jfo1oLetAlAu9dIds2mkgM9Z+lV/UIqbggyriz79UvaeJm5B8k6wlbwVn3GTEa634Af7j2IO1BgLvgBV/UHS7bzVzUygRicSCe6MHv4SmlhuCaF/uRzwoS8LDGviJBOfnn3Wd/G21KnbbMr2vfO77GMM/XRgU/fqWjMWALulGj8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=b0l3Oybl9eR9CTdCw3+69YML33eAR+SMJv49XjXrX8jMH4FDLyt2IRiE6texUCo+RwCruAOdML+FGbTmcwdFnDvGdZBhuXnX+TbTfDNuaI53PV8ZHU1VVT/sgydCbANRvjODhVVUjJHIkL/L8b//3UeqWj4cBjvZElB1Tmb6jO4=; Message-ID: <837544.77407.qm@web37602.mail.mud.yahoo.com> X-YMail-OSG: gJNK_v4VM1mgUL8zmdb677jRuSwk8Jt.wmHvHFIQ._BPUid fKYMNg76mOlyWhuqOo8QH1iegYWOuvm3FH5efb_T2KtIR3iniJeU2osIYSln jBUY1Xm9TfAYQ9CdWl_Rk.A5ofV30N2yoGyyr2EvAAyhBDoNKSlQ8BQd7Pko Lfq3xX8Ju37LTsg5v45ly4LT3rsD7w_dR7mIYu4PXgi5rDoVTEpXgOfaW5If TQBVCkyj49iFp8cI4gPAX1aXmv2JeWOBnZcyYtTTRA2MVhyycS_tHbMc4seV TiVReEW7sE_gziakYPEvMy9y5vNdmko21sQR1oYvPooOS0_csQPJmyyzZbEu NHe3umWZ.h2psRdD7qPwJ4vNhkwpM5hV6J3QG9bnHeQ-- Received: from [208.240.243.170] by web37602.mail.mud.yahoo.com via HTTP; Tue, 10 Aug 2010 09:35:05 PDT X-Mailer: YahooMailRC/459 YahooMailWebService/0.8.105.279950 References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> Date: Tue, 10 Aug 2010 09:35:05 -0700 (PDT) From: Oleg Gryb To: Torsten Lodderstedt , David Recordon In-Reply-To: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1592294065-1281458105=:77407" Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:34:43 -0000 --0-1592294065-1281458105=:77407 Content-Type: text/plain; charset=us-ascii I was trying to understand that too (see "Is user agent profile secure" thread). The answers that I've got were: 1. It's already coded this way. 2. It's the most efficient way of doing that, because that relay.html page is static and can be cached by a browser. None of the answers above looks very convincing to me, but that's where UA is now. From: Torsten Lodderstedt Can someone pls. explain why code and token should both be returned in the fragment? > > > >regards, >Torsten. > --0-1592294065-1281458105=:77407 Content-Type: text/html; charset=us-ascii
I was trying to understand that too (see "Is user agent profile secure" thread). The answers that I've got were:

1. It's already coded this way.
2. It's the most efficient way of doing that, because that relay.html page is static and can be cached by a browser.

None of the answers above looks very convincing to me, but that's where UA is now.

From: Torsten Lodderstedt <torsten@lodderstedt.net>
Can someone pls. explain why code and token should both be returned in the fragment?

regards,
Torsten.


--0-1592294065-1281458105=:77407-- From lshepard@facebook.com Tue Aug 10 10:33:12 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B3423A6AB3 for ; Tue, 10 Aug 2010 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.04 X-Spam-Level: X-Spam-Status: No, score=-101.04 tagged_above=-999 required=5 tests=[AWL=-1.054, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2ilW6OJgEYy for ; Tue, 10 Aug 2010 10:33:10 -0700 (PDT) Received: from mx-out.facebook.com (outmail010.ash1.tfbnw.net [69.63.184.110]) by core3.amsl.com (Postfix) with ESMTP id 5644B3A6A98 for ; Tue, 10 Aug 2010 10:33:10 -0700 (PDT) Received: from [10.18.255.136] ([10.18.255.136:20003] helo=mail.thefacebook.com) by mta006.ash1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 98/B6-14663-71B816C4; Tue, 10 Aug 2010 10:23:36 -0700 Received: from SC-MBX05.TheFacebook.com ([169.254.4.91]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Tue, 10 Aug 2010 10:23:34 -0700 From: Luke Shepard To: Oleg Gryb Thread-Topic: [OAUTH-WG] Quick survey: fragment vs. query Thread-Index: AQHLI3bDAITbPXwcLEeVdwj3462ZcJLaEPmAgAEqKoCAAEdBgIAADaYA Date: Tue, 10 Aug 2010 17:23:56 +0000 Message-ID: References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> <837544.77407.qm@web37602.mail.mud.yahoo.com> In-Reply-To: <837544.77407.qm@web37602.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F4265A73F7434E5FBE165A7D31308B5Afacebookcom_" MIME-Version: 1.0 Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:33:12 -0000 --_000_F4265A73F7434E5FBE165A7D31308B5Afacebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the possible URLs: http://static.facebook.com/connect/xd_proxy.php#code=3D10alkji&access_token= =3Dlzipa3p http://static.facebook.com/connect/xd_proxy.php?code=3D10alkji#access_token= =3Dlzipa3p Those who already use this flow in production (including Google, Facebook, = Twitter, and others) typically work like this: - Parent frame initiates the transaction by spawning a popup or an iframe - Response comes back to a static relay file (like the xd_proxy.php above) - The relay interprets the URL, parses out arguments, and hands them to the= parent frame - Parent frame then does what it wants. this could be making an API call vi= a JSONP, handing info to the server via Ajax, or something else. Because the relay file is static, it isn't going to interpret the code rega= rdless, even if it is sent in the query parameter. So since the client will= handle it anyway, the fragment is better for two reasons: 1/ Less code for the JS to just pull it out of the fragment 2/ More efficient, as the relay file can be cached on the client. If you in= clude a code then you degrade performance because it busts the cache every = time. On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote: I was trying to understand that too (see "Is user agent profile secure" thr= ead). The answers that I've got were: 1. It's already coded this way. 2. It's the most efficient way of doing that, because that relay.html page = is static and can be cached by a browser. None of the answers above looks very convincing to me, but that's where UA = is now. From: Torsten Lodderstedt > Can someone pls. explain why code and token should both be returned in the = fragment? regards, Torsten. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_F4265A73F7434E5FBE165A7D31308B5Afacebookcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9e0d3afe-fc3b-48e1-85a2-4e20da57065c> Content-Transfer-Encoding: quoted-printable
Here = are the possible URLs:

http://static.facebook= .com/connect/xd_proxy.php#code=3D10alkji&access_token=3Dlzipa3p
http://static.facebook.com/connect/xd_proxy.p= hp?code=3D10alkji#access_token=3Dlzipa3p

Those who a= lready use this flow in production (including Google, Facebook, Twitter, an= d others) typically work like this:

- Parent frame= initiates the transaction by spawning a popup or an iframe
- Res= ponse comes back to a static relay file (like the xd_proxy.php above)
=
- The relay interprets the URL, parses out arguments, and hands them t= o the parent frame
- Parent frame then does what it wants. this c= ould be making an API call via JSONP, handing info to the server via Ajax, = or something else.

Because the relay file is stati= c, it isn't going to interpret the code regardless, even if it is sent in t= he query parameter. So since the client will handle it anyway, the fragment= is better for two reasons:

1/ Less code for the J= S to just pull it out of the fragment
2/ More efficient, as the r= elay file can be cached on the client. If you include a code then you degra= de performance because it busts the cache every time.

<= div>
On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote:

I was tryin= g to understand that too (see "Is user agent profile secure" thre= ad). The answers that I've got were:

1. It's already = coded this way.
2. It's the most efficient way of doing that, because th= at relay.html page is static and can be cached by a browser.

None of= the answers above looks very convincing to me, but that's where UA is now.=  

From: Torsten Lodderstedt <torsten@lodderstedt.net>
=
Can someone pls. explain why code and token s= hould both be returned in the fragment?

regards,
Torsten.


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth

<= /body>= --_000_F4265A73F7434E5FBE165A7D31308B5Afacebookcom_-- From torsten@lodderstedt.net Tue Aug 10 10:51:40 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51ECC3A68B7 for ; Tue, 10 Aug 2010 10:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu2vEY6OmBmg for ; Tue, 10 Aug 2010 10:51:39 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id 8B14D3A6A8B for ; Tue, 10 Aug 2010 10:51:38 -0700 (PDT) Received: from [80.187.108.230] (helo=[10.164.59.182]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Oisze-0008Ox-IS; Tue, 10 Aug 2010 19:52:11 +0200 References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> <837544.77407.qm@web37602.mail.mud.yahoo.com> From: Torsten Lodderstedt Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2-360280464 In-Reply-To: Message-Id: Date: Tue, 10 Aug 2010 19:51:11 +0200 To: Luke Shepard Mime-Version: 1.0 (iPhone Mail 8A293) X-Mailer: iPhone Mail (8A293) X-Df-Sender: 141509 Cc: Naitik Shah , Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:51:40 -0000 --Apple-Mail-2-360280464 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you for the explanation. I no Am 10.08.2010 um 19:23 schrieb Luke Shepard : > Here are the possible URLs: >=20 > http://static.facebook.com/connect/xd_proxy.php#code=3D10alkji&access_toke= n=3Dlzipa3p > http://static.facebook.com/connect/xd_proxy.php?code=3D10alkji#access_toke= n=3Dlzipa3p >=20 > Those who already use this flow in production (including Google, Facebook,= Twitter, and others) typically work like this: >=20 > - Parent frame initiates the transaction by spawning a popup or an iframe > - Response comes back to a static relay file (like the xd_proxy.php above)= > - The relay interprets the URL, parses out arguments, and hands them to th= e parent frame > - Parent frame then does what it wants. this could be making an API call v= ia JSONP, handing info to the server via Ajax, or something else. >=20 > Because the relay file is static, it isn't going to interpret the code reg= ardless, even if it is sent in the query parameter. So since the client will= handle it anyway, the fragment is better for two reasons: >=20 > 1/ Less code for the JS to just pull it out of the fragment > 2/ More efficient, as the relay file can be cached on the client. If you i= nclude a code then you degrade performance because it busts the cache every t= ime. >=20 >=20 > On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote: >=20 >> I was trying to understand that too (see "Is user agent profile secure" t= hread). The answers that I've got were: >>=20 >> 1. It's already coded this way. >> 2. It's the most efficient way of doing that, because that relay.html pag= e is static and can be cached by a browser. >>=20 >> None of the answers above looks very convincing to me, but that's where U= A is now.=20 >>=20 >> From: Torsten Lodderstedt >> Can someone pls. explain why code and token should both be returned in th= e fragment? >>=20 >> regards, >> Torsten. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-2-360280464 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thank you for the explanation. I no
=


Am 10.08.2010 um 19:23 schrieb Luke Shepard <lshepard@facebook.com>:

Here are the possible URL= s:

http://static.facebook.com/connect/xd_proxy.= php?code=3D10alkji#access_token=3Dlzipa3p

Those w= ho already use this flow in production (including Google, Facebook, Twitter,= and others) typically work like this:

- Parent fra= me initiates the transaction by spawning a popup or an iframe
- Re= sponse comes back to a static relay file (like the xd_proxy.php above)
=
- The relay interprets the URL, parses out arguments, and hands them to= the parent frame
- Parent frame then does what it wants. this cou= ld be making an API call via JSONP, handing info to the server via Ajax, or s= omething else.

Because the relay file is static, it= isn't going to interpret the code regardless, even if it is sent in the que= ry parameter. So since the client will handle it anyway, the fragment is bet= ter for two reasons:

1/ Less code for the JS to jus= t pull it out of the fragment
2/ More efficient, as the relay file= can be cached on the client. If you include a code then you degrade perform= ance because it busts the cache every time.


On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote:

I was trying to understand that to= o (see "Is user agent profile secure" thread). The answers that I've got wer= e:

1. It's already coded this way.
2. It's the most e= fficient way of doing that, because that relay.html page is static and can b= e cached by a browser.

None of the answers above looks very convincin= g to me, but that's where UA is now.&n= bsp;

From: Torsten L= odderstedt <torsten@lodderstedt.net>

regar= ds,
Torsten.


= _______________________________________________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailm= an/listinfo/oauth

= --Apple-Mail-2-360280464-- From torsten@lodderstedt.net Tue Aug 10 10:58:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6058E3A6A99 for ; Tue, 10 Aug 2010 10:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.139 X-Spam-Level: X-Spam-Status: No, score=0.139 tagged_above=-999 required=5 tests=[AWL=-0.868, BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVUKBKWxv-Dx for ; Tue, 10 Aug 2010 10:58:06 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by core3.amsl.com (Postfix) with ESMTP id 9FEBE3A6A8B for ; Tue, 10 Aug 2010 10:58:05 -0700 (PDT) Received: from [80.187.108.230] (helo=[10.164.59.182]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Oit5o-0001b8-3z; Tue, 10 Aug 2010 19:58:39 +0200 References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> <837544.77407.qm@web37602.mail.mud.yahoo.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-3-360674921 Message-Id: <6A18E244-31B2-46F1-BA10-FC414C185EDB@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Tue, 10 Aug 2010 19:57:28 +0200 To: Luke Shepard X-Df-Sender: 141509 Cc: Naitik Shah , Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:58:07 -0000 --Apple-Mail-3-360674921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you for the explanation.=20 I now understand that the fragment is used for efficiently passing token or c= ode on the client side. What I still don't understand is why a client would n= eed both at once (url 1)? Have you such applications in production? regards, Torsten. Am 10.08.2010 um 19:23 schrieb Luke Shepard : > Here are the possible URLs: >=20 > http://static.facebook.com/connect/xd_proxy.php#code=3D10alkji&access_toke= n=3Dlzipa3p > http://static.facebook.com/connect/xd_proxy.php?code=3D10alkji#access_toke= n=3Dlzipa3p >=20 > Those who already use this flow in production (including Google, Facebook,= Twitter, and others) typically work like this: >=20 > - Parent frame initiates the transaction by spawning a popup or an iframe > - Response comes back to a static relay file (like the xd_proxy.php above)= > - The relay interprets the URL, parses out arguments, and hands them to th= e parent frame > - Parent frame then does what it wants. this could be making an API call v= ia JSONP, handing info to the server via Ajax, or something else. >=20 > Because the relay file is static, it isn't going to interpret the code reg= ardless, even if it is sent in the query parameter. So since the client will= handle it anyway, the fragment is better for two reasons: >=20 > 1/ Less code for the JS to just pull it out of the fragment > 2/ More efficient, as the relay file can be cached on the client. If you i= nclude a code then you degrade performance because it busts the cache every t= ime. >=20 >=20 > On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote: >=20 >> I was trying to understand that too (see "Is user agent profile secure" t= hread). The answers that I've got were: >>=20 >> 1. It's already coded this way. >> 2. It's the most efficient way of doing that, because that relay.html pag= e is static and can be cached by a browser. >>=20 >> None of the answers above looks very convincing to me, but that's where U= A is now.=20 >>=20 >> From: Torsten Lodderstedt >> Can someone pls. explain why code and token should both be returned in th= e fragment? >>=20 >> regards, >> Torsten. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-3-360674921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thank you for the explanation. 

I now understand that the fragment is used for effici= ently passing token or code on the client side. What I still don't understan= d is why a client would need both at once (url 1)? Have you such application= s in production?

regards,
Torsten.


Am 10.08.2010 um 19:23 schrieb Luke Shepard <lshepard@facebook.com>:

<= div>
Here are the possible URLs:

http://static.facebook.com/connect/xd_proxy.p= hp?code=3D10alkji#access_token=3Dlzipa3p

Those wh= o already use this flow in production (including Google, Facebook, Twitter, a= nd others) typically work like this:

- Parent frame= initiates the transaction by spawning a popup or an iframe
- Resp= onse comes back to a static relay file (like the xd_proxy.php above)
- The relay interprets the URL, parses out arguments, and hands them to t= he parent frame
- Parent frame then does what it wants. this could= be making an API call via JSONP, handing info to the server via Ajax, or so= mething else.

Because the relay file is static, it i= sn't going to interpret the code regardless, even if it is sent in the query= parameter. So since the client will handle it anyway, the fragment is bette= r for two reasons:

1/ Less code for the JS to just p= ull it out of the fragment
2/ More efficient, as the relay file ca= n be cached on the client. If you include a code then you degrade performanc= e because it busts the cache every time.


<= div>On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote:

I was trying to understand that too (= see "Is user agent profile secure" thread). The answers that I've got were:<= br>

1. It's already coded this way.
2. It's the most eff= icient way of doing that, because that relay.html page is static and can be c= ached by a browser.

None of the answers above looks very convincing t= o me, but that's where UA is now. = ;

From:=  Torsten Lodder= stedt <torsten@lodderstedt.net>
= Can someone pls. explain why code and token should both be= returned in the fragment?

regards,=
Torsten.


____= ___________________________________________
OAuth mailing list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/l= istinfo/oauth

= --Apple-Mail-3-360674921-- From oleg_gryb@yahoo.com Tue Aug 10 10:59:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135E23A6A95 for ; Tue, 10 Aug 2010 10:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYzYRPAwBTwn for ; Tue, 10 Aug 2010 10:59:47 -0700 (PDT) Received: from web37601.mail.mud.yahoo.com (web37601.mail.mud.yahoo.com [209.191.87.84]) by core3.amsl.com (Postfix) with SMTP id 7BF823A6A8B for ; Tue, 10 Aug 2010 10:59:47 -0700 (PDT) Received: (qmail 1866 invoked by uid 60001); 10 Aug 2010 18:00:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1281463219; bh=aryz9T14OUfdjNMyirwjhKfTvWwMCqRKTQqNePKuppg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MrzPjyUvaz4USO1o3pR2zFyjE4WWqq9LV87KdEkaGkK300/mouvq/JseznyjmSd9t8G+kJcjYGYDjd1rWSFwvKPymq6EOD+cM7Iq7gIs4yNaEJT8vPqVc6K3RIKBm8AiyPTjLlPY75Zml0Dtr2wKolBq2BMSjyQh2IEa+8ioAbU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ZQxuZer4H8fOBTC+1ew719yls9Xqxuwpxz0oHSnAA0XXaLcE1222kB/LihU7L2NIlXPyeDRcMvcC3lyxlszjM+rTdatvWyAaGkJDA5bzn1BxAxznWKC+lRtDRlKyDZYsunLCXN36Lx7NQMNVaUnwXMc1NRpvul2Nls6dPeAk2Is=; Message-ID: <917905.1164.qm@web37601.mail.mud.yahoo.com> X-YMail-OSG: dpqXXvMVM1msHGHN6MLJDkxEwNCT0GF9GwHgxIPVZNVv2RE C2ftTwfKaxBelpBgZjIpwg62e3dsC7gEMaTcvn8gww.NLOqZECOqPsTErxpB E74gU_wlPjnEmFrjAtP46TsfiAWUVX5KSx1I42ilcJs.iOd4qPYHGTTnViVA qDZKJ4zDmpg3A00NaqP0LbG56tTofbh2cLpGIAoy9caUKMxVATFGpVYKjO7M vE5YcI3HKGpP8vLcFZv5TMWnjVU1IN6Y5bhvEv5MomfV4VW5fq.oR80PtImg vDZMhw.2Efroq9kATOBB.vJY18Ov8ghD0QBk.iPN0mlJK7OsNLkrwVwenTOR ByISRg740qtl_ Received: from [208.240.243.170] by web37601.mail.mud.yahoo.com via HTTP; Tue, 10 Aug 2010 11:00:19 PDT X-Mailer: YahooMailRC/459 YahooMailWebService/0.8.105.279950 References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> <837544.77407.qm@web37602.mail.mud.yahoo.com> Date: Tue, 10 Aug 2010 11:00:19 -0700 (PDT) From: Oleg Gryb To: Luke Shepard , Oleg Gryb In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1686917626-1281463219=:1164" Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:59:49 -0000 --0-1686917626-1281463219=:1164 Content-Type: text/plain; charset=us-ascii Luke, Thanks for answering. Sorry, for been paranoid, but I think that you'll have more qs in regards of your frame-based-cross-domain-secret-sharing solution. The thing is that each time when a web app with sensitive info can be run in a frame, security people would advice to break that frame-reads-other-frame-data logic, because it can lead to violation of same origin policy. I think Torsten's suggestion is correct: somebody would need to "threat model" the current UA flow. Alternatively, you might want to consider creating yet another "safer UA flow" where access token will not be passed in a URL. It might require using dynamic pages generated by a server, but if somebody wants to implement a more secure solution, they'll at least have a choice. > >From: Luke Shepard >To: Oleg Gryb >Cc: Torsten Lodderstedt ; David Recordon >; Naitik Shah ; OAuth WG > >Sent: Tue, August 10, 2010 10:23:56 AM >Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query > > >Here are the possible URLs: > > >http://static.facebook.com/connect/xd_proxy.php#code=10alkji&access_token=lzipa3p > >http://static.facebook.com/connect/xd_proxy.php?code=10alkji#access_token=lzipa3p > > > >Those who already use this flow in production (including Google, Facebook, >Twitter, and others) typically work like this: > > >- Parent frame initiates the transaction by spawning a popup or an iframe >- Response comes back to a static relay file (like the xd_proxy.php above) >- The relay interprets the URL, parses out arguments, and hands them to the >parent frame >- Parent frame then does what it wants. this could be making an API call via >JSONP, handing info to the server via Ajax, or something else. > > >Because the relay file is static, it isn't going to interpret the code >regardless, even if it is sent in the query parameter. So since the client will >handle it anyway, the fragment is better for two reasons: > > >1/ Less code for the JS to just pull it out of the fragment >2/ More efficient, as the relay file can be cached on the client. If you include >a code then you degrade performance because it busts the cache every time. > > > > >On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote: > >I was trying to understand that too (see "Is user agent profile secure" thread). >The answers that I've got were: >> >> >>1. It's already coded this way. >>2. It's the most efficient way of doing that, because that relay.html page is >>static and can be cached by a browser. >> >>None of the answers above looks very convincing to me, but that's where UA is >>now. >> >>From: Torsten Lodderstedt >> >>Can someone pls. explain why code and token should both be returned in the >>fragment? >>> >>> >>> >>>regards, >>>Torsten. >>> >>_______________________________________________ >>OAuth mailing list >>OAuth@ietf.org >>https://www.ietf.org/mailman/listinfo/oauth >> > --0-1686917626-1281463219=:1164 Content-Type: text/html; charset=us-ascii
Luke,

Thanks for answering. Sorry, for been paranoid, but I think that you'll have more qs in regards of your frame-based-cross-domain-secret-sharing solution.

The thing is that each time when a web app with sensitive info can be run in a frame, security people would advice to break that frame-reads-other-frame-data logic, because it can lead to violation of same origin policy.

I think Torsten's suggestion is correct: somebody would need to "threat model" the current UA flow.

Alternatively, you might want to consider creating yet another "safer UA flow" where access token will not be passed in a URL. It might require using dynamic pages generated by a server, but if somebody wants to implement a more secure solution, they'll at least have a choice.

 


From: Luke Shepard <lshepard@facebook.com>
To: Oleg Gryb <oleg@gryb.info>
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>; David Recordon <recordond@gmail.com>; Naitik Shah <naitik@facebook.com>; OAuth WG <oauth@ietf.org>
Sent: Tue, August 10, 2010 10:23:56 AM
Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query

Here are the possible URLs:

http://static.facebook.com/connect/xd_proxy.php?code=10alkji#access_token=lzipa3p

Those who already use this flow in production (including Google, Facebook, Twitter, and others) typically work like this:

- Parent frame initiates the transaction by spawning a popup or an iframe
- Response comes back to a static relay file (like the xd_proxy.php above)
- The relay interprets the URL, parses out arguments, and hands them to the parent frame
- Parent frame then does what it wants. this could be making an API call via JSONP, handing info to the server via Ajax, or something else.

Because the relay file is static, it isn't going to interpret the code regardless, even if it is sent in the query parameter. So since the client will handle it anyway, the fragment is better for two reasons:

1/ Less code for the JS to just pull it out of the fragment
2/ More efficient, as the relay file can be cached on the client. If you include a code then you degrade performance because it busts the cache every time.


On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote:

I was trying to understand that too (see "Is user agent profile secure" thread). The answers that I've got were:

1. It's already coded this way.
2. It's the most efficient way of doing that, because that relay.html page is static and can be cached by a browser.

None of the answers above looks very convincing to me, but that's where UA is now. 

From: Torsten Lodderstedt <torsten@lodderstedt.net>
Can someone pls. explain why code and token should both be returned in the fragment?

regards,
Torsten.


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


--0-1686917626-1281463219=:1164-- From eve@xmlgrrl.com Tue Aug 10 12:31:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B043A6ABC for ; Tue, 10 Aug 2010 12:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.014 X-Spam-Level: X-Spam-Status: No, score=-1.014 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqC8dGX39rfU for ; Tue, 10 Aug 2010 12:31:14 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id E83F43A695E for ; Tue, 10 Aug 2010 12:31:13 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o7AJViuJ017748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Aug 2010 12:31:44 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Eve Maler Date: Tue, 10 Aug 2010 12:31:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> References: <20100810192359.2E4F63A69B0@core3.amsl.com> To: OAuth WG X-Mailer: Apple Mail (2.1081) Cc: Maciej Machulak Subject: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:31:16 -0000 Folks-- The UMA group has produced the following I-D as input to the = OAuth discovery/registration/binding discussion. We wanted to set forth = our requirements (knowing that there may be other requirements from the = wider community) and propose some solutions that meet them. If further = discussion seems to warrant an updating of this draft, we're happy to do = that. (If you have interest in getting involved in UMA-specific work, = feel free to drop me a note.) Eve http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt Begin forwarded message: > From: IETF I-D Submission Tool > Date: 10 August 2010 12:23:59 PM PDT > To: eve@xmlgrrl.com > Cc: cs@comlounge.net, m.p.machulak@ncl.ac.uk > Subject: New Version Notification for draft-oauth-dyn-reg-v1-00=20 >=20 >=20 > A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been = successfully submitted by Eve Maler and posted to the IETF repository. >=20 > Filename: draft-oauth-dyn-reg-v1 > Revision: 00 > Title: OAuth Dynamic Client Registration Protocol > Creation_date: 2010-08-10 > WG ID: Independent Submission > Number_of_pages: 20 >=20 > Abstract: > This specification proposes an OAuth Dynamic Client Registration > protocol. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler From igor.faynberg@alcatel-lucent.com Tue Aug 10 12:45:09 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D094A3A6AC0 for ; Tue, 10 Aug 2010 12:45:08 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnWwhp2G9xSN for ; Tue, 10 Aug 2010 12:45:05 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id B9DE73A67F2 for ; Tue, 10 Aug 2010 12:45:02 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o7AJjblQ025565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 14:45:37 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o7AJjaE2021726; Tue, 10 Aug 2010 14:45:37 -0500 (CDT) Message-ID: <4C61AC60.9030202@alcatel-lucent.com> Date: Tue, 10 Aug 2010 15:45:36 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <4C572883.7020302@lodderstedt.net> <9517276C-A806-4630-84D1-6B3F1F6A7754@lodderstedt.net> In-Reply-To: <9517276C-A806-4630-84D1-6B3F1F6A7754@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: "OAuth WG \(oauth@ietf.org\)" Subject: Re: [OAUTH-WG] OAuth Discovery Requirements X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:45:10 -0000 +1 (1) is crystal-clear and is a must, as far as I am concerned. (2) would definitely help as a catch-all for unauthorized requests. Igor Torsten Lodderstedt wrote: > Would it make sense to support two scenarios? (1) Discovery as described in my original posting independent of "functional" requests. (2) Discovery for unauthorized requests (WWW-Authenticate header). > > The later might be a lightweight variant of the first scenario. > > regards, > Torsten. > > > > Am 02.08.2010 um 22:20 schrieb Torsten Lodderstedt : > > >> In the WG meeting at Maastricht, I have been asked to write down my requirements regarding Discovery. And here they are: >> >> Assumptions: Discovery allows a compliant client to automatically obtain all deployment specific data required to securely access a particular resource servers as well as its respective authorization server for the purpose of obtaining access tokens. >> >> Starting point of the discovery process is a resource URL. This URL can be hard-coded into the client, bundled with the applications resources or manually configured by the end-user at runtime. >> >> 1) Client -> Resource >> The client uses the resource URL to obtain resource-specific data, such as >> a) one URI refering to its authorization server >> b) a definition of all scopes of the resource >> c) additional data, e.g. supported signature methods and algorithms >> >> I do not make any assumption about how many requests are processed in order to gather this information and whether there will be any levels of indirections (e.g. from resource to resource server). >> >> 2) Client -> Authz Server >> The authz server URI obtained in step 1 is used to gather the following data from the authz server: >> a) endpoint URLs (end-user authorization, tokens, ...) >> b) information about the server's capabilities, e.g. the supported response (end-user authorization endpoint) and grant types (tokens endpoint) >> >> The client stores the authz server's discovery URL along with the token(s) it obtains for further use. >> >> And that's it from my point of view. I would very much appreciate if we could have a discussion towards a consensus about discovery requirements. >> >> regards, >> Torsten. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From igor.faynberg@alcatel-lucent.com Tue Aug 10 12:47:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2801D3A6AB2 for ; Tue, 10 Aug 2010 12:47:39 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZAQn8ldNaz3 for ; Tue, 10 Aug 2010 12:47:37 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 6107F3A69BE for ; Tue, 10 Aug 2010 12:47:36 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o7AJmA4d027643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 14:48:10 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o7AJm8Ur024133; Tue, 10 Aug 2010 14:48:09 -0500 (CDT) Message-ID: <4C61ACF8.4020700@alcatel-lucent.com> Date: Tue, 10 Aug 2010 15:48:08 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A9D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F03A9D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: oauth Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:47:39 -0000 Strongly agree. Igor Eran Hammer-Lahav wrote: > The single assertion use case is well defined. If you need to support multiple assertions in a single request, you will need to define a way to group them together and include them using the single assertion parameter or define an extension for additional assertions. Either way, this sounds like something that belongs in its own spec. > > EHL > > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Anthony Nadalin >> Sent: Tuesday, August 03, 2010 3:29 PM >> To: Brian Campbell >> Cc: oauth >> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >> draft >> >> This is a use case we are seeing from the various government agencies (UK, >> USA, BC), I agree it add complexity but with having to satisfy several claims >> (i.e. over 21 and being a resident of sate) this seems to be pretty common >> these days. >> >> -----Original Message----- >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> Sent: Tuesday, August 03, 2010 1:12 PM >> To: Anthony Nadalin >> Cc: oauth >> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >> draft >> >> Seems like a much more complicated scenario. Allowing more than one >> assertion, off the top of my head, would necessitate some major changes to >> this profile: >> >> * Define how multiple assertions are encoded into the single "assertion" >> form control (samlp:Response, concatenated, something >> else?) >> * Deal with subject equality across the assertions >> * Define the processing rules for multiple assertion (from different >> issuers) and the expected behavior when some but not all are valid. >> >> That seems like it would add significant complexity to the existing draft (that >> I'm trying to keep simple) for a particular scenario that I'm not sure is very >> common. But maybe I'm wrong. Is this something >> that others anticipate needing? If so, does it belong here? >> >> >> On Mon, Aug 2, 2010 at 4:26 PM, Anthony Nadalin >> wrote: >> >>> So the scenario we have is where there are multiple tokens from attribute >>> >> and identity providers need to be delivered to an OAuth authorization server >> to satisfy the resource owner's policy of required claims. So this is a case >> where a single SAML token/assertion is not enough to satisfy the claim, we >> still expect that the signature verification is out of scope. >> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Brian Campbell >>> Sent: Monday, August 02, 2010 2:53 PM >>> To: oauth >>> Subject: Re: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth >>> 2.0 draft >>> >>> I guess I'd need to understand the scenario better before I'd have an >>> opinion one way or the other. However, I will say that In this >>> profile I was specifically looking to avoid the complexity that exists in SAML >>> >> Web SSO by allowing for multiple assertions and multiple subject >> confirmations. >> >>> On Mon, Aug 2, 2010 at 3:20 PM, Anthony Nadalin >>> >> wrote: >> >>>> There are many cases where we need to have more than 1 SAML >>>> >> assertion be used to represent the authorization token, so would want a >> provision for multiple SAML tokens and not sure it makes sense to have a >> separate profile for that or add it as an option here. >> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Brian Campbell >>>> Sent: Thursday, July 15, 2010 1:50 PM >>>> To: oauth >>>> Subject: [OAUTH-WG] SAML 2.0 Bearer Assertion Profile for OAuth 2.0 >>>> draft >>>> >>>> I'm gong to join the growing list of people attaching a potential I-D >>>> to an email due to he cut off time for the I-D submissions. Attached >>>> is a draft that aims to tightly define the particular format of a >>>> SAML >>>> 2.0 bearer assertion in requesting an access token using the >>>> assertion grant_type. I've been working with Chuck at >>>> Salesforce.com on this and the primary goal is to have some >>>> documentation or specification that is sufficient to facilitate >>>> interoperability between independently developed implementations or >>>> >> products. This, of course, wouldn't preclude using SAML in other ways - it >> would only provide one concrete definition to implement against. >> >>>> I intend to submit this as an I-D when the submission process reopens. >>>> Any feedback from this group would be appreciated as well as thoughts >>>> >> about this eventually becoming a working group draft. >> >>>> Thanks, >>>> Brian Campbell >>>> >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Tue Aug 10 13:18:31 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695CC3A68C5 for ; Tue, 10 Aug 2010 13:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiZtkmkxpqdH for ; Tue, 10 Aug 2010 13:18:30 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id AB5C53A683C for ; Tue, 10 Aug 2010 13:18:29 -0700 (PDT) Received: by bwz10 with SMTP id 10so2840606bwz.31 for ; Tue, 10 Aug 2010 13:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rp17v3fMqlDW8L4SikdUDPjmhnBH6e0L5sGthX7h75g=; b=FhNFuicBNPA1S/aK8ulsQD3vRrfif4G3DsBvMhJbSMLDU4gizTDh+IeWomG3owOdmX v5RMz2KzSyWs+4SnR1T9757WoUJWqPhj8wRHb/Y/xdXMs1gU3XF6DwZXX2TqHlZYSKn3 hZzHxwikD4HxuvG1MoHnDufOA4dbwK/d0YdAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mzbZ27w5oeG3jRjJoyuDqFY+gRRd5oSVniWuvkwbqPd2mM8H4qSvGmFo69DaMv9Ani en+vAPSunTNzrlneRYdhyJ2SqSMjdH8gMSnca7yFv5a+L9asO1HBZZGQHz+6Bp92mRCI ZPARE4pawjLZzpVuoJsXYS8IRSNQr5VQAvIlo= MIME-Version: 1.0 Received: by 10.204.126.29 with SMTP id a29mr4478791bks.59.1281471544190; Tue, 10 Aug 2010 13:19:04 -0700 (PDT) Received: by 10.204.132.155 with HTTP; Tue, 10 Aug 2010 13:19:04 -0700 (PDT) In-Reply-To: <917905.1164.qm@web37601.mail.mud.yahoo.com> References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> <837544.77407.qm@web37602.mail.mud.yahoo.com> <917905.1164.qm@web37601.mail.mud.yahoo.com> Date: Tue, 10 Aug 2010 13:19:04 -0700 Message-ID: From: David Recordon To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:18:31 -0000 Hey Oleg, a server based "safer" version of the user agent flow is the web server flow. It doesn't pass the access token via the fragment or via any means without SSL. On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote: > Luke, > > Thanks for answering. Sorry, for been paranoid, but I think that you'll h= ave > more qs in regards of your frame-based-cross-domain-secret-sharing soluti= on. > > The thing is that each time when a web app with sensitive info can be run= in > a frame, security people would advice to break that > frame-reads-other-frame-data logic, because it can lead to violation of s= ame > origin policy. > > I think Torsten's suggestion is correct: somebody would need to "threat > model" the current UA flow. > > Alternatively, you might want to consider creating yet another "safer UA > flow" where access token will not be passed in a URL. It might require us= ing > dynamic pages generated by a server, but if somebody wants to implement a > more secure solution, they'll at least have a choice. > > > > > From: Luke Shepard > To: Oleg Gryb > Cc: Torsten Lodderstedt ; David Recordon > ; Naitik Shah ; OAuth WG > > Sent: Tue, August 10, 2010 10:23:56 AM > Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query > > Here are the possible URLs: > http://static.facebook.com/connect/xd_proxy.php#code=3D10alkji&access_tok= en=3Dlzipa3p > http://static.facebook.com/connect/xd_proxy.php?code=3D10alkji#access_tok= en=3Dlzipa3p > Those who already use this flow in production (including Google, Facebook= , > Twitter, and others) typically work like this: > - Parent frame initiates the transaction by spawning a popup or an iframe > - Response comes back to a static relay file (like the xd_proxy.php above= ) > - The relay interprets the URL, parses out arguments, and hands them to t= he > parent frame > - Parent frame then does what it wants. this could be making an API call = via > JSONP, handing info to the server via Ajax, or something else. > Because the relay file is static, it isn't going to interpret the code > regardless, even if it is sent in the query parameter. So since the clien= t > will handle it anyway, the fragment is better for two reasons: > 1/ Less code for the JS to just pull it out of the fragment > 2/ More efficient, as the relay file can be cached on the client. If you > include a code then you degrade performance because it busts the cache ev= ery > time. > > On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote: > > I was trying to understand that too (see "Is user agent profile secure" > thread). The answers that I've got were: > > 1. It's already coded this way. > 2. It's the most efficient way of doing that, because that relay.html pag= e > is static and can be cached by a browser. > > None of the answers above looks very convincing to me, but that's where U= A > is now. > > From:=A0Torsten Lodderstedt > > Can someone pls. explain why code and token should both be returned in th= e > fragment? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > From Oleg_Gryb@intuit.com Tue Aug 10 13:21:22 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF9FE3A6899 for ; Tue, 10 Aug 2010 13:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYGJb+XpL3Zr for ; Tue, 10 Aug 2010 13:21:20 -0700 (PDT) Received: from mail1.intuit.com (mail1.intuit.com [12.149.175.11]) by core3.amsl.com (Postfix) with ESMTP id AB1013A68AD for ; Tue, 10 Aug 2010 13:21:20 -0700 (PDT) DomainKey-Signature: s=default; d=intuit.com; c=nofws; q=dns; h=X-SBRS:X-IronPort-AV:Received:Received:X-MimeOLE: Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Cc: Return-Path:X-OriginalArrivalTime; b=qawKaWF26kIDPVZW3YYhMndmVTlPz50LcALc4AQyyziiyei7qqxs+15G wXFbe+ukZc2ZJQ2pgE7wKT8mpMNOIsQ1zs0ICt/vyDrWmqKWHQzTUWbXL o+U+gHwRh53hE0W; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=intuit.com; i=Oleg_Gryb@intuit.com; q=dns/txt; s=default; t=1281471716; x=1313007716; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; z=MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable|Subject:=20RE:=20[OAUTH-WG]=20Quick=20survey: =20fragment=20vs.=20query|Date:=20Tue,=2010=20Aug=202010 =2013:21:52=20-0700|Message-ID:=20<3555AD897E5CAE4BA5D9E0 8AFBD7A7490921EF6F@SDGEXEVS07.corp.intuit.net> |In-Reply-To:=20|References:=20<8F6F3A55-274C-4F38-84C8-C 956D74504AE@lodderstedt.net><837544.77407.qm@web37602.mai l.mud.yahoo.com><917905.1164.qm@web37601.mail.mud.yahoo.com>=20 |From:=20"Gryb,=20Oleg"=20 |To:=20"David=20Recordon"=20|Cc:=20" Luke=20Shepard"=20,=0D=0A=09"Torst en=20Lodderstedt"=20,=0D=0A=09"N aitik=20Shah"=20,=0D=0A=09"OAuth=20W G"=20; bh=OLjfxJd67HWdRzDW7gpmQqpxOfdBlJ2CeEvtt6qOpAk=; b=j69quqAKo0AbKmxSIeNPlqGwZsgyf2RBHsPBlcGuXYVOI/H7wDLVwIZk 5r/JUKsLlcLvo8CVeOZbF34lfFeEmq6tlwdCSR7sMCxgYz+BKiq8oIPkh gYdAoicTa3cq1KV; X-SBRS: None X-IronPort-AV: E=Sophos;i="4.55,349,1278313200"; d="scan'208";a="245362361" Received: from relay-ex.sd.intuit.com (HELO SDGEXBH03.corp.intuit.net) ([172.17.135.77]) by mail1.sdg.ie.intuit.com with ESMTP; 10 Aug 2010 13:21:53 -0700 Received: from SDGEXEVS07.corp.intuit.net ([172.17.135.182]) by SDGEXBH03.corp.intuit.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 13:21:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Aug 2010 13:21:52 -0700 Message-ID: <3555AD897E5CAE4BA5D9E08AFBD7A7490921EF6F@SDGEXEVS07.corp.intuit.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Quick survey: fragment vs. query Thread-Index: Acs4yUknv+mYZtcjReehRBpQN7wOTQAABMQw References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net><837544.77407.qm@web37602.mail.mud.yahoo.com><917905.1164.qm@web37601.mail.mud.yahoo.com> From: "Gryb, Oleg" To: "David Recordon" X-OriginalArrivalTime: 10 Aug 2010 20:21:53.0687 (UTC) FILETIME=[AC159A70:01CB38C9] X-Mailman-Approved-At: Tue, 10 Aug 2010 13:27:33 -0700 Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:23:10 -0000 Yes, but you'll need a web server client for that. I'm saying that UA = profile can be POST based too. If you want, I can write an example of both client and server side code = to explain what I mean. -----Original Message----- From: David Recordon [mailto:recordond@gmail.com]=20 Sent: Tuesday, August 10, 2010 1:19 PM To: Oleg Gryb Cc: Luke Shepard; Torsten Lodderstedt; Naitik Shah; OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query Hey Oleg, a server based "safer" version of the user agent flow is the web server flow. It doesn't pass the access token via the fragment or via any means without SSL. On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote: > Luke, > > Thanks for answering. Sorry, for been paranoid, but I think that = you'll have > more qs in regards of your frame-based-cross-domain-secret-sharing = solution. > > The thing is that each time when a web app with sensitive info can be = run in > a frame, security people would advice to break that > frame-reads-other-frame-data logic, because it can lead to violation = of same > origin policy. > > I think Torsten's suggestion is correct: somebody would need to = "threat > model" the current UA flow. > > Alternatively, you might want to consider creating yet another "safer = UA > flow" where access token will not be passed in a URL. It might require = using > dynamic pages generated by a server, but if somebody wants to = implement a > more secure solution, they'll at least have a choice. > > > > > From: Luke Shepard > To: Oleg Gryb > Cc: Torsten Lodderstedt ; David Recordon > ; Naitik Shah ; OAuth WG > > Sent: Tue, August 10, 2010 10:23:56 AM > Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query > > Here are the possible URLs: > = http://static.facebook.com/connect/xd_proxy.php#code=3D10alkji&access_tok= en=3Dlzipa3p > = http://static.facebook.com/connect/xd_proxy.php?code=3D10alkji#access_tok= en=3Dlzipa3p > Those who already use this flow in production (including Google, = Facebook, > Twitter, and others) typically work like this: > - Parent frame initiates the transaction by spawning a popup or an = iframe > - Response comes back to a static relay file (like the xd_proxy.php = above) > - The relay interprets the URL, parses out arguments, and hands them = to the > parent frame > - Parent frame then does what it wants. this could be making an API = call via > JSONP, handing info to the server via Ajax, or something else. > Because the relay file is static, it isn't going to interpret the code > regardless, even if it is sent in the query parameter. So since the = client > will handle it anyway, the fragment is better for two reasons: > 1/ Less code for the JS to just pull it out of the fragment > 2/ More efficient, as the relay file can be cached on the client. If = you > include a code then you degrade performance because it busts the cache = every > time. > > On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote: > > I was trying to understand that too (see "Is user agent profile = secure" > thread). The answers that I've got were: > > 1. It's already coded this way. > 2. It's the most efficient way of doing that, because that relay.html = page > is static and can be cached by a browser. > > None of the answers above looks very convincing to me, but that's = where UA > is now. > > From:=A0Torsten Lodderstedt > > Can someone pls. explain why code and token should both be returned in = the > fragment? > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > From lr@lukasrosenstock.net Wed Aug 11 01:19:45 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211793A6A36 for ; Wed, 11 Aug 2010 01:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IraMUC2pMmYN for ; Wed, 11 Aug 2010 01:19:43 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 6FC853A6A0A for ; Wed, 11 Aug 2010 01:19:43 -0700 (PDT) Received: by qyk1 with SMTP id 1so4144650qyk.10 for ; Wed, 11 Aug 2010 01:20:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.3.11 with SMTP id 11mr7711262qal.108.1281514818941; Wed, 11 Aug 2010 01:20:18 -0700 (PDT) Received: by 10.229.214.68 with HTTP; Wed, 11 Aug 2010 01:20:18 -0700 (PDT) In-Reply-To: <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> Date: Wed, 11 Aug 2010 10:20:18 +0200 Message-ID: From: Lukas Rosenstock To: OAuth WG Content-Type: multipart/alternative; boundary=0015175ca86e8eb36e048d87eb73 Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 08:19:45 -0000 --0015175ca86e8eb36e048d87eb73 Content-Type: text/plain; charset=ISO-8859-1 Nice to see this draft! I've just read it and would like to provide some feedback: 1) redirect_url vs. redirect_uri: In different flows, different terms have been used. I think that should be consistent and it should be uri. 2) Data formats for requests: This spec uses JSON for everything. The core OAuth (draft 10) uses encoded forms for the request and JSON for the response. Why not make it consistent with that? I don't see any requirement to actually POST in JSON as well. 3) The OpenID Connect proposal* includes something similar. For the response, they have added a few more parameters along with client_id and client_secret. To quote it: - expires_in - The number of seconds that this id and secret are good for or "0" if it does not expire. - flows_supported - A comma separated list of the OAuth 2.0 flows which this server supports. The server MUST support the Web server (web_server) and User-Agent (user_agent) flows. Don't you think those would be useful?! Also, so far there's no information (or I didn't see it ...) on whether dynamic registration should be considered temporary or permanent. Thanks and regards, Lukas Rosenstock [*] http://openidconnect.com/ 2010/8/10 Eve Maler > Folks-- The UMA group has produced the following I-D as input to the OAuth > discovery/registration/binding discussion. We wanted to set forth our > requirements (knowing that there may be other requirements from the wider > community) and propose some solutions that meet them. If further discussion > seems to warrant an updating of this draft, we're happy to do that. (If you > have interest in getting involved in UMA-specific work, feel free to drop me > a note.) > > Eve > > http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt > > --0015175ca86e8eb36e048d87eb73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nice to see this draft!
I've just read it and would like to provide= some feedback:

1) redirect_url vs. redirect_= uri: In different flows, different terms have been used. I think that shoul= d be consistent and it should be uri.

2) Data formats for requests: This spec uses JSON for e= verything. The core OAuth (draft 10) uses encoded forms for the request and= JSON for the response. Why not make it consistent with that? I don't s= ee any requirement to actually POST in JSON as well.

3) The OpenID Connect proposal* includes something simi= lar. For the response, they have added a few more parameters along with cli= ent_id and client_secret. To quote it:
-=A0expires_in - The numbe= r of seconds that this id and secret are good for or "0" if it do= es not expire.
- flows_supported - A comma separated list of the OAuth 2.0 flows whic= h this server supports. The server MUST support the Web server (web_server)= and User-Agent (user_agent) flows.
Don't you think those wou= ld be useful?!=A0Also, so far there's no information (or I didn't s= ee it ...) on whether dynamic registration should be considered temporary o= r permanent.

Thanks and regards,
=A0Lukas Rosenstock
=



2010/= 8/10 Eve Maler <eve= @xmlgrrl.com>
Folks-- The UMA group has produced the foll= owing I-D as input to the OAuth discovery/registration/binding discussion. = =A0We wanted to set forth our requirements (knowing that there may be other= requirements from the wider community) and propose some solutions that mee= t them. =A0If further discussion seems to warrant an updating of this draft= , we're happy to do that. =A0(If you have interest in getting involved = in UMA-specific work, feel free to drop me a note.)

=A0 =A0 =A0 =A0Eve

http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt

--0015175ca86e8eb36e048d87eb73-- From torsten@lodderstedt.net Wed Aug 11 03:41:10 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD5F3A689D for ; Wed, 11 Aug 2010 03:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4jRK7rldUjE for ; Wed, 11 Aug 2010 03:41:09 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id 526323A685A for ; Wed, 11 Aug 2010 03:41:08 -0700 (PDT) Received: from [80.187.109.217] (helo=[10.165.72.207]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Oj8kf-0001on-Rk; Wed, 11 Aug 2010 12:41:43 +0200 References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> In-Reply-To: <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 11 Aug 2010 12:40:53 +0200 To: Eve Maler X-Df-Sender: 141509 Cc: OAuth WG , Maciej Machulak Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:41:10 -0000 Eve, thank you for writting this document. I consider it a good starting point fo= r a discussion about client registration and discovery. Will you propose thi= s as a WG item? My comments & questions: You propose a host-meta based discovery of the registration endpoint on the a= uthz server. Could this mechanism be used for discovering all AS endpoints, e= .g. tokens and end-user authorization? How is a UMA requestor envisioned to discover the auth server? I think host-meta based client discovery could be to limited since it does n= ot allow (at least in my understanding) to serve different clients (or their= home web apps) on the same host. What about using JRD or XRD? This would al= low for a client-URL-related discovery. What means for authentication a client against its home web app. do you envi= sion? regards, Torsten. Am 10.08.2010 um 21:31 schrieb Eve Maler : > Folks-- The UMA group has produced the following I-D as input to the OAuth= discovery/registration/binding discussion. We wanted to set forth our requ= irements (knowing that there may be other requirements from the wider commun= ity) and propose some solutions that meet them. If further discussion seems= to warrant an updating of this draft, we're happy to do that. (If you have= interest in getting involved in UMA-specific work, feel free to drop me a n= ote.) >=20 > Eve >=20 > http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >=20 > Begin forwarded message: >=20 >> From: IETF I-D Submission Tool >> Date: 10 August 2010 12:23:59 PM PDT >> To: eve@xmlgrrl.com >> Cc: cs@comlounge.net, m.p.machulak@ncl.ac.uk >> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00=20 >>=20 >>=20 >> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been successfully= submitted by Eve Maler and posted to the IETF repository. >>=20 >> Filename: draft-oauth-dyn-reg-v1 >> Revision: 00 >> Title: OAuth Dynamic Client Registration Protocol >> Creation_date: 2010-08-10 >> WG ID: Independent Submission >> Number_of_pages: 20 >>=20 >> Abstract: >> This specification proposes an OAuth Dynamic Client Registration >> protocol. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >=20 >=20 > Eve Maler > http://www.xmlgrrl.com/blog > http://www.twitter.com/xmlgrrl > http://www.linkedin.com/in/evemaler >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@nsn.com Wed Aug 11 04:20:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714B63A686E for ; Wed, 11 Aug 2010 04:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMSwGF8BvSr8 for ; Wed, 11 Aug 2010 04:20:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 106A23A6807 for ; Wed, 11 Aug 2010 04:20:35 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg9MC012480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 11 Aug 2010 12:42:09 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7BAg96N026202 for ; Wed, 11 Aug 2010 12:42:09 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 12:42:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3941.D620D0ED" Date: Wed, 11 Aug 2010 13:42:03 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E5D297@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Feedback solicited for Privacy and Identity Management Terminology Thread-Index: Acs5Pe7BXoEHlsg3SgWwmsl6jcwj/g== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "OAuth WG" X-OriginalArrivalTime: 11 Aug 2010 10:42:08.0347 (UTC) FILETIME=[D8D1B2B0:01CB3941] Subject: [OAUTH-WG] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 11:20:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3941.D620D0ED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 Althought this request is only indirectly related to the OAuth protocol work I nevertheless think your input is valuable. We have just submitted a new version of the privacy and identity management terminology document: http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology-01. txt =20 The full document titel is "Terminology for Talking about Privacy by Data Minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management" and here is the abstract:=20 This document is an attempt to consolidate terminology in the field privacy by data minimization. It motivates and develops definitions for anonymity/identifiability, (un)linkability, (un)detectability, (un)observability, pseudonymity, identity, partial identity, digital identity and identity management. Starting the definitions from the anonymity and unlinkability perspective and not from a definition of identity (the latter is the obvious approach to some people) reveals some deeper structures in this field. =20 Please let us know whether the terminology is useful and complete. Your input is highly appreciated! Ciao Hannes ------_=_NextPart_001_01CB3941.D620D0ED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Feedback solicited for Privacy and Identity Management = Terminology

Hi all,

Althought this request is only = indirectly related to the OAuth protocol work I nevertheless think your = input is valuable. We have just submitted a new version of the privacy = and identity management terminology document:

http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology= -01.txt
 
The full document titel is = "Terminology for Talking about Privacy by Data Minimization: = Anonymity, Unlinkability, Undetectability, Unobservability, = Pseudonymity, and Identity Management" and here is the abstract: =

   This document is an = attempt to consolidate terminology in the field
   privacy by data = minimization.  It motivates and develops definitions
   for = anonymity/identifiability, (un)linkability, (un)detectability,
   (un)observability, = pseudonymity, identity, partial identity, digital
   identity and = identity management.  Starting the definitions from the
   anonymity and = unlinkability perspective and not from a definition of
   identity (the = latter is the obvious approach to some people) reveals
   some deeper = structures in this field.
  
Please let us know whether the = terminology is useful and complete. Your input is highly = appreciated!

Ciao
Hannes


------_=_NextPart_001_01CB3941.D620D0ED-- From torsten@lodderstedt.net Wed Aug 11 05:17:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 115403A6781 for ; Wed, 11 Aug 2010 05:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LebEPCeGEISo for ; Wed, 11 Aug 2010 05:17:21 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id 8FFF93A67AC for ; Wed, 11 Aug 2010 05:17:21 -0700 (PDT) Received: from [80.187.109.217] (helo=[10.165.72.207]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OjAFm-0007YM-SV; Wed, 11 Aug 2010 14:17:55 +0200 References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <9478CF67-EEC5-4C97-9929-408A8C6A877E@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 11 Aug 2010 14:17:09 +0200 To: Torsten Lodderstedt X-Df-Sender: 141509 Cc: OAuth WG , Maciej Machulak Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 12:17:23 -0000 Am 11.08.2010 um 12:40 schrieb Torsten Lodderstedt = : > Eve, >=20 > thank you for writting this document. I consider it a good starting point f= or a discussion about client registration and discovery. Will you propose th= is as a WG item? >=20 > My comments & questions: >=20 > You propose a host-meta based discovery of the registration endpoint on th= e authz server. Could this mechanism be used for discovering all AS endpoint= s, e.g. tokens and end-user authorization? >=20 > How is a UMA requestor envisioned to discover the auth server? >=20 > I think host-meta based client discovery could be to limited since it does= not allow (at least in my understanding) to serve different clients (or the= ir home web apps) on the same host. What about using JRD or XRD? This would a= llow for a client-URL-related discovery. I meant LRDD, seems I got lost in the discovery universe for a moment :-) I t= ook a look into the latest host-meta draft. host-meta processors seem to dir= ectly support LRDD. So everything is fine with me. regards, Torsten. >=20 > What means for authentication a client against its home web app. do you en= vision? >=20 > regards, > Torsten. >=20 > Am 10.08.2010 um 21:31 schrieb Eve Maler : >=20 >> Folks-- The UMA group has produced the following I-D as input to the OAut= h discovery/registration/binding discussion. We wanted to set forth our req= uirements (knowing that there may be other requirements from the wider commu= nity) and propose some solutions that meet them. If further discussion seem= s to warrant an updating of this draft, we're happy to do that. (If you hav= e interest in getting involved in UMA-specific work, feel free to drop me a n= ote.) >>=20 >> Eve >>=20 >> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >>=20 >> Begin forwarded message: >>=20 >>> From: IETF I-D Submission Tool >>> Date: 10 August 2010 12:23:59 PM PDT >>> To: eve@xmlgrrl.com >>> Cc: cs@comlounge.net, m.p.machulak@ncl.ac.uk >>> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00=20 >>>=20 >>>=20 >>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been successfull= y submitted by Eve Maler and posted to the IETF repository. >>>=20 >>> Filename: draft-oauth-dyn-reg-v1 >>> Revision: 00 >>> Title: OAuth Dynamic Client Registration Protocol >>> Creation_date: 2010-08-10 >>> WG ID: Independent Submission >>> Number_of_pages: 20 >>>=20 >>> Abstract: >>> This specification proposes an OAuth Dynamic Client Registration >>> protocol. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>=20 >>=20 >> Eve Maler >> http://www.xmlgrrl.com/blog >> http://www.twitter.com/xmlgrrl >> http://www.linkedin.com/in/evemaler >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lvh@laurensvh.be Wed Aug 11 06:24:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5694F3A690D for ; Wed, 11 Aug 2010 06:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.113 X-Spam-Level: X-Spam-Status: No, score=0.113 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kJWTihHe3Ig for ; Wed, 11 Aug 2010 06:24:27 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 57B5B3A6846 for ; Wed, 11 Aug 2010 06:24:27 -0700 (PDT) Received: by qyk29 with SMTP id 29so92825qyk.10 for ; Wed, 11 Aug 2010 06:25:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.54.140 with SMTP id q12mr10803297qag.319.1281533101954; Wed, 11 Aug 2010 06:25:01 -0700 (PDT) Received: by 10.229.21.9 with HTTP; Wed, 11 Aug 2010 06:25:01 -0700 (PDT) Date: Wed, 11 Aug 2010 15:25:01 +0200 Message-ID: From: Laurens Van Houtven To: OAuth WG Content-Type: text/plain; charset=UTF-8 Subject: [OAUTH-WG] Scope: why is the format predetermined? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 13:24:28 -0000 Hey, We have a use case for a scope that's more fine-grained/flexible than what you could explain in a set of space-delimited keywords. We would like to encode things like the precision with which some data can be accessed, and the scope sounds like the reasonable place to do that. Of course we can cheat by encoding eg JSON and escaping all the spaces to "\u0020" but that seems like an ugly workaround. Considering the spec says that the actual values of a scope are determined by the server, why does it dictate the *format*? Thanks in advance Laurens From lshepard@facebook.com Wed Aug 11 07:27:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F32B3A6405 for ; Wed, 11 Aug 2010 07:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.944 X-Spam-Level: X-Spam-Status: No, score=-100.944 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gRf-PE5MyG0 for ; Wed, 11 Aug 2010 07:27:30 -0700 (PDT) Received: from mx-out.facebook.com (outmail026.snc1.tfbnw.net [69.63.178.185]) by core3.amsl.com (Postfix) with ESMTP id 7C9303A695F for ; Wed, 11 Aug 2010 07:27:30 -0700 (PDT) Received: from [10.18.255.131] ([10.18.255.131:3363] helo=mail.thefacebook.com) by mta021.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 87/AB-21540-473B26C4; Wed, 11 Aug 2010 07:28:04 -0700 Received: from SC-MBX05.TheFacebook.com ([169.254.4.91]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Wed, 11 Aug 2010 07:28:03 -0700 From: Luke Shepard To: Laurens Van Houtven Thread-Topic: [OAUTH-WG] Scope: why is the format predetermined? Thread-Index: AQHLOVieSJXHC447iU6b003WzBrzKJLcxZSA Date: Wed, 11 Aug 2010 14:28:27 +0000 Message-ID: <24D1D8FA-51B7-4385-9008-0DEF7BB2A786@facebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <211f98f2-b425-445c-a781-53c6d92e0f92> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope: why is the format predetermined? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 14:27:35 -0000 Can you explain your use case a little more, and provide an example of why = the current system doesn't work for you? We have had numerous previous discussions about the format of scope, and th= e spec represents the consensus around how people plan to use them. http://www.ietf.org/mail-archive/web/oauth/current/msg03630.html On Aug 11, 2010, at 6:25 AM, Laurens Van Houtven wrote: > Hey, >=20 > We have a use case for a scope that's more fine-grained/flexible than > what you could explain in a set of space-delimited keywords. We would > like to encode things like the precision with which some data can be > accessed, and the scope sounds like the reasonable place to do that. >=20 > Of course we can cheat by encoding eg JSON and escaping all the spaces > to "\u0020" but that seems like an ugly workaround. >=20 > Considering the spec says that the actual values of a scope are > determined by the server, why does it dictate the *format*? >=20 >=20 > Thanks in advance > Laurens > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sDronia@gmx.de Wed Aug 11 07:35:53 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5F73A68ED for ; Wed, 11 Aug 2010 07:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.28 X-Spam-Level: * X-Spam-Status: No, score=1.28 tagged_above=-999 required=5 tests=[AWL=1.114, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6cNWphvEaJv for ; Wed, 11 Aug 2010 07:35:52 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id AA6A53A67EB for ; Wed, 11 Aug 2010 07:35:51 -0700 (PDT) Received: (qmail invoked by alias); 11 Aug 2010 14:36:25 -0000 Received: from tmo-098-116.customers.d1-online.com (EHLO [127.0.0.1]) [80.187.98.116] by mail.gmx.net (mp072) with SMTP; 11 Aug 2010 16:36:25 +0200 X-Authenticated: #3259608 X-Provags-ID: V01U2FsdGVkX19Mrj8YHIdMOtjn803XYZTHSsRsdq3NvPpJfkI6wV OiGMJPDurWu3ts Message-ID: <4C62B565.7020406@gmx.de> Date: Wed, 11 Aug 2010 16:36:21 +0200 From: Stefanie Dronia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: eve@xmlgrrl.com, oauth@ietf.org References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> In-Reply-To: <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 14:35:53 -0000 Hallo Eve, I read your proposal, too. Thanks for providing it. Some questions: # first part of chapter 2 # enchanced OAuth RS, AS and client are mentioned. Does the enhancement just denote, that they support dynamic client registration or have any further requirements to be fulfilled by them? # The text is "... use an access token in approximately the normal OAuth fashion,...": What do you mean by "approximately" in this context? As far as I understood, after client registration, OAuth flows are performed as defined. # For registration, the client has to give its URL (parameter client_url in registration request). May it be used later for OAuth callback url, e.g. if client registration with pushed metadata is selected? And just a typo: Example chapter 7.1: "url" instead of "client_url" is printed. Regards, Stefanie Am 10.08.2010 21:31, schrieb Eve Maler: > Folks-- The UMA group has produced the following I-D as input to the OAuth discovery/registration/binding discussion. We wanted to set forth our requirements (knowing that there may be other requirements from the wider community) and propose some solutions that meet them. If further discussion seems to warrant an updating of this draft, we're happy to do that. (If you have interest in getting involved in UMA-specific work, feel free to drop me a note.) > > Eve > > http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt > > Begin forwarded message: > > >> From: IETF I-D Submission Tool >> Date: 10 August 2010 12:23:59 PM PDT >> To:eve@xmlgrrl.com >> Cc:cs@comlounge.net,m.p.machulak@ncl.ac.uk >> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00 >> >> >> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been successfully submitted by Eve Maler and posted to the IETF repository. >> >> Filename: draft-oauth-dyn-reg-v1 >> Revision: 00 >> Title: OAuth Dynamic Client Registration Protocol >> Creation_date: 2010-08-10 >> WG ID: Independent Submission >> Number_of_pages: 20 >> >> Abstract: >> This specification proposes an OAuth Dynamic Client Registration >> protocol. >> >> >> >> The IETF Secretariat. >> >> >> > Eve Maler > http://www.xmlgrrl.com/blog > http://www.twitter.com/xmlgrrl > http://www.linkedin.com/in/evemaler > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From cs@comlounge.net Wed Aug 11 07:50:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4ED3A6989 for ; Wed, 11 Aug 2010 07:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.204 X-Spam-Level: X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_36=0.6, SARE_URI_CONS7=0.306] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4kMF1sCV1Ix for ; Wed, 11 Aug 2010 07:50:33 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id E1F203A6980 for ; Wed, 11 Aug 2010 07:50:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 40FBF1CE0344 for ; Wed, 11 Aug 2010 16:51:08 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKz55zOBhdt9 for ; Wed, 11 Aug 2010 16:51:07 +0200 (CEST) Received: from [192.168.2.113] (p5B391F3E.dip.t-dialin.net [91.57.31.62]) by post.comlounge.net (Postfix) with ESMTPSA id C9B3F1CE006E for ; Wed, 11 Aug 2010 16:51:07 +0200 (CEST) Message-ID: <4C62B8DB.1010409@comlounge.net> Date: Wed, 11 Aug 2010 16:51:07 +0200 From: Christian Scholz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: oauth@ietf.org References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 14:50:35 -0000 Hi! Thanks for the feedback! :-) Am 11.08.10 10:20, schrieb Lukas Rosenstock: > Nice to see this draft! > I've just read it and would like to provide some feedback: > > 1) redirect_url vs. redirect_uri: In different flows, different terms > have been used. I think that should be consistent and it should be uri. I agree, there is also a client_url which might also be client_uri then. > 2) Data formats for requests: This spec uses JSON for everything. The > core OAuth (draft 10) uses encoded forms for the request and JSON for > the response. Why not make it consistent with that? I don't see any > requirement to actually POST in JSON as well. Except maybe length. It might depend on how much metadata in the end will be transferred from client to server (eventually with a signature) but a good point indeed. > 3) The OpenID Connect proposal* includes something similar. For the > response, they have added a few more parameters along with client_id and > client_secret. To quote it: > - expires_in - The number of seconds that this id and secret are good > for or "0" if it does not expire. We have that in the push version but not in pull where it probably should be added. > - flows_supported - A comma separated list of the OAuth 2.0 flows which > this server supports. The server MUST support the Web server > (web_server) and User-Agent (user_agent) flows. > Don't you think those would be useful?! Also, so far there's no > information (or I didn't see it ...) on whether dynamic registration > should be considered temporary or permanent. I wonder if this should be part of the client registration response or maybe part of the general AS metadata as I assume it's more of a global attribute and not one per client. As for temporary/permanent wouldn't the server decide based on the expires_in attribute? In UMA though we are probably more interesting in long term relationships to be able to identify clients over time. cheers, Christian > > Thanks and regards, > Lukas Rosenstock > > [*] http://openidconnect.com/ > > > 2010/8/10 Eve Maler > > > Folks-- The UMA group has produced the following I-D as input to the > OAuth discovery/registration/binding discussion. We wanted to set > forth our requirements (knowing that there may be other requirements > from the wider community) and propose some solutions that meet them. > If further discussion seems to warrant an updating of this draft, > we're happy to do that. (If you have interest in getting involved > in UMA-specific work, feel free to drop me a note.) > > Eve > > http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH http://mrtopf.de/blog Hanbrucher Str. 33 http://twitter.com/mrtopf 52064 Aachen Skype: HerrTopf Tel: +49 241 400 730 0 cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf Podcasts: Der OpenWeb-Podcast (http://openwebpodcast.de) Data Without Borders (http://datawithoutborders.net) Politisches: http://politfunk.de/ Technical: http://comlounge.tv/ From cs@comlounge.net Wed Aug 11 08:12:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BFF3A687A for ; Wed, 11 Aug 2010 08:12:37 -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=[AWL=0.495, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAMlw4254sTu for ; Wed, 11 Aug 2010 08:12:36 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id C419A3A6902 for ; Wed, 11 Aug 2010 08:12:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 728031CE0344 for ; Wed, 11 Aug 2010 17:13:10 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grLSvdLzYElK for ; Wed, 11 Aug 2010 17:13:10 +0200 (CEST) Received: from [192.168.2.113] (p5B391F3E.dip.t-dialin.net [91.57.31.62]) by post.comlounge.net (Postfix) with ESMTPSA id E8EEA1CE006E for ; Wed, 11 Aug 2010 17:13:09 +0200 (CEST) Message-ID: <4C62BE05.8030301@comlounge.net> Date: Wed, 11 Aug 2010 17:13:09 +0200 From: Christian Scholz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: oauth@ietf.org References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 15:12:38 -0000 Hi! Am 11.08.10 12:40, schrieb Torsten Lodderstedt: > Eve, > > thank you for writting this document. I consider it a good starting > point for a discussion about client registration and discovery. Will > you propose this as a WG item? I think that's the plan as it is more related more to OAuth in genral than UMA specific. > My comments & questions: > > You propose a host-meta based discovery of the registration endpoint > on the authz server. Could this mechanism be used for discovering all > AS endpoints, e.g. tokens and end-user authorization? I would think so. We concentrated more on the one endpoint we need but it makes sense to discover all of the necessary endpoints that way. So some merge of ideas floating here about general discovery might be useful. > How is a UMA requestor envisioned to discover the auth server? On the Host side the user can tell it which AM (in UMA terms it's an Authorization Manager, some sort of extended AS) to use or it might be discovered via webfinger or similar means. The process for requesters is up to discussion a bit right now. In my prototype the Host is telling the Requester which AM is registered to the resource it tries to access. Then client registration can start from there. > I think host-meta based client discovery could be to limited since it > does not allow (at least in my understanding) to serve different > clients (or their home web apps) on the same host. What about using > JRD or XRD? This would allow for a client-URL-related discovery. You are right. The question here might be if the LRDD part is being used or if maybe directly point to the client spec which would save one redirection. Not sure if we need to add a type field in this case, too (e.g. if JRD or XRD). I would favour to use only one format (JRD) though. -- Christian > What means for authentication a client against its home web app. do > you envision? > > regards, Torsten. > > Am 10.08.2010 um 21:31 schrieb Eve Maler : > >> Folks-- The UMA group has produced the following I-D as input to >> the OAuth discovery/registration/binding discussion. We wanted to >> set forth our requirements (knowing that there may be other >> requirements from the wider community) and propose some solutions >> that meet them. If further discussion seems to warrant an updating >> of this draft, we're happy to do that. (If you have interest in >> getting involved in UMA-specific work, feel free to drop me a >> note.) >> >> Eve >> >> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool Date: 10 >>> August 2010 12:23:59 PM PDT To: eve@xmlgrrl.com Cc: >>> cs@comlounge.net, m.p.machulak@ncl.ac.uk Subject: New Version >>> Notification for draft-oauth-dyn-reg-v1-00 >>> >>> >>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been >>> successfully submitted by Eve Maler and posted to the IETF >>> repository. >>> >>> Filename: draft-oauth-dyn-reg-v1 Revision: 00 Title: >>> OAuth Dynamic Client Registration Protocol Creation_date: >>> 2010-08-10 WG ID: Independent Submission Number_of_pages: >>> 20 >>> >>> Abstract: This specification proposes an OAuth Dynamic Client >>> Registration protocol. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> >> Eve Maler http://www.xmlgrrl.com/blog >> http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler >> >> _______________________________________________ OAuth mailing list >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list > OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH http://mrtopf.de/blog Hanbrucher Str. 33 http://twitter.com/mrtopf 52064 Aachen Skype: HerrTopf Tel: +49 241 400 730 0 cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf Podcasts: Der OpenWeb-Podcast (http://openwebpodcast.de) Data Without Borders (http://datawithoutborders.net) Politisches: http://politfunk.de/ Technical: http://comlounge.tv/ From torsten@lodderstedt.net Wed Aug 11 08:32:08 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05B843A693D for ; Wed, 11 Aug 2010 08:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRhe2Wf4pZbR for ; Wed, 11 Aug 2010 08:32:07 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id A8AE53A693A for ; Wed, 11 Aug 2010 08:32:06 -0700 (PDT) Received: from [80.187.109.217] (helo=[10.165.72.207]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OjDIE-0005Z7-F7; Wed, 11 Aug 2010 17:32:41 +0200 References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> <4C62BE05.8030301@comlounge.net> In-Reply-To: <4C62BE05.8030301@comlounge.net> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 11 Aug 2010 17:31:52 +0200 To: Christian Scholz X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 15:32:08 -0000 >> >> > >> How is a UMA requestor envisioned to discover the auth server? > > On the Host side the user can tell it which AM (in UMA terms it's an > Authorization Manager, some sort of extended AS) to use or it might be > discovered via webfinger or similar means. > > The process for requesters is up to discussion a bit right now. In my > prototype the Host is telling the Requester which AM is registered to > the resource it tries to access. Then client registration can start from > there. How does the Host tell the requester? I would imagine using host-meta, too. regards, Torsten. > >> I think host-meta based client discovery could be to limited since it >> does not allow (at least in my understanding) to serve different >> clients (or their home web apps) on the same host. What about using >> JRD or XRD? This would allow for a client-URL-related discovery. > > You are right. The question here might be if the LRDD part is being used > or if maybe directly point to the client spec which would save one > redirection. Not sure if we need to add a type field in this case, too > (e.g. if JRD or XRD). I would favour to use only one format (JRD) though. > > > -- Christian > >> What means for authentication a client against its home web app. do >> you envision? >> >> regards, Torsten. >> >> Am 10.08.2010 um 21:31 schrieb Eve Maler : >> >>> Folks-- The UMA group has produced the following I-D as input to >>> the OAuth discovery/registration/binding discussion. We wanted to >>> set forth our requirements (knowing that there may be other >>> requirements from the wider community) and propose some solutions >>> that meet them. If further discussion seems to warrant an updating >>> of this draft, we're happy to do that. (If you have interest in >>> getting involved in UMA-specific work, feel free to drop me a >>> note.) >>> >>> Eve >>> >>> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >>> >>> Begin forwarded message: >>> >>>> From: IETF I-D Submission Tool Date: 10 >>>> August 2010 12:23:59 PM PDT To: eve@xmlgrrl.com Cc: >>>> cs@comlounge.net, m.p.machulak@ncl.ac.uk Subject: New Version >>>> Notification for draft-oauth-dyn-reg-v1-00 >>>> >>>> >>>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been >>>> successfully submitted by Eve Maler and posted to the IETF >>>> repository. >>>> >>>> Filename: draft-oauth-dyn-reg-v1 Revision: 00 Title: >>>> OAuth Dynamic Client Registration Protocol Creation_date: >>>> 2010-08-10 WG ID: Independent Submission Number_of_pages: >>>> 20 >>>> >>>> Abstract: This specification proposes an OAuth Dynamic Client >>>> Registration protocol. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>> >>> >>> Eve Maler http://www.xmlgrrl.com/blog >>> http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler >>> >>> _______________________________________________ OAuth mailing list >>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ OAuth mailing list >> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth > > > -- > Christian Scholz Homepage: http://comlounge.net > COM.lounge GmbH http://mrtopf.de/blog > Hanbrucher Str. 33 http://twitter.com/mrtopf > 52064 Aachen Skype: HerrTopf > Tel: +49 241 400 730 0 cs@comlounge.net > Fax: +49 241 979 00 850 IRC: MrTopf > > Podcasts: > Der OpenWeb-Podcast (http://openwebpodcast.de) > Data Without Borders (http://datawithoutborders.net) > Politisches: http://politfunk.de/ > Technical: http://comlounge.tv/ > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From cs@comlounge.net Wed Aug 11 08:40:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A977F3A698A for ; Wed, 11 Aug 2010 08:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.946 X-Spam-Level: X-Spam-Status: No, score=-0.946 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 635EsFdLn5Ed for ; Wed, 11 Aug 2010 08:40:06 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 0A9B03A67E7 for ; Wed, 11 Aug 2010 08:40:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 45B501CE0425; Wed, 11 Aug 2010 17:40:41 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvpDTnawdwsd; Wed, 11 Aug 2010 17:40:40 +0200 (CEST) Received: from [192.168.2.113] (p5B391F3E.dip.t-dialin.net [91.57.31.62]) by post.comlounge.net (Postfix) with ESMTPSA id E3ACE1CE006E; Wed, 11 Aug 2010 17:40:39 +0200 (CEST) Message-ID: <4C62C476.1010405@comlounge.net> Date: Wed, 11 Aug 2010 17:40:38 +0200 From: Christian Scholz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Torsten Lodderstedt References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> <4C62BE05.8030301@comlounge.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 15:40:07 -0000 Am 11.08.10 17:31, schrieb Torsten Lodderstedt: > >>> >>> >> >>> How is a UMA requestor envisioned to discover the auth server? >> >> On the Host side the user can tell it which AM (in UMA terms it's an >> Authorization Manager, some sort of extended AS) to use or it might be >> discovered via webfinger or similar means. >> >> The process for requesters is up to discussion a bit right now. In my >> prototype the Host is telling the Requester which AM is registered to >> the resource it tries to access. Then client registration can start from >> there. > > How does the Host tell the requester? I would imagine using host-meta, too. The URI of the AM's resource token endpoint is included in the WWW-Authenticate header. From there on it's host-meta discovery for all necessary data. So yes. (and the Host knows which AM to include because it knows which resource was registered with which AM) Very rough version: http://mrtopf.clprojects.net/uma/draft-uma-core.html#anchor9 -- Christian > > regards, > Torsten. > >> >>> I think host-meta based client discovery could be to limited since it >>> does not allow (at least in my understanding) to serve different >>> clients (or their home web apps) on the same host. What about using >>> JRD or XRD? This would allow for a client-URL-related discovery. >> >> You are right. The question here might be if the LRDD part is being used >> or if maybe directly point to the client spec which would save one >> redirection. Not sure if we need to add a type field in this case, too >> (e.g. if JRD or XRD). I would favour to use only one format (JRD) though. >> >> >> -- Christian >> >>> What means for authentication a client against its home web app. do >>> you envision? >>> >>> regards, Torsten. >>> >>> Am 10.08.2010 um 21:31 schrieb Eve Maler : >>> >>>> Folks-- The UMA group has produced the following I-D as input to >>>> the OAuth discovery/registration/binding discussion. We wanted to >>>> set forth our requirements (knowing that there may be other >>>> requirements from the wider community) and propose some solutions >>>> that meet them. If further discussion seems to warrant an updating >>>> of this draft, we're happy to do that. (If you have interest in >>>> getting involved in UMA-specific work, feel free to drop me a >>>> note.) >>>> >>>> Eve >>>> >>>> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >>>> >>>> Begin forwarded message: >>>> >>>>> From: IETF I-D Submission Tool Date: 10 >>>>> August 2010 12:23:59 PM PDT To: eve@xmlgrrl.com Cc: >>>>> cs@comlounge.net, m.p.machulak@ncl.ac.uk Subject: New Version >>>>> Notification for draft-oauth-dyn-reg-v1-00 >>>>> >>>>> >>>>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been >>>>> successfully submitted by Eve Maler and posted to the IETF >>>>> repository. >>>>> >>>>> Filename: draft-oauth-dyn-reg-v1 Revision: 00 Title: >>>>> OAuth Dynamic Client Registration Protocol Creation_date: >>>>> 2010-08-10 WG ID: Independent Submission Number_of_pages: >>>>> 20 >>>>> >>>>> Abstract: This specification proposes an OAuth Dynamic Client >>>>> Registration protocol. >>>>> >>>>> >>>>> >>>>> The IETF Secretariat. >>>>> >>>>> >>>> >>>> >>>> Eve Maler http://www.xmlgrrl.com/blog >>>> http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler >>>> >>>> _______________________________________________ OAuth mailing list >>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ OAuth mailing list >>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >> >> >> -- >> Christian Scholz Homepage: http://comlounge.net >> COM.lounge GmbH http://mrtopf.de/blog >> Hanbrucher Str. 33 http://twitter.com/mrtopf >> 52064 Aachen Skype: HerrTopf >> Tel: +49 241 400 730 0 cs@comlounge.net >> Fax: +49 241 979 00 850 IRC: MrTopf >> >> Podcasts: >> Der OpenWeb-Podcast (http://openwebpodcast.de) >> Data Without Borders (http://datawithoutborders.net) >> Politisches: http://politfunk.de/ >> Technical: http://comlounge.tv/ >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH http://mrtopf.de/blog Hanbrucher Str. 33 http://twitter.com/mrtopf 52064 Aachen Skype: HerrTopf Tel: +49 241 400 730 0 cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf Podcasts: Der OpenWeb-Podcast (http://openwebpodcast.de) Data Without Borders (http://datawithoutborders.net) Politisches: http://politfunk.de/ Technical: http://comlounge.tv/ From torsten@lodderstedt.net Wed Aug 11 08:45:17 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5742A3A69DD for ; Wed, 11 Aug 2010 08:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7uQEHGh03s2 for ; Wed, 11 Aug 2010 08:45:16 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id 077F43A6922 for ; Wed, 11 Aug 2010 08:45:15 -0700 (PDT) Received: from [80.187.109.217] (helo=[10.165.72.207]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OjDV0-0007f4-Ic; Wed, 11 Aug 2010 17:45:51 +0200 References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> <4C62BE05.8030301@comlounge.net> <4C62C476.1010405@comlounge.net> In-Reply-To: <4C62C476.1010405@comlounge.net> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 11 Aug 2010 17:45:05 +0200 To: Christian Scholz X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 15:45:17 -0000 Am 11.08.2010 um 17:40 schrieb Christian Scholz : > Am 11.08.10 17:31, schrieb Torsten Lodderstedt: >>=20 >>>>=20 >>>>=20 >>>=20 >>>> How is a UMA requestor envisioned to discover the auth server? >>>=20 >>> On the Host side the user can tell it which AM (in UMA terms it's an >>> Authorization Manager, some sort of extended AS) to use or it might be >>> discovered via webfinger or similar means. >>>=20 >>> The process for requesters is up to discussion a bit right now. In my >>> prototype the Host is telling the Requester which AM is registered to >>> the resource it tries to access. Then client registration can start from= >>> there. >>=20 >> How does the Host tell the requester? I would imagine using host-meta, to= o. >=20 > The URI of the AM's resource token endpoint is included in the > WWW-Authenticate header. =46rom there on it's host-meta discovery for all > necessary data. So yes. >=20 > (and the Host knows which AM to include because it knows which resource > was registered with which AM) >=20 > Very rough version: > http://mrtopf.clprojects.net/uma/draft-uma-core.html#anchor9 >=20 >=20 > -- Christian >=20 >=20 >=20 >=20 >>=20 >> regards, >> Torsten. >>=20 >>>=20 >>>> I think host-meta based client discovery could be to limited since it >>>> does not allow (at least in my understanding) to serve different >>>> clients (or their home web apps) on the same host. What about using >>>> JRD or XRD? This would allow for a client-URL-related discovery. >>>=20 >>> You are right. The question here might be if the LRDD part is being used= >>> or if maybe directly point to the client spec which would save one >>> redirection. Not sure if we need to add a type field in this case, too >>> (e.g. if JRD or XRD). I would favour to use only one format (JRD) though= . >>>=20 >>>=20 >>> -- Christian >>>=20 >>>> What means for authentication a client against its home web app. do >>>> you envision? >>>>=20 >>>> regards, Torsten. >>>>=20 >>>> Am 10.08.2010 um 21:31 schrieb Eve Maler : >>>>=20 >>>>> Folks-- The UMA group has produced the following I-D as input to >>>>> the OAuth discovery/registration/binding discussion. We wanted to >>>>> set forth our requirements (knowing that there may be other >>>>> requirements from the wider community) and propose some solutions >>>>> that meet them. If further discussion seems to warrant an updating >>>>> of this draft, we're happy to do that. (If you have interest in >>>>> getting involved in UMA-specific work, feel free to drop me a >>>>> note.) >>>>>=20 >>>>> Eve >>>>>=20 >>>>> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: IETF I-D Submission Tool Date: 10 >>>>>> August 2010 12:23:59 PM PDT To: eve@xmlgrrl.com Cc: >>>>>> cs@comlounge.net, m.p.machulak@ncl.ac.uk Subject: New Version >>>>>> Notification for draft-oauth-dyn-reg-v1-00 >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been >>>>>> successfully submitted by Eve Maler and posted to the IETF >>>>>> repository. >>>>>>=20 >>>>>> Filename: draft-oauth-dyn-reg-v1 Revision: 00 Title: >>>>>> OAuth Dynamic Client Registration Protocol Creation_date: >>>>>> 2010-08-10 WG ID: Independent Submission Number_of_pages: >>>>>> 20 >>>>>>=20 >>>>>> Abstract: This specification proposes an OAuth Dynamic Client >>>>>> Registration protocol. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF Secretariat. >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> Eve Maler http://www.xmlgrrl.com/blog=20 >>>>> http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler >>>>>=20 >>>>> _______________________________________________ OAuth mailing list=20 >>>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ OAuth mailing list=20 >>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> --=20 >>> Christian Scholz Homepage: http://comlounge.net= >>> COM.lounge GmbH http://mrtopf.de/blog= >>> Hanbrucher Str. 33 http://twitter.com/mrtopf= >>> 52064 Aachen Skype: HerrTopf= >>> Tel: +49 241 400 730 0 cs@comlounge.net= >>> Fax: +49 241 979 00 850 IRC: MrTopf= >>>=20 >>> Podcasts: >>> Der OpenWeb-Podcast (http://openwebpodcast.de) >>> Data Without Borders (http://datawithoutborders.net) >>> Politisches: http://politfunk.de/ >>> Technical: http://comlounge.tv/ >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > Christian Scholz Homepage: http://comlounge.net > COM.lounge GmbH http://mrtopf.de/blog > Hanbrucher Str. 33 http://twitter.com/mrtopf > 52064 Aachen Skype: HerrTopf > Tel: +49 241 400 730 0 cs@comlounge.net > Fax: +49 241 979 00 850 IRC: MrTopf >=20 > Podcasts: > Der OpenWeb-Podcast (http://openwebpodcast.de) > Data Without Borders (http://datawithoutborders.net) > Politisches: http://politfunk.de/ > Technical: http://comlounge.tv/ From torsten@lodderstedt.net Wed Aug 11 08:47:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6355B3A6803 for ; Wed, 11 Aug 2010 08:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=-0.564, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_36=0.6, MIME_QP_LONG_LINE=1.396, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYb96U+0abPa for ; Wed, 11 Aug 2010 08:47:55 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by core3.amsl.com (Postfix) with ESMTP id E933C3A689C for ; Wed, 11 Aug 2010 08:47:54 -0700 (PDT) Received: from [80.187.109.217] (helo=[10.165.72.207]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OjDXY-0005IY-PB; Wed, 11 Aug 2010 17:48:29 +0200 References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> <4C62BE05.8030301@comlounge.net> <4C62C476.1010405@comlounge.net> In-Reply-To: <4C62C476.1010405@comlounge.net> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8D62B3A5-075F-48C2-A7F1-48B44AEEE306@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 11 Aug 2010 17:47:45 +0200 To: Christian Scholz X-Df-Sender: 141509 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 15:47:56 -0000 Am 11.08.2010 um 17:40 schrieb Christian Scholz : > Am 11.08.10 17:31, schrieb Torsten Lodderstedt: >>=20 >>>>=20 >>>>=20 >>>=20 >>>> How is a UMA requestor envisioned to discover the auth server? >>>=20 >>> On the Host side the user can tell it which AM (in UMA terms it's an >>> Authorization Manager, some sort of extended AS) to use or it might be >>> discovered via webfinger or similar means. >>>=20 >>> The process for requesters is up to discussion a bit right now. In my >>> prototype the Host is telling the Requester which AM is registered to >>> the resource it tries to access. Then client registration can start from= >>> there. >>=20 >> How does the Host tell the requester? I would imagine using host-meta, to= o. >=20 > The URI of the AM's resource token endpoint is included in the > WWW-Authenticate header. =46rom there on it's host-meta discovery for all > necessary data. So yes. >=20 > (and the Host knows which AM to include because it knows which resource > was registered with which AM) >=20 > Very rough version: > http://mrtopf.clprojects.net/uma/draft-uma-core.html#anchor9 >=20 So sending an unauthorized request is the only way to discover the AM? regards, Torsten. >=20 > -- Christian >=20 >=20 >=20 >=20 >>=20 >> regards, >> Torsten. >>=20 >>>=20 >>>> I think host-meta based client discovery could be to limited since it >>>> does not allow (at least in my understanding) to serve different >>>> clients (or their home web apps) on the same host. What about using >>>> JRD or XRD? This would allow for a client-URL-related discovery. >>>=20 >>> You are right. The question here might be if the LRDD part is being used= >>> or if maybe directly point to the client spec which would save one >>> redirection. Not sure if we need to add a type field in this case, too >>> (e.g. if JRD or XRD). I would favour to use only one format (JRD) though= . >>>=20 >>>=20 >>> -- Christian >>>=20 >>>> What means for authentication a client against its home web app. do >>>> you envision? >>>>=20 >>>> regards, Torsten. >>>>=20 >>>> Am 10.08.2010 um 21:31 schrieb Eve Maler : >>>>=20 >>>>> Folks-- The UMA group has produced the following I-D as input to >>>>> the OAuth discovery/registration/binding discussion. We wanted to >>>>> set forth our requirements (knowing that there may be other >>>>> requirements from the wider community) and propose some solutions >>>>> that meet them. If further discussion seems to warrant an updating >>>>> of this draft, we're happy to do that. (If you have interest in >>>>> getting involved in UMA-specific work, feel free to drop me a >>>>> note.) >>>>>=20 >>>>> Eve >>>>>=20 >>>>> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >>>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>>> From: IETF I-D Submission Tool Date: 10 >>>>>> August 2010 12:23:59 PM PDT To: eve@xmlgrrl.com Cc: >>>>>> cs@comlounge.net, m.p.machulak@ncl.ac.uk Subject: New Version >>>>>> Notification for draft-oauth-dyn-reg-v1-00 >>>>>>=20 >>>>>>=20 >>>>>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been >>>>>> successfully submitted by Eve Maler and posted to the IETF >>>>>> repository. >>>>>>=20 >>>>>> Filename: draft-oauth-dyn-reg-v1 Revision: 00 Title: >>>>>> OAuth Dynamic Client Registration Protocol Creation_date: >>>>>> 2010-08-10 WG ID: Independent Submission Number_of_pages: >>>>>> 20 >>>>>>=20 >>>>>> Abstract: This specification proposes an OAuth Dynamic Client >>>>>> Registration protocol. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The IETF Secretariat. >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> Eve Maler http://www.xmlgrrl.com/blog=20 >>>>> http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler >>>>>=20 >>>>> _______________________________________________ OAuth mailing list=20 >>>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ OAuth mailing list=20 >>>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> --=20 >>> Christian Scholz Homepage: http://comlounge.net= >>> COM.lounge GmbH http://mrtopf.de/blog= >>> Hanbrucher Str. 33 http://twitter.com/mrtopf= >>> 52064 Aachen Skype: HerrTopf= >>> Tel: +49 241 400 730 0 cs@comlounge.net= >>> Fax: +49 241 979 00 850 IRC: MrTopf= >>>=20 >>> Podcasts: >>> Der OpenWeb-Podcast (http://openwebpodcast.de) >>> Data Without Borders (http://datawithoutborders.net) >>> Politisches: http://politfunk.de/ >>> Technical: http://comlounge.tv/ >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > --=20 > Christian Scholz Homepage: http://comlounge.net > COM.lounge GmbH http://mrtopf.de/blog > Hanbrucher Str. 33 http://twitter.com/mrtopf > 52064 Aachen Skype: HerrTopf > Tel: +49 241 400 730 0 cs@comlounge.net > Fax: +49 241 979 00 850 IRC: MrTopf >=20 > Podcasts: > Der OpenWeb-Podcast (http://openwebpodcast.de) > Data Without Borders (http://datawithoutborders.net) > Politisches: http://politfunk.de/ > Technical: http://comlounge.tv/ From cs@comlounge.net Wed Aug 11 09:21:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1663A635F for ; Wed, 11 Aug 2010 09:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkwDZ-k+njUo for ; Wed, 11 Aug 2010 09:21:41 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id DFB293A69A2 for ; Wed, 11 Aug 2010 09:21:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id EFFDA1CE006E for ; Wed, 11 Aug 2010 18:22:15 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtM7qMtFC0Jo for ; Wed, 11 Aug 2010 18:22:15 +0200 (CEST) Received: from [192.168.2.113] (p5B391F3E.dip.t-dialin.net [91.57.31.62]) by post.comlounge.net (Postfix) with ESMTPSA id 6D94A1CE0562 for ; Wed, 11 Aug 2010 18:22:15 +0200 (CEST) Message-ID: <4C62CE36.9090003@comlounge.net> Date: Wed, 11 Aug 2010 18:22:14 +0200 From: Christian Scholz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.7) Gecko/20100713 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: oauth@ietf.org References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> <4C62B565.7020406@gmx.de> In-Reply-To: <4C62B565.7020406@gmx.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 16:21:42 -0000 Hi! Am 11.08.10 16:36, schrieb Stefanie Dronia: > Hallo Eve, > > I read your proposal, too. Thanks for providing it. > > Some questions: > # first part of chapter 2 > # enchanced OAuth RS, AS and client are mentioned. Does the > enhancement just denote, that they support dynamic client registration > or have any further requirements to be fulfilled by them? These are mostly examples from the User Managed Access (UMA) Working Group where we use components which have to do a bit more than simple OAuth. Out of this came the need for dynamic client registration which we thought might be useful in other OAuth contexts as well. So regarding the actual client registration they do not need to have further requirements other than the client registration capabilities described. In the final version we might want to get rid of the UMA specific text in order to prevent confusion. > # The text is "... use an access token in approximately the normal > OAuth fashion,...": What do you mean by "approximately" in this context? > As far as I understood, after client registration, OAuth flows are > performed as defined. Yes, again this relates to our UMA use cases where later on (after client registration) those components need to do a bit more. For this spec though this is irrelevant. > # For registration, the client has to give its URL (parameter client_url > in registration request). May it be used later for OAuth callback url, > e.g. if client registration with pushed metadata is selected? Those parameters basically should represent what you otherwise would enter into a registration form like http://dev.twitter.com/apps/new Thus there probably need to be more fields in there but website url (or client_url) and callback_url should probably be 2 different attributes. The question regarding the client metadata is how much information really is needed. For manual registration the server can ask as much as it wants. For automatic registration I would like some basic set of attributes, some maybe being optional. The question might be which ones to take. > And just a typo: Example chapter 7.1: "url" instead of "client_url" is > printed. Right, thanks! -- Christian > > Regards, > Stefanie > > Am 10.08.2010 21:31, schrieb Eve Maler: >> Folks-- The UMA group has produced the following I-D as input to the >> OAuth discovery/registration/binding discussion. We wanted to set >> forth our requirements (knowing that there may be other requirements >> from the wider community) and propose some solutions that meet them. >> If further discussion seems to warrant an updating of this draft, >> we're happy to do that. (If you have interest in getting involved in >> UMA-specific work, feel free to drop me a note.) >> >> Eve >> >> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >> >> Begin forwarded message: >> >> >>> From: IETF I-D Submission Tool >>> Date: 10 August 2010 12:23:59 PM PDT >>> To:eve@xmlgrrl.com >>> Cc:cs@comlounge.net,m.p.machulak@ncl.ac.uk >>> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00 >>> >>> >>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been >>> successfully submitted by Eve Maler and posted to the IETF repository. >>> >>> Filename: draft-oauth-dyn-reg-v1 >>> Revision: 00 >>> Title: OAuth Dynamic Client Registration Protocol >>> Creation_date: 2010-08-10 >>> WG ID: Independent Submission >>> Number_of_pages: 20 >>> >>> Abstract: >>> This specification proposes an OAuth Dynamic Client Registration >>> protocol. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >>> >> Eve Maler >> http://www.xmlgrrl.com/blog >> http://www.twitter.com/xmlgrrl >> http://www.linkedin.com/in/evemaler >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH http://mrtopf.de/blog Hanbrucher Str. 33 http://twitter.com/mrtopf 52064 Aachen Skype: HerrTopf Tel: +49 241 400 730 0 cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf Podcasts: Der OpenWeb-Podcast (http://openwebpodcast.de) Data Without Borders (http://datawithoutborders.net) Politisches: http://politfunk.de/ Technical: http://comlounge.tv/ From igor.faynberg@alcatel-lucent.com Wed Aug 11 09:30:14 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C75E3A6A6D for ; Wed, 11 Aug 2010 09:30:14 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNz8T2RS4l0C for ; Wed, 11 Aug 2010 09:30:13 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 7A2DA3A6A2E for ; Wed, 11 Aug 2010 09:30:10 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o7BGUkfC025865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2010 11:30:46 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o7BGUkW2023004; Wed, 11 Aug 2010 11:30:46 -0500 (CDT) Message-ID: <4C62D035.5080403@alcatel-lucent.com> Date: Wed, 11 Aug 2010 12:30:45 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B4502E5D297@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E5D297@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: OAuth WG Subject: Re: [OAUTH-WG] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 16:30:14 -0000 Hannes, This is indeed a very good idea! ITU has been developing the IdM terminology for some time, so this document should prompt the discussion and -- let us hope!-- the alignment of normative terminology. With thanks, Igor Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Hi all, > > Althought this request is only indirectly related to the OAuth > protocol work I nevertheless think your input is valuable. We have > just submitted a new version of the privacy and identity management > terminology document: > > _http://www.ietf.org/internet-drafts/draft-hansen-privacy-terminology-01.txt_ > > > The full document titel is "Terminology for Talking about Privacy by > Data Minimization: Anonymity, Unlinkability, Undetectability, > Unobservability, Pseudonymity, and Identity Management" and here is > the abstract: > > This document is an attempt to consolidate terminology in the field > privacy by data minimization. It motivates and develops definitions > for anonymity/identifiability, (un)linkability, (un)detectability, > (un)observability, pseudonymity, identity, partial identity, digital > identity and identity management. Starting the definitions from the > anonymity and unlinkability perspective and not from a definition of > identity (the latter is the obvious approach to some people) reveals > some deeper structures in this field. > > Please let us know whether the terminology is useful and complete. > Your input is highly appreciated! > > Ciao > Hannes > > > ------------------------------------------------------------------------ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From hannes.tschofenig@nsn.com Wed Aug 11 10:01:43 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740683A6981 for ; Wed, 11 Aug 2010 10:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu0x9rPfhtRY for ; Wed, 11 Aug 2010 10:01:42 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id BEB313A67D9 for ; Wed, 11 Aug 2010 10:01:41 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7BH21pG005149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Aug 2010 19:02:01 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7BH20Lr015600; Wed, 11 Aug 2010 19:02:01 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 19:01:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Aug 2010 20:01:36 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502E5D591@FIESEXC015.nsn-intra.net> In-Reply-To: <4C62D035.5080403@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Feedback solicited for Privacy and Identity Management Terminology Thread-Index: Acs5cpHH1Rt3kefhTnuQ/uCFab0qGAABECBQ References: <3D3C75174CB95F42AD6BCC56E5555B4502E5D297@FIESEXC015.nsn-intra.net> <4C62D035.5080403@alcatel-lucent.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 11 Aug 2010 17:01:38.0012 (UTC) FILETIME=[DC98D9C0:01CB3976] Cc: OAuth WG Subject: Re: [OAUTH-WG] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 17:01:43 -0000 I am not aware of the ITU-T terminology. Are the documents publically available? =20 > -----Original Message----- > From: ext Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com]=20 > Sent: Wednesday, August 11, 2010 7:31 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Feedback solicited for Privacy and=20 > Identity Management Terminology >=20 > Hannes, >=20 > This is indeed a very good idea! >=20 > ITU has been developing the IdM terminology for some time, so this=20 > document should prompt the discussion and -- let us hope!-- the=20 > alignment of normative terminology. >=20 > With thanks, >=20 > Igor >=20 > Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > > > Hi all, > > > > Althought this request is only indirectly related to the OAuth=20 > > protocol work I nevertheless think your input is valuable. We have=20 > > just submitted a new version of the privacy and identity management=20 > > terminology document: > > > >=20 > _http://www.ietf.org/internet-drafts/draft-hansen-privacy-term > inology-01.txt_=20 > > > > =20 > > The full document titel is "Terminology for Talking about=20 > Privacy by=20 > > Data Minimization: Anonymity, Unlinkability, Undetectability,=20 > > Unobservability, Pseudonymity, and Identity Management" and here is=20 > > the abstract: > > > > This document is an attempt to consolidate terminology=20 > in the field > > privacy by data minimization. It motivates and develops=20 > definitions > > for anonymity/identifiability, (un)linkability,=20 > (un)detectability, > > (un)observability, pseudonymity, identity, partial=20 > identity, digital > > identity and identity management. Starting the=20 > definitions from the > > anonymity and unlinkability perspective and not from a=20 > definition of > > identity (the latter is the obvious approach to some=20 > people) reveals > > some deeper structures in this field. > > =20 > > Please let us know whether the terminology is useful and complete.=20 > > Your input is highly appreciated! > > > > Ciao > > Hannes > > > > > >=20 > -------------------------------------------------------------- > ---------- > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > =20 >=20 From eve@xmlgrrl.com Wed Aug 11 10:12:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584683A6981 for ; Wed, 11 Aug 2010 10:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zKZy1sZrVY6 for ; Wed, 11 Aug 2010 10:11:58 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 920F528C0F0 for ; Wed, 11 Aug 2010 10:11:55 -0700 (PDT) Received: from [172.19.131.151] ([12.130.106.87]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o7BHCQvR001442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Aug 2010 10:12:30 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: Date: Wed, 11 Aug 2010 10:12:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1267A363-D0A9-49D8-B95B-F21D8D891603@xmlgrrl.com> References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> To: OAuth WG X-Mailer: Apple Mail (2.1081) Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 17:12:02 -0000 Great comments; thanks to Christian for responding. To answer just a = couple of more points that I don't think got addressed yet: Yes, we would very much like for dynamic client registration to become a = work item of this group. (Do we need to take any steps other than = stating so in this email?) And, I've written to this list a couple of times in the past, describing = ways in which UMA builds on top of OAuth (it's basically a series of = profiles and extensions, any of which I'm willing to believe might have = value to a wider community on its own), but it seems like a summary at = this juncture would be a good idea. If OAuth has two steps, "get a = token" and "use a token", UMA has three, adding one at the beginning: - Step 1: trust a token: Authorizing user introduces host to = authorization manager as an OAuth client of it. The host and AM need to = acquaint themselves with each other in the context of this user to = support the user's setting of policies at the AM that will govern the = giving out of requester access tokens for the host's protected resources = later. The specifics involve the host actually getting its own access = token that it can use at a host-specific set of endpoints at the AM = (it's basically an embedded instance of OAuth). As necessary, the = dynamic client registration stuff comes in. - Step 2: get a token: The requester approaches a protected resource, = learns where to go to get an access token, and sets about trying to get = it in mostly a normal fashion (engaging in dynamic client registration = as necessary). What UMA adds on top is that the AM can ask the = requester to produce "claims" in support of proving its suitability for = getting the token. If the authorizing user had set policies that could = be applied unilaterally in token issuance, great, but if the user had = set policies that require the requester to (say) promise to adhere to = the user's licensing terms, that can be provided in a claim. (The = mechanism is simple so far, but the implications are powerful... We've = been exploring legal considerations of authorizing access by fully = autonomous parties.) - Step 3: use a token: Requester wields token at host to get access. = What UMA adds on top is the host's ability to talk to the AM on a back = channel to validate that token, to support minimal host implementations = and fully dynamic host deployments. We're still in the process of defining (and in some cases redefining) = the various protocol bits, and welcome input and engagement from others = if the use cases we're solving for float your boat. If you want to see = a full experimental implementation (soon to be open-sourced, I = understand) in action, I-D coauthor Maciej and his crew are documenting = their work at http://smartjisc.wordpress.com/. Eve On 11 Aug 2010, at 3:40 AM, Torsten Lodderstedt wrote: > Eve, >=20 > thank you for writting this document. I consider it a good starting = point for a discussion about client registration and discovery. Will you = propose this as a WG item? >=20 > My comments & questions: >=20 > You propose a host-meta based discovery of the registration endpoint = on the authz server. Could this mechanism be used for discovering all AS = endpoints, e.g. tokens and end-user authorization? >=20 > How is a UMA requestor envisioned to discover the auth server? >=20 > I think host-meta based client discovery could be to limited since it = does not allow (at least in my understanding) to serve different clients = (or their home web apps) on the same host. What about using JRD or XRD? = This would allow for a client-URL-related discovery. >=20 > What means for authentication a client against its home web app. do = you envision? >=20 > regards, > Torsten. >=20 > Am 10.08.2010 um 21:31 schrieb Eve Maler : >=20 >> Folks-- The UMA group has produced the following I-D as input to the = OAuth discovery/registration/binding discussion. We wanted to set forth = our requirements (knowing that there may be other requirements from the = wider community) and propose some solutions that meet them. If further = discussion seems to warrant an updating of this draft, we're happy to do = that. (If you have interest in getting involved in UMA-specific work, = feel free to drop me a note.) >>=20 >> Eve >>=20 >> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >>=20 >> Begin forwarded message: >>=20 >>> From: IETF I-D Submission Tool >>> Date: 10 August 2010 12:23:59 PM PDT >>> To: eve@xmlgrrl.com >>> Cc: cs@comlounge.net, m.p.machulak@ncl.ac.uk >>> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00=20 >>>=20 >>>=20 >>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been = successfully submitted by Eve Maler and posted to the IETF repository. >>>=20 >>> Filename: draft-oauth-dyn-reg-v1 >>> Revision: 00 >>> Title: OAuth Dynamic Client Registration Protocol >>> Creation_date: 2010-08-10 >>> WG ID: Independent Submission >>> Number_of_pages: 20 >>>=20 >>> Abstract: >>> This specification proposes an OAuth Dynamic Client Registration >>> protocol. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >=20 Eve Maler http://www.xmlgrrl.com/blog http://www.twitter.com/xmlgrrl http://www.linkedin.com/in/evemaler From torsten@lodderstedt.net Wed Aug 11 10:37:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 176603A6A7B for ; Wed, 11 Aug 2010 10:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq2RH8AxqBku for ; Wed, 11 Aug 2010 10:36:59 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by core3.amsl.com (Postfix) with ESMTP id 386633A69D0 for ; Wed, 11 Aug 2010 10:36:59 -0700 (PDT) Received: from [80.187.98.84] (helo=[10.203.12.52]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OjFEo-0001Ts-SZ; Wed, 11 Aug 2010 19:37:33 +0200 References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> <837544.77407.qm@web37602.mail.mud.yahoo.com> <6A18E244-31B2-46F1-BA10-FC414C185EDB@lodderstedt.net> In-Reply-To: <6A18E244-31B2-46F1-BA10-FC414C185EDB@lodderstedt.net> Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1-445804549 Message-Id: <97D7B0AE-2370-4501-871C-5147EE0F1D03@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Wed, 11 Aug 2010 19:36:20 +0200 To: Torsten Lodderstedt X-Df-Sender: 141509 Cc: Naitik Shah , Oleg Gryb , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 17:37:01 -0000 --Apple-Mail-1-445804549 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom what has been discussed in this thread (and other discussions before)= , I see the need for the following variants: - code in URI (Web App.) - token in fragment (JS client app) - code in fragment (installed app) - code in URI + token in fragment (Web App. with JS Client?) Any comments? regards, Torsten. Am 10.08.2010 um 19:57 schrieb Torsten Lodderstedt = : > Thank you for the explanation.=20 >=20 > I now understand that the fragment is used for efficiently passing token o= r code on the client side. What I still don't understand is why a client wou= ld need both at once (url 1)? Have you such applications in production? >=20 > regards, > Torsten. >=20 >=20 >=20 > Am 10.08.2010 um 19:23 schrieb Luke Shepard : >=20 >> Here are the possible URLs: >>=20 >> http://static.facebook.com/connect/xd_proxy.php#code=3D10alkji&access_tok= en=3Dlzipa3p >> http://static.facebook.com/connect/xd_proxy.php?code=3D10alkji#access_tok= en=3Dlzipa3p >>=20 >> Those who already use this flow in production (including Google, Facebook= , Twitter, and others) typically work like this: >>=20 >> - Parent frame initiates the transaction by spawning a popup or an iframe= >> - Response comes back to a static relay file (like the xd_proxy.php above= ) >> - The relay interprets the URL, parses out arguments, and hands them to t= he parent frame >> - Parent frame then does what it wants. this could be making an API call v= ia JSONP, handing info to the server via Ajax, or something else. >>=20 >> Because the relay file is static, it isn't going to interpret the code re= gardless, even if it is sent in the query parameter. So since the client wil= l handle it anyway, the fragment is better for two reasons: >>=20 >> 1/ Less code for the JS to just pull it out of the fragment >> 2/ More efficient, as the relay file can be cached on the client. If you i= nclude a code then you degrade performance because it busts the cache every t= ime. >>=20 >>=20 >> On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrote: >>=20 >>> I was trying to understand that too (see "Is user agent profile secure" t= hread). The answers that I've got were: >>>=20 >>> 1. It's already coded this way. >>> 2. It's the most efficient way of doing that, because that relay.html pa= ge is static and can be cached by a browser. >>>=20 >>> None of the answers above looks very convincing to me, but that's where U= A is now.=20 >>>=20 >>> From: Torsten Lodderstedt >>> Can someone pls. explain why code and token should both be returned in t= he fragment? >>>=20 >>> regards, >>> Torsten. >>>=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-1-445804549 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=46rom what has been discussed in this t= hread (and other discussions before), I see the need for the following varia= nts:

- code in URI (Web App.)
- token in frag= ment (JS client app)
- code in fragment (installed app)
- code in URI + token in fragment (Web App. with JS Client?)

Any comments?

regards,
T= orsten.

Am 10.08.2010 um 19:57 schrieb Torsten Lodderstedt <= ;torsten@lodderstedt.net>:=

Thank you for t= he explanation. 

I now understand that the fra= gment is used for efficiently passing token or code on the client side. What= I still don't understand is why a client would need both at once (url 1)? H= ave you such applications in production?

regards,
Torsten.



Am 10.08.2010 um 19:23 schrieb L= uke Shepard <lshepard@facebook.com>:

<= /div>
Here are the possible URLs:

http://static.fa= cebook.com/connect/xd_proxy.php?code=3D10alkji#access_token=3Dlzipa3p

Those who already use this flow in production (includin= g Google, Facebook, Twitter, and others) typically work like this:

- Parent frame initiates the transaction by spawning a popup= or an iframe
- Response comes back to a static relay file (like t= he xd_proxy.php above)
- The relay interprets the URL, parses out a= rguments, and hands them to the parent frame
- Parent frame then d= oes what it wants. this could be making an API call via JSONP, handing info t= o the server via Ajax, or something else.

Because t= he relay file is static, it isn't going to interpret the code regardless, ev= en if it is sent in the query parameter. So since the client will handle it a= nyway, the fragment is better for two reasons:

1/ L= ess code for the JS to just pull it out of the fragment
2/ More ef= ficient, as the relay file can be cached on the client. If you include a cod= e then you degrade performance because it busts the cache every time.
<= div>

On Aug 10, 2010, at 9:35 AM, Oleg Gryb wrot= e:

I was tr= ying to understand that too (see "Is user agent profile secure" thread). The= answers that I've got were:

1. It's already coded this= way.
2. It's the most efficient way of doing that, because that relay.ht= ml page is static and can be cached by a browser.

None of the answers= above looks very convincing to me, but that's where UA is now. 

From: Torsten Lodderstedt <torsten@lodderstedt.net>

regar= ds,
Torsten.


= _______________________________________________
OAuth mailing list
OAuth@ietf.org
https:= //www.ietf.org/mailman/listinfo/oauth
<= /div>
_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-1-445804549-- From igor.faynberg@alcatel-lucent.com Wed Aug 11 10:41:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD863A694E for ; Wed, 11 Aug 2010 10:41:46 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6yglhUVwh0x for ; Wed, 11 Aug 2010 10:41:45 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id A060D3A684B for ; Wed, 11 Aug 2010 10:41:45 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o7BHgK1Q003222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2010 12:42:20 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o7BHgJj3025205; Wed, 11 Aug 2010 12:42:19 -0500 (CDT) Message-ID: <4C62E0FB.8060209@alcatel-lucent.com> Date: Wed, 11 Aug 2010 13:42:19 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <3D3C75174CB95F42AD6BCC56E5555B4502E5D297@FIESEXC015.nsn-intra.net> <4C62D035.5080403@alcatel-lucent.com> <3D3C75174CB95F42AD6BCC56E5555B4502E5D591@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4502E5D591@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: OAuth WG Subject: Re: [OAUTH-WG] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 17:41:46 -0000 Yes, there is Recommendation X.1252 (IdM terms) and then Y 2720 (NGN identity management framework) has some terms in addition to that. All documents in force are listed, and can be picked up free, at http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx. Igor Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I am not aware of the ITU-T terminology. Are the documents publically > available? > > >> -----Original Message----- >> From: ext Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] >> Sent: Wednesday, August 11, 2010 7:31 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Feedback solicited for Privacy and >> Identity Management Terminology >> >> Hannes, >> >> This is indeed a very good idea! >> >> ITU has been developing the IdM terminology for some time, so this >> document should prompt the discussion and -- let us hope!-- the >> alignment of normative terminology. >> >> With thanks, >> >> Igor >> >> Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >>> Hi all, >>> >>> Althought this request is only indirectly related to the OAuth >>> protocol work I nevertheless think your input is valuable. We have >>> just submitted a new version of the privacy and identity management >>> terminology document: >>> >>> >>> >> _http://www.ietf.org/internet-drafts/draft-hansen-privacy-term >> inology-01.txt_ >> >>> >>> The full document titel is "Terminology for Talking about >>> >> Privacy by >> >>> Data Minimization: Anonymity, Unlinkability, Undetectability, >>> Unobservability, Pseudonymity, and Identity Management" and here is >>> the abstract: >>> >>> This document is an attempt to consolidate terminology >>> >> in the field >> >>> privacy by data minimization. It motivates and develops >>> >> definitions >> >>> for anonymity/identifiability, (un)linkability, >>> >> (un)detectability, >> >>> (un)observability, pseudonymity, identity, partial >>> >> identity, digital >> >>> identity and identity management. Starting the >>> >> definitions from the >> >>> anonymity and unlinkability perspective and not from a >>> >> definition of >> >>> identity (the latter is the obvious approach to some >>> >> people) reveals >> >>> some deeper structures in this field. >>> >>> Please let us know whether the terminology is useful and complete. >>> Your input is highly appreciated! >>> >>> Ciao >>> Hannes >>> >>> >>> >>> >> -------------------------------------------------------------- >> ---------- >> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> From beaton@google.com Wed Aug 11 11:02:44 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60753A684B for ; Wed, 11 Aug 2010 11:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.961 X-Spam-Level: X-Spam-Status: No, score=-103.961 tagged_above=-999 required=5 tests=[AWL=2.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPDvxUR0s9QF for ; Wed, 11 Aug 2010 11:02:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id AE3B13A67EC for ; Wed, 11 Aug 2010 11:02:43 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o7BI3IXY005107 for ; Wed, 11 Aug 2010 11:03:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281549799; bh=Vtua++FcmszxueFd8FNd+eMQUHo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=GE4ci2sEQ219xVvpLG3egBdvGKP1dIPPM8Jd3wic9Mz3B+zcl+pZmhEpks9bJYQwO lz64QjFuiK+yVItaO8m5w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Fl9p+mguxnCfPhoCnNLTEgJOCmXlbowzZdQpDFHATpin56450Mwwcsqkeyhr9rZ5f ApK4bxbdYzCOl9uV28tiQ== Received: from pzk33 (pzk33.prod.google.com [10.243.19.161]) by kpbe14.cbf.corp.google.com with ESMTP id o7BI353j009195 for ; Wed, 11 Aug 2010 11:03:12 -0700 Received: by pzk33 with SMTP id 33so188859pzk.28 for ; Wed, 11 Aug 2010 11:03:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.238.2 with SMTP id l2mr14957060wfh.164.1281549792265; Wed, 11 Aug 2010 11:03:12 -0700 (PDT) Received: by 10.143.46.3 with HTTP; Wed, 11 Aug 2010 11:03:12 -0700 (PDT) In-Reply-To: <917905.1164.qm@web37601.mail.mud.yahoo.com> References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> <837544.77407.qm@web37602.mail.mud.yahoo.com> <917905.1164.qm@web37601.mail.mud.yahoo.com> Date: Wed, 11 Aug 2010 11:03:12 -0700 Message-ID: From: Brian Eaton To: Oleg Gryb Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 18:02:45 -0000 On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote: > The thing is that each time when a web app with sensitive info can be run in > a frame, security people would advice to break that > frame-reads-other-frame-data logic, because it can lead to violation of same > origin policy. This is incorrect. The security of this flow is based entirely on the same-origin policy. Same-origin provides the basic authentication of the destination of the access tokens. Note that both the web-server and the user-agent flows are entirely about passing information to third-party web sites, so suggesting that these flows should not pass information across domains is not really helpful. =) > Yes, but you'll need a web server client for that. I'm saying that UA profile can > be POST based too. (a) The POST would bust the browser cache. (b) Javascript can't read POST bodies. (At least not to my knowledge. If you know of client-side code that can do this, I'm interested.) If we were willing to accept the performance penalty of busting the browser-cache, we would use the web-server flow. From tonynad@microsoft.com Wed Aug 11 11:25:57 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79FFD3A67F5 for ; Wed, 11 Aug 2010 11:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-WhwE6t7qxB for ; Wed, 11 Aug 2010 11:25:52 -0700 (PDT) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id D5B9B3A67EC for ; Wed, 11 Aug 2010 11:25:51 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 11 Aug 2010 11:26:28 -0700 Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.187]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0218.010; Wed, 11 Aug 2010 11:26:27 -0700 From: Anthony Nadalin To: "igor.faynberg@alcatel-lucent.com" , "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [OAUTH-WG] Feedback solicited for Privacy and Identity Management Terminology Thread-Index: AQHLOXyncq2qUOmrB06irjrPbMKdKJLckkJw Date: Wed, 11 Aug 2010 18:26:25 +0000 Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B4502E5D297@FIESEXC015.nsn-intra.net> <4C62D035.5080403@alcatel-lucent.com> <3D3C75174CB95F42AD6BCC56E5555B4502E5D591@FIESEXC015.nsn-intra.net> <4C62E0FB.8060209@alcatel-lucent.com> In-Reply-To: <4C62E0FB.8060209@alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 18:25:57 -0000 Seems that ISO/IEC 24760 is yet another one that does not align with Recomm= endation X.1252 (IdM terms) =20 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of I= gor Faynberg Sent: Wednesday, August 11, 2010 10:42 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: OAuth WG Subject: Re: [OAUTH-WG] Feedback solicited for Privacy and Identity Managem= ent Terminology Yes, there is Recommendation X.1252 (IdM terms) and then Y 2720 (NGN ident= ity management framework) has some terms in addition to that. All documents= in force are listed, and can be picked up free, at http://www.itu.int/en/I= TU-T/publications/Pages/recs.aspx. Igor Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I am not aware of the ITU-T terminology. Are the documents publically=20 > available? > > =20 >> -----Original Message----- >> From: ext Igor Faynberg [mailto:igor.faynberg@alcatel-lucent.com] >> Sent: Wednesday, August 11, 2010 7:31 PM >> To: Tschofenig, Hannes (NSN - FI/Espoo) >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Feedback solicited for Privacy and Identity=20 >> Management Terminology >> >> Hannes, >> >> This is indeed a very good idea! >> >> ITU has been developing the IdM terminology for some time, so this=20 >> document should prompt the discussion and -- let us hope!-- the=20 >> alignment of normative terminology. >> >> With thanks, >> >> Igor >> >> Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> =20 >>> Hi all, >>> >>> Althought this request is only indirectly related to the OAuth=20 >>> protocol work I nevertheless think your input is valuable. We have=20 >>> just submitted a new version of the privacy and identity management=20 >>> terminology document: >>> >>> >>> =20 >> _http://www.ietf.org/internet-drafts/draft-hansen-privacy-term >> inology-01.txt_ >> =20 >>> =20 >>> The full document titel is "Terminology for Talking about >>> =20 >> Privacy by >> =20 >>> Data Minimization: Anonymity, Unlinkability, Undetectability,=20 >>> Unobservability, Pseudonymity, and Identity Management" and here is=20 >>> the abstract: >>> >>> This document is an attempt to consolidate terminology >>> =20 >> in the field >> =20 >>> privacy by data minimization. It motivates and develops >>> =20 >> definitions >> =20 >>> for anonymity/identifiability, (un)linkability, >>> =20 >> (un)detectability, >> =20 >>> (un)observability, pseudonymity, identity, partial >>> =20 >> identity, digital >> =20 >>> identity and identity management. Starting the >>> =20 >> definitions from the >> =20 >>> anonymity and unlinkability perspective and not from a >>> =20 >> definition of >> =20 >>> identity (the latter is the obvious approach to some >>> =20 >> people) reveals >> =20 >>> some deeper structures in this field. >>> =20 >>> Please let us know whether the terminology is useful and complete.=20 >>> Your input is highly appreciated! >>> >>> Ciao >>> Hannes >>> >>> >>> >>> =20 >> -------------------------------------------------------------- >> ---------- >> =20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> =20 >>> =20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From sDronia@gmx.de Thu Aug 12 00:11:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058B53A69D6 for ; Thu, 12 Aug 2010 00:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.724 X-Spam-Level: X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBvBYZJmZokP for ; Thu, 12 Aug 2010 00:11:11 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id A19B83A69C5 for ; Thu, 12 Aug 2010 00:11:07 -0700 (PDT) Received: (qmail invoked by alias); 12 Aug 2010 07:11:35 -0000 Received: from tmo-099-163.customers.d1-online.com (EHLO [127.0.0.1]) [80.187.99.163] by mail.gmx.net (mp058) with SMTP; 12 Aug 2010 09:11:35 +0200 X-Authenticated: #3259608 X-Provags-ID: V01U2FsdGVkX1+AWbdO8veAyfMh/rDEEwQ1u30ziU0vKA8jntcNaA Y/b/29e8ZAs3dg Message-ID: <4C639E95.50407@gmx.de> Date: Thu, 12 Aug 2010 09:11:17 +0200 From: Stefanie Dronia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Christian Scholz References: <20100810192359.2E4F63A69B0@core3.amsl.com> <1EE4AF83-538C-404A-BF09-D9075A80B576@xmlgrrl.com> <4C62B565.7020406@gmx.de> <4C62CE36.9090003@comlounge.net> In-Reply-To: <4C62CE36.9090003@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Proposal for OAuth dynamic client registration X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 07:11:13 -0000 Hi Christian, thanks for clarification. Regards, Stefanie Am 11.08.2010 18:22, schrieb Christian Scholz: > Hi! > > Am 11.08.10 16:36, schrieb Stefanie Dronia: > >> Hallo Eve, >> >> I read your proposal, too. Thanks for providing it. >> >> Some questions: >> # first part of chapter 2 >> # enchanced OAuth RS, AS and client are mentioned. Does the >> enhancement just denote, that they support dynamic client registration >> or have any further requirements to be fulfilled by them? >> > These are mostly examples from the User Managed Access (UMA) Working > Group where we use components which have to do a bit more than simple > OAuth. Out of this came the need for dynamic client registration which > we thought might be useful in other OAuth contexts as well. > > So regarding the actual client registration they do not need to have > further requirements other than the client registration capabilities > described. In the final version we might want to get rid of the UMA > specific text in order to prevent confusion. > > >> # The text is "... use an access token in approximately the normal >> OAuth fashion,...": What do you mean by "approximately" in this context? >> As far as I understood, after client registration, OAuth flows are >> performed as defined. >> > Yes, again this relates to our UMA use cases where later on (after > client registration) those components need to do a bit more. For this > spec though this is irrelevant. > > >> # For registration, the client has to give its URL (parameter client_url >> in registration request). May it be used later for OAuth callback url, >> e.g. if client registration with pushed metadata is selected? >> > Those parameters basically should represent what you otherwise would > enter into a registration form like http://dev.twitter.com/apps/new > Thus there probably need to be more fields in there but website url (or > client_url) and callback_url should probably be 2 different attributes. > > The question regarding the client metadata is how much information > really is needed. For manual registration the server can ask as much as > it wants. For automatic registration I would like some basic set of > attributes, some maybe being optional. The question might be which ones > to take. > > > >> And just a typo: Example chapter 7.1: "url" instead of "client_url" is >> printed. >> > Right, thanks! > > -- Christian > > >> Regards, >> Stefanie >> >> Am 10.08.2010 21:31, schrieb Eve Maler: >> >>> Folks-- The UMA group has produced the following I-D as input to the >>> OAuth discovery/registration/binding discussion. We wanted to set >>> forth our requirements (knowing that there may be other requirements >>> from the wider community) and propose some solutions that meet them. >>> If further discussion seems to warrant an updating of this draft, >>> we're happy to do that. (If you have interest in getting involved in >>> UMA-specific work, feel free to drop me a note.) >>> >>> Eve >>> >>> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >>> >>> Begin forwarded message: >>> >>> >>> >>>> From: IETF I-D Submission Tool >>>> Date: 10 August 2010 12:23:59 PM PDT >>>> To:eve@xmlgrrl.com >>>> Cc:cs@comlounge.net,m.p.machulak@ncl.ac.uk >>>> Subject: New Version Notification for draft-oauth-dyn-reg-v1-00 >>>> >>>> >>>> A new version of I-D, draft-oauth-dyn-reg-v1-00.txt has been >>>> successfully submitted by Eve Maler and posted to the IETF repository. >>>> >>>> Filename: draft-oauth-dyn-reg-v1 >>>> Revision: 00 >>>> Title: OAuth Dynamic Client Registration Protocol >>>> Creation_date: 2010-08-10 >>>> WG ID: Independent Submission >>>> Number_of_pages: 20 >>>> >>>> Abstract: >>>> This specification proposes an OAuth Dynamic Client Registration >>>> protocol. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> >>>> >>> Eve Maler >>> http://www.xmlgrrl.com/blog >>> http://www.twitter.com/xmlgrrl >>> http://www.linkedin.com/in/evemaler >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > From paul.tarjan@facebook.com Thu Aug 12 01:24:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515B428C107 for ; Thu, 12 Aug 2010 01:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.636 X-Spam-Level: X-Spam-Status: No, score=-100.636 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEOWva6Ua80K for ; Thu, 12 Aug 2010 01:24:06 -0700 (PDT) Received: from mx-out.facebook.com (outmail006.ash1.tfbnw.net [69.63.184.106]) by core3.amsl.com (Postfix) with ESMTP id 5BDC028C0F8 for ; Thu, 12 Aug 2010 01:24:06 -0700 (PDT) Received: from [10.18.255.132] ([10.18.255.132:13537] helo=mail.thefacebook.com) by mta005.ash1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 9D/DA-13308-ACFA36C4; Thu, 12 Aug 2010 01:24:43 -0700 Received: from SC-MBX03.TheFacebook.com ([169.254.2.61]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Thu, 12 Aug 2010 01:24:41 -0700 From: Paul Tarjan To: OAuth WG Thread-Topic: 5.2 Example Error Thread-Index: AQHLOffPb+tasdRGqU+/hnlScG0XFQ== Date: Thu, 12 Aug 2010 08:24:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] 5.2 Example Error X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:24:07 -0000 Hi (Fellow) OAuthers, Reading the spec over, I noticed the example in 5.2 says WWW-Authenticate: OAuth realm=3D'Example Service', error=3D'expired-token= ' but the syntax above it seems to want WWW-Authenticate: OAuth realm=3D'"Example Service" error=3D"expired-token= " also, expired-token isn't a valid response code, I think it should be: WWW-Authenticate: OAuth realm=3D'"Example Service" error=3D"expired_token= " and for good measure, maybe an example description=20 WWW-Authenticate: OAuth realm=3D'"Example Service" error=3D"expired_token= " error_description=3D"This token expired at 1234567890 and it is now 12345= 99999" Similarly in 5.2.1: WWW-Authenticate: OAuth realm=3D'Example Service' I think it should be double quotes. Thanks Paul= From oleg_gryb@yahoo.com Thu Aug 12 08:26:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD66628C136 for ; Thu, 12 Aug 2010 08:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJgVVQoufd-7 for ; Thu, 12 Aug 2010 08:26:26 -0700 (PDT) Received: from web37604.mail.mud.yahoo.com (web37604.mail.mud.yahoo.com [209.191.87.87]) by core3.amsl.com (Postfix) with SMTP id BBC3C28C128 for ; Thu, 12 Aug 2010 08:26:24 -0700 (PDT) Received: (qmail 82392 invoked by uid 60001); 12 Aug 2010 15:26:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1281626818; bh=eokXOvoGq+4uBFUMcQbp3aRjjHobKdQRA04UFbrYJFg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rm1X405HcwF6z8B/Kw45EZtEt2k7dzPeCbUHGGy4fZNTkegeM3HhqqfGwJwaMbeoZUmf1U22G2G7ugUHOENl0jQZleSH+tWFkbCa4QPo/U2iDPU17CyE/khfAFDBdMlNMAtgbwyhBxlCI4MriqnKc7YhiFw8McEJXMPGIaZZ59A= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=6Q6XwclK4twcJwCY0/6VRhkV6npMx2bGH4GVi+Dx4VNOMBK7ASgCZ6Zn+RY8dNBe1oVmOYC+Gc9QgzAnEiZPjZaCmSi2ytvqF4BnRhfjBP+/HLllpM7JnMIw3X/yvp8dYoNNW7BoRgXQi1J9hiv8ZXObtRii9p1BtT5rinbHvJk=; Message-ID: <674292.82385.qm@web37604.mail.mud.yahoo.com> X-YMail-OSG: u1aqasEVM1kRqOtatOqf9_rsdqzpGjGvOm5xbSA5.8z8HsH KNcY9ShBaoAgeCFyvLnaBQFjhbzrJBAbLI7EuDJ_vVeax_OGmrw8_JMRZifi QT.t0Y0TxcO_FVS20..6J0a1fyItSYwZZMdRtsMiSJyzeMg3XnnWnoyMw9Hx v0Iu_tjX8RojWTRROuuzqH0xZGYmn84WyoaP0nf9OvY1XKpFbm2J0G3QFFLh Nbt.tUNS4naNezd0QQGwH_7RZPsXPFgmH9Kv.pZotl6c28gOLAmgCYKf3cK7 De8RfQHdQo9LPrYGbf.e9kwF6j3GkiptGWHGsAnNYGQZ1nB81yRIpQYHicWU 6vzg9BEAVhNfZEeVpvzx3CrtI1mmH14.qzKzoaCqZ.FGSqchkDoOT_NjXHw- - Received: from [75.24.108.43] by web37604.mail.mud.yahoo.com via HTTP; Thu, 12 Aug 2010 08:26:58 PDT X-Mailer: YahooMailRC/470 YahooMailWebService/0.8.105.279950 References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> <837544.77407.qm@web37602.mail.mud.yahoo.com> <917905.1164.qm@web37601.mail.mud.yahoo.com> Date: Thu, 12 Aug 2010 08:26:58 -0700 (PDT) From: Oleg Gryb To: Brian Eaton , Oleg Gryb In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Oleg Gryb List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 15:26:27 -0000 ----- Original Message ---- > From: Brian Eaton > To: Oleg Gryb > Cc: Naitik Shah ; OAuth WG > Sent: Wed, August 11, 2010 11:03:12 AM > Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query > > On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote: > > The thing is that each time when a web app with sensitive info can be run in > > a frame, security people would advice to break that > > frame-reads-other-frame-data logic, because it can lead to violation of >same > > origin policy. > > This is incorrect. The security of this flow is based entirely on the > same-origin policy. It is not: you get an access token from authz server and want to share it with thirdparty.com domain, which is in a different domain. You do it through frames running in a browser. Do a threat modeling as others suggested here. Why the access token needs to be shared with thirdparty.com is still not clear. > Note that both the web-server and the user-agent flows are entirely > about passing information to third-party web sites, so suggesting that > these flows should not pass information across domains is not really > helpful. =) There are two kinds of information here: thirdparty.com state (e.g. list of selected photos on Facebook) and access token, which is really a printing.com secret. If you store access token in a printing.com cookie you don't need to share it with thirdparty.com. > > Yes, but you'll need a web server client for that. I'm saying that UA >profile can > > be POST based too. > > (a) The POST would bust the browser cache. > (b) Javascript can't read POST bodies. (At least not to my knowledge. No, it can't and I never said it could. Busting the browser cache by writing a server side logic doesn't look like a big issue or performance lost to me. You could aqcwire access token once, persist it (e.g. through a cookie in printing.com domain) and reuse until it's expired. > If we were willing to accept the performance penalty of busting the > browser-cache, we would use the web-server flow. I'm still struggling to undertand what you're trying to achieve with UA profile. If it's getting rid of web server client, you didn't aachieve it, because you still have thridparty.com, which is actually a web server client. Here are some qs to the existing spec (v.10) related to that: "The user-agent profile is suitable for client applications residing in a user-agent, typically implemented in a browser using a scripting language such as JavaScript"Client application (JavaScript) resides and is implemented on thrirdparty.com. Browser only executes it, so you actually do have a web server client, it just you don't want to use server side code and server side objects, right? If this is the case, why don't you say it explicitly? "These clients cannot keep client secrets confidential"What is wrong with cookies? I think, in your UA flow you'll also need to reflect: 1. thirdparty.com and it's role. 2. the cross-domain secret sharing logic that we've discussed here and why you need it. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Thu Aug 12 09:25:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 961613A68EF for ; Thu, 12 Aug 2010 09:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.023 X-Spam-Level: X-Spam-Status: No, score=-104.023 tagged_above=-999 required=5 tests=[AWL=1.953, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93sysEgeshWr for ; Thu, 12 Aug 2010 09:25:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 709D53A6853 for ; Thu, 12 Aug 2010 09:25:04 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o7CGPfKp009737 for ; Thu, 12 Aug 2010 09:25:41 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281630341; bh=Zat2wB+LsBjjglfBJUR35rGY/i8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=D805TM+K5UR+DMk0YD/0imsdZuj+GgJApx9iBD9usveaT8NrmDd1HFVpDI63hGkWr v4JYuFjQGguZ6ioTzdRdQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=sZbp+hKJYDj5ANGN2v5VqGpmPkWhRKM4ezrBLSY/i2rSpNgYTgH+el+bfbzBJrKgr 1ofg608mR2Px9/8NXJGBQ== Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by hpaq2.eem.corp.google.com with ESMTP id o7CGPdgP008532 for ; Thu, 12 Aug 2010 09:25:39 -0700 Received: by pwj8 with SMTP id 8so543066pwj.1 for ; Thu, 12 Aug 2010 09:25:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.156.16 with SMTP id d16mr269041wfe.120.1281630337777; Thu, 12 Aug 2010 09:25:37 -0700 (PDT) Received: by 10.143.46.3 with HTTP; Thu, 12 Aug 2010 09:25:37 -0700 (PDT) In-Reply-To: <674292.82385.qm@web37604.mail.mud.yahoo.com> References: <8F6F3A55-274C-4F38-84C8-C956D74504AE@lodderstedt.net> <837544.77407.qm@web37602.mail.mud.yahoo.com> <917905.1164.qm@web37601.mail.mud.yahoo.com> <674292.82385.qm@web37604.mail.mud.yahoo.com> Date: Thu, 12 Aug 2010 09:25:37 -0700 Message-ID: From: Brian Eaton To: Oleg Gryb Content-Type: multipart/alternative; boundary=000e0cd17c880442e2048da2d1de X-System-Of-Record: true Cc: Naitik Shah , OAuth WG Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 16:25:06 -0000 --000e0cd17c880442e2048da2d1de Content-Type: text/plain; charset=ISO-8859-1 Hi Oleg - "There are two kinds of information here: thirdparty.com state (e.g. list of selected photos on Facebook) and access token, which is really a printing.com secret. If you store access token in a printing.com cookie you don't need to share it with thirdparty.com." The goal of the flow is for third-party.com to access printing.com. That is what the user wants to have happen, and the service provider wants to allow it. Cheers, Brian On Thu, Aug 12, 2010 at 8:26 AM, Oleg Gryb wrote: > > > > > ----- Original Message ---- > > From: Brian Eaton > > To: Oleg Gryb > > Cc: Naitik Shah ; OAuth WG > > Sent: Wed, August 11, 2010 11:03:12 AM > > Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query > > > > On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb wrote: > > > The thing is that each time when a web app with sensitive info can be > run > in > > > a frame, security people would advice to break that > > > frame-reads-other-frame-data logic, because it can lead to violation > of > >same > > > origin policy. > > > > This is incorrect. The security of this flow is based entirely on the > > same-origin policy. > > It is not: you get an access token from authz server and want to share it > with > thirdparty.com domain, which is in a different domain. You do it through > frames > running in a browser. Do a threat modeling as others suggested here. Why > the > access token needs to be shared with thirdparty.com is still not clear. > > > Note that both the web-server and the user-agent flows are entirely > > about passing information to third-party web sites, so suggesting that > > these flows should not pass information across domains is not really > > helpful. =) > > There are two kinds of information here: thirdparty.com state (e.g. list > of > selected photos on Facebook) and access token, which is really a > printing.com > secret. If you store access token in a printing.com cookie you don't need > to > share it with thirdparty.com. > > > > Yes, but you'll need a web server client for that. I'm saying that UA > >profile can > > > be POST based too. > > > > (a) The POST would bust the browser cache. > > (b) Javascript can't read POST bodies. (At least not to my knowledge. > > No, it can't and I never said it could. Busting the browser cache by > writing a > server side logic doesn't look like a big issue or performance lost to me. > You > could aqcwire access token once, persist it (e.g. through a cookie in > printing.com domain) and reuse until it's expired. > > > If we were willing to accept the performance penalty of busting the > > browser-cache, we would use the web-server flow. > > I'm still struggling to undertand what you're trying to achieve with UA > profile. > If it's getting rid of web server client, you didn't aachieve it, because > you > still have thridparty.com, which is actually a web server client. > > Here are some qs to the existing spec (v.10) related to that: > > "The user-agent profile is suitable for client applications residing > in a user-agent, typically implemented in a browser using a scripting > language such as JavaScript"Client application (JavaScript) resides and > is > implemented on thrirdparty.com. Browser only executes it, so you actually > do > have a web server client, it just you don't want to use server side code > and > server side objects, right? If this is the case, why don't you say it > explicitly? > > > "These clients cannot keep client > secrets confidential"What is wrong with cookies? > > I think, in your UA flow you'll also need to reflect: > > 1. thirdparty.com and it's role. > 2. the cross-domain secret sharing logic that we've discussed here and why > you > need it. > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > --000e0cd17c880442e2048da2d1de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Oleg -=A0

"There are two kinds of information he= re:=A0thirdparty.com=A0state (e.g. list of
selected photos on Facebook) and access token, = which is really a=A0prin= ting.com
secret. If you store access token in a=A0printing.com=A0cookie you don't need to
share i= t with=A0thirdparty.co= m."

The goal of the flow is for third-party.com to access print= ing.com. =A0That is what the user wants to have happen, and the service= provider wants to allow it.

Cheers,
Brian

On Thu, Aug 12, 2010 at 8:26 AM, Oleg Gryb <oleg_gryb@yahoo.com> wrote:




----- Original Message ----
> From: Brian Eaton <beaton@goog= le.com>
> To: Oleg Gryb <oleg@gryb.info= >
> Cc: Naitik Shah <naitik@facebook.com>; OAuth WG <oauth@ietf.org>
> Sent: Wed, August 11, 2010 11:03:12 AM
> Subject: Re: [OAUTH-WG] Quick survey: fragment vs. query
>
> On Tue, Aug 10, 2010 at 11:00 AM, Oleg Gryb &l= t;oleg_gryb@yahoo.com> wrote:=
> > The =A0thing is that each time when a web app with sensitive info= can be run
in
> > =A0a frame, security people would advice to break that
> > =A0frame-reads-other-frame-data logic, because it can lead to vio= lation of
>same
> > origin policy.
>
> This is incorrect. =A0The security of this =A0flow is based entirely o= n the
> same-origin policy.

It is not: you get an access token from authz server and want to shar= e it with
thirdparty.com doma= in, which is in a different domain. You do it through frames
running in a browser. Do a threat modeling as others suggested here. Why th= e
access token needs to be shared with thirdparty.com is still not clear.

> Note =A0that both the web-server and the user-agent flows are entirely=
> about passing =A0information to third-party web sites, so suggesting t= hat
> these flows should =A0not pass information across domains is not reall= y
> helpful. =3D)

There are two kinds of information here: thirdparty.com state (e.g. list of
selected photos on Facebook) and access token, which is really a printing.com
secret. If you store access token in a printing.com cookie you don't need to
share it with thirdpart= y.com.

> > =A0Yes, but you'll need a web server client for that. I'm= saying that UA
>profile =A0can
> > be POST based too.
>
> (a) The POST would bust the browser =A0cache.
> (b) Javascript can't read POST bodies. =A0(At least not to my =A0k= nowledge.

No, it can't and I never said it could. Busting the browser cache= by writing a
server side logic doesn't look like a big issue or performance lost to = me. You
could aqcwire access token once, persist it (e.g. through a cookie in
printing.com domain) = and reuse until it's expired.

> If we were willing to accept the performance penalty of =A0busting the=
> browser-cache, we would use the web-server =A0flow.

I'm still struggling to undertand what you're trying to achie= ve with UA profile.
If it's getting rid of web server client, you didn't aachieve it, b= ecause you
still have thridparty.c= om, which is actually a web server client.

Here are some qs to the existing spec (v.10) related to that:

=A0 "The user-agent profile is suitable for client applications resid= ing
=A0 in a user-agent, typically implemented in a browser using a scripting<= br> =A0 language such as JavaScript"Client application (JavaScript) resid= es and is
implemented on thrirdp= arty.com. Browser only executes it, so you actually do
have a web server client, it just you don't want to use server side cod= e and
server side objects, right? If this is the case, why don't you say it explicitly?


"These clients cannot keep client
=A0 secrets confidential"What is wrong with cookies?

I think, in your UA flow you'll also need to reflect:

1. thirdparty.com a= nd it's role.
2. the cross-domain secret sharing logic that we've discussed here and = why you
need it.

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




--000e0cd17c880442e2048da2d1de-- From cmortimore@salesforce.com Thu Aug 12 10:18:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E69273A6999 for ; Thu, 12 Aug 2010 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0e7YRYRNFhFs for ; Thu, 12 Aug 2010 10:18:34 -0700 (PDT) Received: from exprod8og116.obsmtp.com (exprod8og116.obsmtp.com [64.18.3.32]) by core3.amsl.com (Postfix) with SMTP id 611A33A690D for ; Thu, 12 Aug 2010 10:18:34 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob116.postini.com ([64.18.7.12]) with SMTP ID DSNKTGQtD+OF7CtSCNwXpIDrznhCZ4Cl1Ksa@postini.com; Thu, 12 Aug 2010 10:19:11 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Thu, 12 Aug 2010 10:19:10 -0700 From: Chuck Mortimore To: Brian Campbell , oauth Date: Thu, 12 Aug 2010 10:19:11 -0700 Thread-Topic: [OAUTH-WG] SAML profile comments/questions from the SAML people Thread-Index: Acs34EfSO1Uu0ZP4Sk+do1om2oshBwCYjLTF Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8897B1FB75Bcmortimoresalesforcecom_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML people X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 17:18:36 -0000 --_000_C8897B1FB75Bcmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 8/9/10 9:30 AM, "Brian Campbell" wrote: I received some feedback on the SAML profile from a cross posting on the OASIS SSTC (SAML) list. Links to the thread topic index are below[1], if you are interested, but I'll try and summarize the two primary issues here. First, concern was expressed that restricting the assertion to only allow for a single element was too limiting. The restriction basically limits the ability of a single assertion to be issued for use across multiple use-cases/profiles. A good example is the use-case that Prateek recently brought up in a different thread on this list[2] where the assertion is delivered to an SP via Web SSO and then that SP uses that same assertion to acquire an access token for data services at a 3rd party site. As currently written, draft-campbell-oauth-saml-00[3], wouldn't allow for that use-case. I'm starting to think that my attempt at simplification was is indeed too restrictive. Allowing for more than one will make the wording in the profile a bit more complicated (as well as implementing validation) but I think, in the longer term, it's probably the right thing to do from a spec perspective. At this point I'm planning on loosening that restriction in the next draft. I'm curious, however, if anyone has any strong opinions on it one way or the other? The second issue involves my assumption and requirement in the profile that the subject of the assertion be the resource owner. To me, it seemed like a reasonable and useful constraint that was generally inline with the spirit of the assertion flow, however, the comments from Scott (editor of the core SAML specifications) suggest that it's too constraining and/or inappropriate. I'm honestly not sure where to go with this one and am reaching out to this list for ideas/suggestions/opinions. I guess I see where he's coming from but I'm kind of partial to the restriction/guidance as I have it. Also, I'm thinking that perhaps the counter example cases he describes would be better captured by use of the "none" access grant type and a client assertion (coming in draft -11, I think?). I think it would be reasonable to loosen the language to reflect that the s= ubject is who access will be granted to. It may or may not be the resourc= e owner, I agree. -cmort Thanks, Brian C [1] Discussion Thread on SSTC list http://lists.oasis-open.org/archives/security-services/201008/threads.html#= 00000 http://lists.oasis-open.org/archives/security-services/201007/threads.html#= 00034 [2] Discussion Thread with use-case on OAuth list http://www.ietf.org/mail-archive/web/oauth/current/msg04118.html [3] draft-campbell-oauth-saml-00 / SAML 2.0 Bearer Assertion Profile for OAuth 2.0 http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C8897B1FB75Bcmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] SAML profile comments/questions from the SAML people<= /TITLE> </HEAD> <BODY> <FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-size:11pt'><BR> <BR> <BR> On 8/9/10 9:30 AM, "Brian Campbell" <<a href=3D"bcampbell@ping= identity.com">bcampbell@pingidentity.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-= size:11pt'>I received some feedback on the SAML profile from a cross postin= g on<BR> the OASIS SSTC (SAML) list.  Links to the thread topic index are<BR> below[1], if you are interested, but I'll try and summarize the two<BR> primary issues here.<BR> <BR> First, concern was expressed that restricting the assertion to only<BR> allow for a single <SubjectConfirmation> element was too limiting.<BR= > The restriction basically limits the ability of a single assertion to<BR> be issued for use across multiple use-cases/profiles.   A good ex= ample<BR> is the use-case that Prateek recently brought up in a different thread<BR> on this list[2] where the assertion is delivered to an SP via Web SSO<BR> and then that SP uses that same assertion to acquire an access token<BR> for data services at a 3rd party site.    As currently writt= en,<BR> draft-campbell-oauth-saml-00[3], wouldn't allow for that use-case.<BR> I'm starting to think that my attempt at simplification was is indeed<BR> too restrictive.  Allowing for more than one <SubjectConfirmation&g= t;<BR> will make the wording in the profile a bit more complicated (as well<BR> as implementing validation) but I think, in the longer term, it's<BR> probably the right thing to do from a spec perspective.  At this point= <BR> I'm planning on loosening that restriction in the next draft.  I'm<BR> curious, however, if anyone has any strong opinions on it one way or<BR> the other?<BR> <BR> The second issue involves my assumption and requirement in the profile<BR> that the subject of the assertion be the resource owner.  To me, it<BR= > seemed like a reasonable and useful constraint that was generally<BR> inline with the spirit of the assertion flow, however, the comments<BR> from Scott (editor of the core SAML specifications) suggest that it's<BR> too constraining and/or inappropriate.  I'm honestly not sure where to= <BR> go with this one and am reaching out to this list for<BR> ideas/suggestions/opinions.   I guess I see where he's coming fro= m but<BR> I'm kind of partial to the restriction/guidance as I have it.  Also,<B= R> I'm thinking that perhaps the counter example cases he describes would<BR> be better captured by use of the "none" access grant type and a c= lient<BR> assertion (coming in draft -11, I think?).<BR> <BR> </SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font= -size:11pt'>I think it would be reasonable to loosen the language to reflec= t that the subject is who access will be granted to.   It may or = may not be the resource owner, I agree.   <BR> <BR> -cmort <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Lucida Grande"><SPAN STYLE=3D'font-= size:11pt'><BR> <BR> Thanks,<BR> Brian C<BR> <BR> [1] Discussion Thread on SSTC list<BR> <a href=3D"http://lists.oasis-open.org/archives/security-services/201008/th= reads.html#00000">http://lists.oasis-open.org/archives/security-services/20= 1008/threads.html#00000</a><BR> <a href=3D"http://lists.oasis-open.org/archives/security-services/201007/th= reads.html#00034">http://lists.oasis-open.org/archives/security-services/20= 1007/threads.html#00034</a><BR> <BR> [2] Discussion Thread with use-case on OAuth list<BR> <a href=3D"http://www.ietf.org/mail-archive/web/oauth/current/msg04118.html= ">http://www.ietf.org/mail-archive/web/oauth/current/msg04118.html</a><BR> <BR> [3] draft-campbell-oauth-saml-00 / SAML 2.0 Bearer Assertion Profile<BR> for OAuth 2.0<BR> <a href=3D"http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt">http://= www.ietf.org/id/draft-campbell-oauth-saml-00.txt</a><BR> _______________________________________________<BR> OAuth mailing list<BR> <a href=3D"OAuth@ietf.org">OAuth@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.or= g/mailman/listinfo/oauth</a><BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C8897B1FB75Bcmortimoresalesforcecom_-- From cmortimore@salesforce.com Thu Aug 12 10:23:39 2010 Return-Path: <cmortimore@salesforce.com> X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C3863A698C for <oauth@core3.amsl.com>; Thu, 12 Aug 2010 10:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkQxZhuqhf-a for <oauth@core3.amsl.com>; Thu, 12 Aug 2010 10:23:36 -0700 (PDT) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by core3.amsl.com (Postfix) with SMTP id 478EE3A69A0 for <oauth@ietf.org>; Thu, 12 Aug 2010 10:23:36 -0700 (PDT) Received: from source ([204.14.239.238]) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKTGQuPTHze7XbabPgU667UVkFq+laaKLo@postini.com; Thu, 12 Aug 2010 10:24:13 PDT Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Thu, 12 Aug 2010 10:24:12 -0700 From: Chuck Mortimore <cmortimore@salesforce.com> To: Eran Hammer-Lahav <eran@hueniverse.com>, Brian Campbell <bcampbell@pingidentity.com> Date: Thu, 12 Aug 2010 10:24:12 -0700 Thread-Topic: [OAUTH-WG] more than one assertion? Thread-Index: Acs4pZWLbX9cjC7QSa2+4aBv+Nh43QAAZixQAGb/9HE= Message-ID: <C8897C4C.B75E%cmortimore@salesforce.com> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C8897C4CB75Ecmortimoresalesforcecom_" MIME-Version: 1.0 Cc: oauth <oauth@ietf.org> Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG <oauth.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/oauth> List-Post: <mailto:oauth@ietf.org> List-Help: <mailto:oauth-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 12 Aug 2010 17:23:39 -0000 --_000_C8897C4CB75Ecmortimoresalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Personally, I'd first like to see more concrete use-cases of how multiple a= ssertions are going to be used in practice. Tony alluded to some abstract= use-cases, but fuller descriptions would probably help everyone out. -cmort On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote: WFM. > -----Original Message----- > From: Brian Campbell [mailto:bcampbell@pingidentity.com] > Sent: Tuesday, August 10, 2010 9:03 AM > To: Eran Hammer-Lahav > Cc: oauth > Subject: Re: [OAUTH-WG] more than one assertion? > > To be honest, I somehow overlooked that particular text - my mistake and > apologies. Reading it again, it probably does preclude parameters from > repeating, however, I can see some room for varied interpretations as to = if > that's a strong normative requirement or a looser suggestion about an err= or > code that could be used in that circumstance. > > Perhaps it could be made more clear by adding some wording about it to th= e > end of the first part of sections 3&4 where it says: "Parameters sent wit= hout > a value MUST be treated as if they were omitted from the request. The > authorization server SHOULD ignore unrecognized request parameters."? > > That said, does it make sense to relax the ban on repeating parameters in > some situations, like for the assertion parameter, to facilitate > easy encoding of multiple assertions? Anthony (Tony?) Nadalin > suggested that multiple assertions might be a common use case and I think > allowing for that via repeating assertion parameters is a cleaner and mor= e > reusable way to do it. > > The text at the bottom of section for could say something like: > > "Parameters sent without a value MUST be treated as if they were omitted > from the request. The authorization server SHOULD ignore unrecognized > request parameters. Parameters MUST NOT repeat unless otherwise noted > in the parameter definition." > > Then in 4.1.3. the assertion parameter could be something like this: > > "assertion > REQUIRED. The assertion(s). This parameter MAY be repeated in = the > request, if more than one > assertion is needed for the access grant" > > > Obviously Eran could improve on the actual text but hopefully that gets t= he > concept across? > > > > On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav > <eran@hueniverse.com> wrote: > > Do we need to clarify 4.3.1 "repeats a parameter" description for > "invalid_request" error code does not preclude parameters from repeating? > I'm not sure. > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Brian Campbell > >> Sent: Monday, August 09, 2010 12:34 PM > >> To: oauth > >> Subject: [OAUTH-WG] more than one assertion? > >> > >> The question of allowing for multiple assertions in the SAML profile > >> came up recently. See http://www.ietf.org/mail- > >> archive/web/oauth/current/msg04068.html and several subsequent > >> messages in the thread. > >> > >> I pushed back on the idea at first due to added complexity. There > >> are a number of things that need to be addressed that aren't present > >> in the single assertion case. One of the sticker ones, to me, was > >> how to encode the assertions into the request. A SAML <Response> > >> element is a nice container for multiple assertions but using it in > >> this context seemed awkward at best. A new schema could be defined > >> or a special deliminator character could be used but that seems excess= ive > and kludgy respectively. > >> > >> What about pushing it up into the HTTP layer and allowing for > >> multiple occurrences of the assertion=3DXXX parameter in the POST body= ? > >> I don't see anything in core OAuth that would necessarily preclude doi= ng > this. > >> It seems cleaner and more lightweight than some of the other options. > >> And perhaps it could be a more general (not just SAML) method of > >> sending multiple assertions in a single assertion grant type request? > >> > >> It'd look something like this: > >> > >> POST /token.oauth2 HTTP/1.1 > >> Host: authz.example.net > >> Content-Type: application/x-www-form-urlencoded > >> > >> grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%2Fa > sse > >> rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st > >> assertion...]&assertion=3D > >> [...2nd assertion...]&assertion=3D[...3nd assertion...] > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_C8897C4CB75Ecmortimoresalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [OAUTH-WG] more than one assertion? Personally, I&#= 8217;d first like to see more concrete use-cases of how multiple assertions= are going to be used in practice.   Tony alluded to some abstrac= t use-cases, but fuller descriptions would probably help everyone out.

-cmort


On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

WFM.

> -----Original Message-----
> From: Brian Campbell [ma= ilto:bcampbell@pingidentity.com]
> Sent: Tuesday, August 10, 2010 9:03 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] more than one assertion?
>
> To be honest, I somehow overlooked that particular text - my mistake a= nd
> apologies. Reading it again, it probably does preclude parameters from=
> repeating, however, I can see some room for varied interpretations as = to if
> that's a strong normative requirement or a looser suggestion about an = error
> code that could be used in that circumstance.
>
> Perhaps it could be made more clear by adding some wording about it to= the
> end of the first part of sections 3&4 where it says: "Paramet= ers sent without
> a value MUST be treated as if they were omitted from the request. &nbs= p;The
> authorization server SHOULD ignore unrecognized request parameters.&qu= ot;?
>
> That said, does it make sense to relax the ban on repeating parameters= in
> some situations, like for the assertion parameter, to facilitate
> easy encoding of multiple assertions?   Anthony (Tony?) Nada= lin
> suggested that multiple assertions might be a common use case and I th= ink
> allowing for that via repeating assertion parameters is a cleaner and = more
> reusable way to do it.
>
> The text at the bottom of section for could say something like:
>
> "Parameters sent without a value MUST be treated as if they were = omitted
> from the request.  The authorization server SHOULD ignore unrecog= nized
> request parameters.  Parameters MUST NOT repeat unless otherwise = noted
> in the parameter definition."
>
> Then in 4.1.3. the assertion parameter could be something like this: >
>   "assertion
>          REQUIRED.  = The assertion(s).  This parameter MAY be repeated in the
> request,  if more than one
>           assertion = is needed for the access grant"
>
>
> Obviously Eran could improve on the actual text but hopefully that get= s the
> concept across?
>
>
>
> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:=
> > Do we need to clarify 4.3.1 "repeats a parameter" descr= iption for
> "invalid_request" error code does not preclude parameters fr= om repeating?
> I'm not sure.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.o= rg [mailto:oauth-bounces@ietf= .org] On
> >> Behalf Of Brian Campbell
> >> Sent: Monday, August 09, 2010 12:34 PM
> >> To: oauth
> >> Subject: [OAUTH-WG] more than one assertion?
> >>
> >> The question of allowing for multiple assertions in the SAML = profile
> >> came up recently. =A0See http://www.ietf.org/mail-
> >> archive/web/oauth/current/msg04068.html and several subsequen= t
> >> messages in the thread.
> >>
> >> I pushed back on the idea at first due to added complexity. = =A0There
> >> are a number of things that need to be addressed that aren't = present
> >> in the single assertion case. =A0 One of the sticker ones, to= me, was
> >> how to encode the assertions into the request. =A0 A SAML <= ;Response>
> >> element is a nice container for multiple assertions but using= it in
> >> this context seemed awkward at best. =A0A new schema could be= defined
> >> or a special deliminator character could be used but that see= ms excessive
> and kludgy respectively.
> >>
> >> What about pushing it up into the HTTP layer and allowing for=
> >> multiple occurrences of the assertion=3DXXX parameter in the = POST body?
> >> I don't see anything in core OAuth that would necessarily pre= clude doing
> this.
> >> =A0It seems cleaner and more lightweight than some of the oth= er options.
> >> =A0And perhaps it could be a more general (not just SAML) met= hod of
> >> sending multiple assertions in a single assertion grant type = request?
> >>
> >> It'd look something like this:
> >>
> >> =A0 POST /token.oauth2 HTTP/1.1
> >> =A0 Host: authz.example.net
> >> =A0 Content-Type: application/x-www-form-urlencoded
> >>
> >> =A0 =A0grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F= %2Foauth.net%2Fa
> sse
> >> =A0 =A0rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1= st
> >> assertion...]&assertion=3D
> >> =A0 =A0[...2nd assertion...]&assertion=3D[...3nd assertio= n...]
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https= ://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.or= g/mailman/listinfo/oauth

--_000_C8897C4CB75Ecmortimoresalesforcecom_-- From recordond@gmail.com Thu Aug 12 12:35:37 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 685D43A6903 for ; Thu, 12 Aug 2010 12:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hV7ay8sWCXBq for ; Thu, 12 Aug 2010 12:35:36 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id EDBD53A67C3 for ; Thu, 12 Aug 2010 12:35:32 -0700 (PDT) Received: by bwz7 with SMTP id 7so866196bwz.31 for ; Thu, 12 Aug 2010 12:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oNf39WjPZTzlTRahHp7Vh0Q6tokc3BbATcqco4Gcjls=; b=BGw9Kk3EVqclMVL0F2Co8yDn18Nyy8xiUVqK5k3kQ2B37Y/r6T1RYH0YkAOamura/d WyqYZbya4y61KXyF7uIvaLe5edg6bR1wZegSamnRjHBTNIFY6k3VUVQs8KgE9ltFimtA lO4X7qwkk56QesUoe2mKEDx8OpBfVBndvrJm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XO+x23u/7Zyw/iog0b6edihhfEPg99ndXAsPc777IQSJul+VBm/LbU9Z1aEjFq+c0K wTm0mFllwW8lwg+RSmVtQoqSIWeDHZvpe1gePJWFkTJi77FGb6o6bD3M6EKQKLtNphcV ZtS+ufcQvBiQxL1jLcZJxpWJ22pQ4ShoQ/uW4= MIME-Version: 1.0 Received: by 10.204.117.136 with SMTP id r8mr373883bkq.119.1281641769045; Thu, 12 Aug 2010 12:36:09 -0700 (PDT) Received: by 10.204.132.155 with HTTP; Thu, 12 Aug 2010 12:36:09 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 12 Aug 2010 15:36:09 -0400 Message-ID: From: David Recordon To: Chuck Mortimore Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 19:35:37 -0000 I've only been half following the recent assertion threads for this exact reason. I don't understand how these proposals are going to be used and worry about any additional complexity added to the spec. --David On Thu, Aug 12, 2010 at 1:24 PM, Chuck Mortimore wrote: > Personally, I=92d first like to see more concrete use-cases of how multip= le > assertions are going to be used in practice. =A0=A0Tony alluded to some a= bstract > use-cases, but fuller descriptions would probably help everyone out. > > -cmort > > > On 8/10/10 9:15 AM, "Eran Hammer-Lahav" wrote: > > WFM. > >> -----Original Message----- >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] >> Sent: Tuesday, August 10, 2010 9:03 AM >> To: Eran Hammer-Lahav >> Cc: oauth >> Subject: Re: [OAUTH-WG] more than one assertion? >> >> To be honest, I somehow overlooked that particular text - my mistake and >> apologies. Reading it again, it probably does preclude parameters from >> repeating, however, I can see some room for varied interpretations as to >> if >> that's a strong normative requirement or a looser suggestion about an >> error >> code that could be used in that circumstance. >> >> Perhaps it could be made more clear by adding some wording about it to t= he >> end of the first part of sections 3&4 where it says: "Parameters sent >> without >> a value MUST be treated as if they were omitted from the request. =A0The >> authorization server SHOULD ignore unrecognized request parameters."? >> >> That said, does it make sense to relax the ban on repeating parameters i= n >> some situations, like for the assertion parameter, to facilitate >> easy encoding of multiple assertions? =A0=A0Anthony (Tony?) Nadalin >> suggested that multiple assertions might be a common use case and I thin= k >> allowing for that via repeating assertion parameters is a cleaner and mo= re >> reusable way to do it. >> >> The text at the bottom of section for could say something like: >> >> "Parameters sent without a value MUST be treated as if they were omitted >> from the request. =A0The authorization server SHOULD ignore unrecognized >> request parameters. =A0Parameters MUST NOT repeat unless otherwise noted >> in the parameter definition." >> >> Then in 4.1.3. the assertion parameter could be something like this: >> >> =A0=A0"assertion >> =A0=A0=A0=A0=A0=A0=A0=A0=A0REQUIRED. =A0The assertion(s). =A0This parame= ter MAY be repeated in >> the >> request, =A0if more than one >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0assertion is needed for the access grant" >> >> >> Obviously Eran could improve on the actual text but hopefully that gets >> the >> concept across? >> >> >> >> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav >> wrote: >> > Do we need to clarify 4.3.1 "repeats a parameter" description for >> "invalid_request" error code does not preclude parameters from repeating= ? >> I'm not sure. >> > >> > EHL >> > >> >> -----Original Message----- >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> >> Behalf Of Brian Campbell >> >> Sent: Monday, August 09, 2010 12:34 PM >> >> To: oauth >> >> Subject: [OAUTH-WG] more than one assertion? >> >> >> >> The question of allowing for multiple assertions in the SAML profile >> >> came up recently. =A0See http://www.ietf.org/mail- >> >> archive/web/oauth/current/msg04068.html and several subsequent >> >> messages in the thread. >> >> >> >> I pushed back on the idea at first due to added complexity. =A0There >> >> are a number of things that need to be addressed that aren't present >> >> in the single assertion case. =A0 One of the sticker ones, to me, was >> >> how to encode the assertions into the request. =A0 A SAML >> >> element is a nice container for multiple assertions but using it in >> >> this context seemed awkward at best. =A0A new schema could be defined >> >> or a special deliminator character could be used but that seems >> >> excessive >> and kludgy respectively. >> >> >> >> What about pushing it up into the HTTP layer and allowing for >> >> multiple occurrences of the assertion=3DXXX parameter in the POST bod= y? >> >> I don't see anything in core OAuth that would necessarily preclude >> >> doing >> this. >> >> =A0It seems cleaner and more lightweight than some of the other optio= ns. >> >> =A0And perhaps it could be a more general (not just SAML) method of >> >> sending multiple assertions in a single assertion grant type request? >> >> >> >> It'd look something like this: >> >> >> >> =A0 POST /token.oauth2 HTTP/1.1 >> >> =A0 Host: authz.example.net >> >> =A0 Content-Type: application/x-www-form-urlencoded >> >> >> >> =A0 =A0grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net= %2Fa >> sse >> >> =A0 =A0rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st >> >> assertion...]&assertion=3D >> >> =A0 =A0[...2nd assertion...]&assertion=3D[...3nd assertion...] >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From beaton@google.com Thu Aug 12 12:37:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211F13A6A09 for ; Thu, 12 Aug 2010 12:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.083 X-Spam-Level: X-Spam-Status: No, score=-104.083 tagged_above=-999 required=5 tests=[AWL=1.894, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOGsQDFMjuch for ; Thu, 12 Aug 2010 12:37:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 1F49B3A69DB for ; Thu, 12 Aug 2010 12:37:37 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id o7CJcEQU011994 for ; Thu, 12 Aug 2010 12:38:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281641894; bh=ouG8Y4BV8F3CTEIojpUQNsbYbiE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=VfSzIcTE1PVGQQ1Ngm3adiWhNr8xvnNKba94Lfk42d7L1fk1XwMwLdC7XGjcccyQG 5/dSDXWVwAXEDZdU3tZ3Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Apkq7UwtigcUOwUqDUx8AlGazSSMoVNa7xm2sKQ58xskx7ZFasu1yQQ3betsbFSFu iFLmnCOHliPJQiyjbasiw== Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by hpaq5.eem.corp.google.com with ESMTP id o7CJbe8L015133 for ; Thu, 12 Aug 2010 12:38:13 -0700 Received: by pzk6 with SMTP id 6so539205pzk.3 for ; Thu, 12 Aug 2010 12:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.148.2 with SMTP id v2mr453285wfd.115.1281641892812; Thu, 12 Aug 2010 12:38:12 -0700 (PDT) Received: by 10.143.46.3 with HTTP; Thu, 12 Aug 2010 12:38:12 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 12 Aug 2010 12:38:12 -0700 Message-ID: From: Brian Eaton To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 19:37:39 -0000 On Thu, Aug 12, 2010 at 12:36 PM, David Recordon wrote: > I've only been half following the recent assertion threads for this > exact reason. I don't understand how these proposals are going to be > used and worry about any additional complexity added to the spec. Likewise. From bcampbell@pingidentity.com Thu Aug 12 13:02:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BBD63A65A5 for ; Thu, 12 Aug 2010 13:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.786 X-Spam-Level: X-Spam-Status: No, score=-5.786 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkmUA0Wau++z for ; Thu, 12 Aug 2010 13:02:03 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 180153A6995 for ; Thu, 12 Aug 2010 13:01:46 -0700 (PDT) Received: from source ([209.85.215.51]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTGRTTzJ6RZ6f0tw8cfJ1l64SNlijJxel@postini.com; Thu, 12 Aug 2010 13:02:24 PDT Received: by ewy21 with SMTP id 21so1160008ewy.24 for ; Thu, 12 Aug 2010 13:02:22 -0700 (PDT) Received: by 10.216.157.81 with SMTP id n59mr360110wek.84.1281643342315; Thu, 12 Aug 2010 13:02:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.60.136 with HTTP; Thu, 12 Aug 2010 13:01:52 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Thu, 12 Aug 2010 14:01:52 -0600 Message-ID: To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 20:02:04 -0000 I generally agree more with Chuck, David and Brain E than I don't. But I do think that someone will find a pragmatic reason for > 1 assertion eventually and I think the proposal earlier in this thread to allow for multiple occurrences of the assertion parameter in the core spec will make that easier for a number of instantiations of the assertion flow (grant type) at a later time. It adds some complexity but I don't think a lot. And specifications or pairwise agreements building on the assertion flow could easily constrain down to a single assertion, if it suits the profile. That's the only change proposal to the core spec that's come out of discussion around my I-D http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt (that I can think of). I'm still not sure if it makes sense to allow for multiple assertions in the next draft of that, but allowing for multiple assertion params in core sure seems like a cleaner way to do it. Yaron's proposal for a Section 2.2 on Client Assertions is a change to core as well (latest in that thread: http://www.ietf.org/mail-archive/web/oauth/current/msg04154.html). However, even though it uses the term assertion similarly, it's a distinct issue from the SAML work. The latter is a SAML based usage of the assertion grant type while the former I think of it more as a means of allowing for stronger forms of client authentication than just a client password/secret. I guess both could be used in a two-legged style interaction (or used together) and maybe that's where it starts to get confusing... On Thu, Aug 12, 2010 at 1:38 PM, Brian Eaton wrote: > On Thu, Aug 12, 2010 at 12:36 PM, David Recordon wrote: >> I've only been half following the recent assertion threads for this >> exact reason. I don't understand how these proposals are going to be >> used and worry about any additional complexity added to the spec. > > Likewise. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From recordond@gmail.com Thu Aug 12 13:04:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB9C3A68CF for ; Thu, 12 Aug 2010 13:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnaD53yU-Lgk for ; Thu, 12 Aug 2010 13:04:12 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6447F3A65A5 for ; Thu, 12 Aug 2010 13:04:12 -0700 (PDT) Received: by bwz7 with SMTP id 7so886965bwz.31 for ; Thu, 12 Aug 2010 13:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BBPveHYoufB+Er5L7WGs1RR5Hi5rmZnvWB2NwKaDHx4=; b=LXjGBbjpdQZFGjXUwQlzlASV5TizjLHumvc68THhmvoz21F4KbXyM2Wg0F+NfW/yqv 7qcWjC8mXkjbwQ87aHW3bZamb7kWZXctQj9j26PZjbzoekb8v4QZhvV9Mxd6JJxRKXzA 56a4aayixJlK9SncQh78PjjfZNtNb4C/pdPhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PVyZlfiKT7EcqhfGOVa9Nph/Ggu/wKqJzJChYq7Jm0L9UVOiTlwYY2Y5qCOc6GAFTN U6Hsl9iZ1Aqu+DAwmuY24bQNEP1bXHiI9sJVAMFHrswZ4nF92nuoY7mKvBOvfcTLT4cL bFXFvT/wJFlV5P2d5XcMy0/tp9cppWHIY/fx4= MIME-Version: 1.0 Received: by 10.204.56.84 with SMTP id x20mr415959bkg.68.1281643488990; Thu, 12 Aug 2010 13:04:48 -0700 (PDT) Received: by 10.204.132.155 with HTTP; Thu, 12 Aug 2010 13:04:48 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 12 Aug 2010 16:04:48 -0400 Message-ID: From: David Recordon To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 20:04:13 -0000 Given that, would you strongly object to these proposals being written in a separate document than the core spec? The device flow is a good example of where we're doing this. We really think that it will be useful, are working on implementations, but it hasn't yet been proven in production. On Thu, Aug 12, 2010 at 4:01 PM, Brian Campbell wrote: > I generally agree more with Chuck, David and Brain E than I don't. > But I do think that someone will find a pragmatic reason for > 1 > assertion eventually and I think the proposal earlier in this thread > to allow for multiple occurrences of the assertion parameter in the > core spec will make that easier for a number of instantiations of the > assertion flow (grant type) at a later time. =A0It adds some complexity > but I don't think a lot. =A0And specifications or pairwise agreements > building on the assertion flow could easily constrain down to a single > assertion, if it suits the profile. > > That's the only change proposal to the core spec that's come out of > discussion around my I-D > http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt (that I can > think of). =A0I'm still not sure if it makes sense to allow for multiple > assertions in the next draft of that, but allowing for multiple > assertion params in core sure seems like a cleaner way to do it. > > Yaron's proposal for a Section 2.2 on Client Assertions is a change to > core as well (latest in that thread: > http://www.ietf.org/mail-archive/web/oauth/current/msg04154.html). > However, even though it uses the term assertion similarly, it's a > distinct issue from the SAML work. =A0The latter is a SAML based usage > of the assertion grant type while the former I think of it more as a > means of allowing for stronger forms of client authentication than > just a client password/secret. > > I guess both could be used in a two-legged style interaction (or used > together) and maybe that's where it starts to get confusing... > > > > On Thu, Aug 12, 2010 at 1:38 PM, Brian Eaton wrote: >> On Thu, Aug 12, 2010 at 12:36 PM, David Recordon w= rote: >>> I've only been half following the recent assertion threads for this >>> exact reason. I don't understand how these proposals are going to be >>> used and worry about any additional complexity added to the spec. >> >> Likewise. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > From bcampbell@pingidentity.com Thu Aug 12 13:07:54 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA493A6840 for ; Thu, 12 Aug 2010 13:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqiaF5zR1RZ8 for ; Thu, 12 Aug 2010 13:07:53 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with SMTP id CB6703A67AE for ; Thu, 12 Aug 2010 13:07:52 -0700 (PDT) Received: from source ([209.85.215.175]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTGRUvXOp8Wam1usv2aITDkQDqBjPUJwL@postini.com; Thu, 12 Aug 2010 13:08:30 PDT Received: by eyx24 with SMTP id 24so1247512eyx.34 for ; Thu, 12 Aug 2010 13:08:29 -0700 (PDT) Received: by 10.216.62.206 with SMTP id y56mr396327wec.59.1281643709173; Thu, 12 Aug 2010 13:08:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.60.136 with HTTP; Thu, 12 Aug 2010 13:07:59 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 12 Aug 2010 14:07:59 -0600 Message-ID: To: Chuck Mortimore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML people X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 20:07:54 -0000 On Thu, Aug 12, 2010 at 11:19 AM, Chuck Mortimore wrote: > I think it would be reasonable to loosen the language to reflect that the > subject is who access will be granted to. =A0=A0It may or may not be the > resource owner, I agree. Any thoughts on what that would look like in the spec? Something like "The assertion MUST contain a element. The MAY identify the resource owner for whom the access token is being requested."? Or just drop the language about resource owner all together? Or something else? What about the two bullets on AuthnStatement? o If the assertion issuer authenticated the subject, the assertion SHOULD contain a single representing that authentication event. o If the assertion was issued with the intention that the client act autonomously on behalf of the subject, an SHOULD NOT be included. They kind of, but not completely, imply/assume some explicit relationship between the subject and resource owner. From torsten@lodderstedt.net Fri Aug 13 00:50:39 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8450D3A68B9 for ; Fri, 13 Aug 2010 00:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.657 X-Spam-Level: X-Spam-Status: No, score=-0.657 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRwM6reW5DNk for ; Fri, 13 Aug 2010 00:50:38 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id 3E0023A6870 for ; Fri, 13 Aug 2010 00:50:36 -0700 (PDT) Received: from [80.187.108.154] (helo=[10.164.83.122]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Ojp2l-0006HC-9S; Fri, 13 Aug 2010 09:51:11 +0200 References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Fri, 13 Aug 2010 09:50:22 +0200 To: Brian Campbell X-Df-Sender: 141509 Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 07:50:39 -0000 multiple (SAML) assertions also mean multiple subject statements. Are there a= ny constraints regarding the relations among those subjects (identities)?=20= regards, Torsten. Am 12.08.2010 um 22:01 schrieb Brian Campbell : > I generally agree more with Chuck, David and Brain E than I don't. > But I do think that someone will find a pragmatic reason for > 1 > assertion eventually and I think the proposal earlier in this thread > to allow for multiple occurrences of the assertion parameter in the > core spec will make that easier for a number of instantiations of the > assertion flow (grant type) at a later time. It adds some complexity > but I don't think a lot. And specifications or pairwise agreements > building on the assertion flow could easily constrain down to a single > assertion, if it suits the profile. >=20 > That's the only change proposal to the core spec that's come out of > discussion around my I-D > http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt (that I can > think of). I'm still not sure if it makes sense to allow for multiple > assertions in the next draft of that, but allowing for multiple > assertion params in core sure seems like a cleaner way to do it. >=20 > Yaron's proposal for a Section 2.2 on Client Assertions is a change to > core as well (latest in that thread: > http://www.ietf.org/mail-archive/web/oauth/current/msg04154.html). > However, even though it uses the term assertion similarly, it's a > distinct issue from the SAML work. The latter is a SAML based usage > of the assertion grant type while the former I think of it more as a > means of allowing for stronger forms of client authentication than > just a client password/secret. >=20 > I guess both could be used in a two-legged style interaction (or used > together) and maybe that's where it starts to get confusing... >=20 >=20 >=20 > On Thu, Aug 12, 2010 at 1:38 PM, Brian Eaton wrote: >> On Thu, Aug 12, 2010 at 12:36 PM, David Recordon wr= ote: >>> I've only been half following the recent assertion threads for this >>> exact reason. I don't understand how these proposals are going to be >>> used and worry about any additional complexity added to the spec. >>=20 >> Likewise. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Aug 13 11:28:24 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 528B33A6850 for ; Fri, 13 Aug 2010 11:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ys3ybsL+fsmQ for ; Fri, 13 Aug 2010 11:28:23 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 0E3613A6805 for ; Fri, 13 Aug 2010 11:28:22 -0700 (PDT) Received: (qmail 2811 invoked from network); 13 Aug 2010 18:28:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Aug 2010 18:28:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 13 Aug 2010 11:28:36 -0700 From: Eran Hammer-Lahav To: David Recordon , Chuck Mortimore Date: Fri, 13 Aug 2010 11:28:30 -0700 Thread-Topic: [OAUTH-WG] more than one assertion? Thread-Index: Acs6VaJxy7X7eVMtTB2oylQ7QN5ckwAv4jnw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F1D6A06@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:28:24 -0000 The only change I'm aligned with is being more specific about repeating par= ameters and potentially allowing the assertion parameter to repeat. That's = it for the core spec. The SAML spec should be more specific about allowing = or not multiple assertions for the given type URI. EHL > -----Original Message----- > From: David Recordon [mailto:recordond@gmail.com] > Sent: Thursday, August 12, 2010 12:36 PM > To: Chuck Mortimore > Cc: Eran Hammer-Lahav; Brian Campbell; oauth > Subject: Re: [OAUTH-WG] more than one assertion? >=20 > I've only been half following the recent assertion threads for this exact > reason. I don't understand how these proposals are going to be used and > worry about any additional complexity added to the spec. >=20 > --David >=20 >=20 > On Thu, Aug 12, 2010 at 1:24 PM, Chuck Mortimore > wrote: > > Personally, I'd first like to see more concrete use-cases of how > > multiple assertions are going to be used in practice. =A0=A0Tony allude= d > > to some abstract use-cases, but fuller descriptions would probably help > everyone out. > > > > -cmort > > > > > > On 8/10/10 9:15 AM, "Eran Hammer-Lahav" > wrote: > > > > WFM. > > > >> -----Original Message----- > >> From: Brian Campbell [mailto:bcampbell@pingidentity.com] > >> Sent: Tuesday, August 10, 2010 9:03 AM > >> To: Eran Hammer-Lahav > >> Cc: oauth > >> Subject: Re: [OAUTH-WG] more than one assertion? > >> > >> To be honest, I somehow overlooked that particular text - my mistake > >> and apologies. Reading it again, it probably does preclude parameters > >> from repeating, however, I can see some room for varied > >> interpretations as to if that's a strong normative requirement or a > >> looser suggestion about an error code that could be used in that > >> circumstance. > >> > >> Perhaps it could be made more clear by adding some wording about it > >> to the end of the first part of sections 3&4 where it says: > >> "Parameters sent without a value MUST be treated as if they were > >> omitted from the request. =A0The authorization server SHOULD ignore > >> unrecognized request parameters."? > >> > >> That said, does it make sense to relax the ban on repeating > >> parameters in some situations, like for the assertion parameter, to > >> facilitate easy encoding of multiple assertions? =A0=A0Anthony (Tony?) > >> Nadalin suggested that multiple assertions might be a common use case > >> and I think allowing for that via repeating assertion parameters is a > >> cleaner and more reusable way to do it. > >> > >> The text at the bottom of section for could say something like: > >> > >> "Parameters sent without a value MUST be treated as if they were > >> omitted from the request. =A0The authorization server SHOULD ignore > >> unrecognized request parameters. =A0Parameters MUST NOT repeat unless > >> otherwise noted in the parameter definition." > >> > >> Then in 4.1.3. the assertion parameter could be something like this: > >> > >> =A0=A0"assertion > >> =A0=A0=A0=A0=A0=A0=A0=A0=A0REQUIRED. =A0The assertion(s). =A0This para= meter MAY be repeated > >> in the request, =A0if more than one > >> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0assertion is needed for the access grant= " > >> > >> > >> Obviously Eran could improve on the actual text but hopefully that > >> gets the concept across? > >> > >> > >> > >> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav > >> wrote: > >> > Do we need to clarify 4.3.1 "repeats a parameter" description for > >> "invalid_request" error code does not preclude parameters from > repeating? > >> I'm not sure. > >> > > >> > EHL > >> > > >> >> -----Original Message----- > >> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> >> Behalf Of Brian Campbell > >> >> Sent: Monday, August 09, 2010 12:34 PM > >> >> To: oauth > >> >> Subject: [OAUTH-WG] more than one assertion? > >> >> > >> >> The question of allowing for multiple assertions in the SAML > >> >> profile came up recently. =A0See http://www.ietf.org/mail- > >> >> archive/web/oauth/current/msg04068.html and several subsequent > >> >> messages in the thread. > >> >> > >> >> I pushed back on the idea at first due to added complexity. =A0Ther= e > >> >> are a number of things that need to be addressed that aren't > >> >> present in the single assertion case. =A0 One of the sticker ones, > >> >> to me, was how to encode the assertions into the request. =A0 A SAM= L > >> >> element is a nice container for multiple assertions but > >> >> using it in this context seemed awkward at best. =A0A new schema > >> >> could be defined or a special deliminator character could be used > >> >> but that seems excessive > >> and kludgy respectively. > >> >> > >> >> What about pushing it up into the HTTP layer and allowing for > >> >> multiple occurrences of the assertion=3DXXX parameter in the POST > body? > >> >> I don't see anything in core OAuth that would necessarily preclude > >> >> doing > >> this. > >> >> =A0It seems cleaner and more lightweight than some of the other > options. > >> >> =A0And perhaps it could be a more general (not just SAML) method of > >> >> sending multiple assertions in a single assertion grant type reques= t? > >> >> > >> >> It'd look something like this: > >> >> > >> >> =A0 POST /token.oauth2 HTTP/1.1 > >> >> =A0 Host: authz.example.net > >> >> =A0 Content-Type: application/x-www-form-urlencoded > >> >> > >> > >> =A0 =A0grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%= 2Fa > >> sse > >> >> =A0 =A0rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st > >> >> assertion...]&assertion=3D > >> >> =A0 =A0[...2nd assertion...]&assertion=3D[...3nd assertion...] > >> >> _______________________________________________ > >> >> OAuth mailing list > >> >> OAuth@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/oauth > >> > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > From bcampbell@pingidentity.com Fri Aug 13 12:58:09 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C17E3A67E2 for ; Fri, 13 Aug 2010 12:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5nuq8+87Yjv for ; Fri, 13 Aug 2010 12:58:08 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 173843A63D3 for ; Fri, 13 Aug 2010 12:58:07 -0700 (PDT) Received: from source ([74.125.82.46]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTGWj9Pk2Fd9b6a2u5Bs9LX3dpNK9qzwY@postini.com; Fri, 13 Aug 2010 12:58:45 PDT Received: by mail-ww0-f46.google.com with SMTP id 15so192420wwe.27 for ; Fri, 13 Aug 2010 12:58:44 -0700 (PDT) Received: by 10.227.154.211 with SMTP id p19mr1954495wbw.19.1281729524156; Fri, 13 Aug 2010 12:58:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.60.136 with HTTP; Fri, 13 Aug 2010 12:58:14 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F1D6A06@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72343B3F1D6A06@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Fri, 13 Aug 2010 13:58:14 -0600 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:58:09 -0000 On Fri, Aug 13, 2010 at 12:28 PM, Eran Hammer-Lahav wrote: > The only change I'm aligned with is being more specific about repeating parameters > and potentially allowing the assertion parameter to repeat. That's it for the core spec. Thanks for clarifying that Eran. That's the only change I was suggesting here. And if others think it's too complicated, I'm not married to it. Just seemed like a potentially useful thing. > The SAML spec should be more specific about allowing or not multiple assertions for the given type URI. Yes, and it will be. From bcampbell@pingidentity.com Fri Aug 13 13:54:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD723A694A for ; Fri, 13 Aug 2010 13:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05o4PhNBSy2H for ; Fri, 13 Aug 2010 13:54:58 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by core3.amsl.com (Postfix) with SMTP id 59B3D3A6800 for ; Fri, 13 Aug 2010 13:54:58 -0700 (PDT) Received: from source ([74.125.82.52]) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKTGWxRoOTXlEuE7XVDU7q0Erg2AfOAWPC@postini.com; Fri, 13 Aug 2010 13:55:35 PDT Received: by mail-ww0-f52.google.com with SMTP id 18so2532496wwi.33 for ; Fri, 13 Aug 2010 13:55:34 -0700 (PDT) Received: by 10.216.188.20 with SMTP id z20mr119322wem.51.1281732934175; Fri, 13 Aug 2010 13:55:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.60.136 with HTTP; Fri, 13 Aug 2010 13:55:04 -0700 (PDT) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Fri, 13 Aug 2010 14:55:04 -0600 Message-ID: To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 20:54:59 -0000 On Thu, Aug 12, 2010 at 2:04 PM, David Recordon wrote: > Given that, would you strongly object to these proposals being written > in a separate document than the core spec? The device flow is a good > example of where we're doing this. We really think that it will be > useful, are working on implementations, but it hasn't yet been proven > in production. The assertion flow should stay in core (others have expressed this opinion as well). I've got interop tested code built on that that is about to GA. As far as the client assertions, I do believe there's real value in having a clean extension point for stronger forms of client authentication. Yaron's proposed language does a pretty good job I think. But if it can be done in a simpler way, let's discuss. I'll probably regret saying this, but what about not using the word "assertion" for stronger client auth options? That might help eliminate some confusion. From paul.tarjan@facebook.com Fri Aug 13 14:30:35 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAC773A698A for ; Fri, 13 Aug 2010 14:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.45 X-Spam-Level: X-Spam-Status: No, score=-100.45 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpX6bUPrnT7r for ; Fri, 13 Aug 2010 14:30:34 -0700 (PDT) Received: from mx-out.facebook.com (outmail004.snc1.tfbnw.net [69.63.178.163]) by core3.amsl.com (Postfix) with ESMTP id 00C263A679F for ; Fri, 13 Aug 2010 14:30:32 -0700 (PDT) Received: from [10.18.255.139] ([10.18.255.139:46089] helo=mail.thefacebook.com) by mta004.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 91/3C-13638-D99B56C4; Fri, 13 Aug 2010 14:31:10 -0700 Received: from SC-MBX03.TheFacebook.com ([169.254.2.61]) by sc-hub03.TheFacebook.com ([fe80::1cfe:1f6b:8b35:cf7f%11]) with mapi; Fri, 13 Aug 2010 14:31:07 -0700 From: Paul Tarjan To: OAuth WG Thread-Topic: Returning HTTP 200 on Error for JSONP Thread-Index: AQHLOy7WyjYGNn3uj0G9ZJ7bfvdE1w== Date: Fri, 13 Aug 2010 21:31:05 +0000 Message-ID: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1643FCF1841F41FFB8A843269320CFA8facebookcom_" MIME-Version: 1.0 Subject: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 21:30:36 -0000 --_000_1643FCF1841F41FFB8A843269320CFA8facebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Fellow OAuthers, If a resource wants to return data via the JSONP mechanism then it MUST ret= urn an HTTP 200 error code, or else the browser won't actually call the cal= lback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on error= s which won't ever tell the client that an error happens. For example: GET /me?callback=3Djsonp_cb HTTP/1.1 Host: graph.facebook.com HTTP/1.1 200 OK Content-Type: text/javascript; charset=3DUTF-8 Content-Length: 152 jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query infor= mation about the current user." }); would never get sent to the browser if we obeyed the spec and sent it as an= HTTP 400. --- So, I recommend we add wording to 5.2.1 like: If the protected resource is issuing a response that requires a different H= TTP status code than the one specified (for example, JSONP), then it MAY us= e an alternate HTTP code. The server should make it clear which parameters = trigger this mode so that clients know not to rely on the HTTP status code = for error detection. Paul --_000_1643FCF1841F41FFB8A843269320CFA8facebookcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <639d07ff-416c-4aac-8bb8-fb60ba894092> Content-Transfer-Encoding: quoted-printable Hi Fellow OAuthers,

If a resou= rce wants to return data via the JSONP mechanism then it MUST return an HTT= P 200 error code, or else the browser won't actually call the callback. The= OAuth spec as it stands requires HTTP 400 or 401 or 403 on errors which wo= n't ever tell the client that an error happens. 

For example:
GET /me?callback=3Djsonp_cb HTTP/1.1
Host: graph.facebook.com

HTTP/1.1 200 OK
= Content-Type: text/javascript; charset=3DUTF-8
Content-Length: 152

jsonp_cb({
   "error": "= invalid_request",
   "error_description"= : "An active access token must be used to query information about the = current user."
});

would never get sent = to the browser if we obeyed the spec and sent it as an HTTP 400.

---=
So, I recommend we add wording to 5.2.1 like:

If the protected r= esource is issuing a response that requires a different HTTP status code th= an the one specified (for example, JSONP), then it MAY use an alternate HTT= P code. The server should make it clear which parameters trigger this mode = so that clients know not to rely on the HTTP status code for error detectio= n.


Paul
= --_000_1643FCF1841F41FFB8A843269320CFA8facebookcom_-- From lshepard@facebook.com Sun Aug 15 22:16:28 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395B73A6841 for ; Sun, 15 Aug 2010 22:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.071 X-Spam-Level: X-Spam-Status: No, score=-102.071 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdNY-V5UkW2B for ; Sun, 15 Aug 2010 22:16:22 -0700 (PDT) Received: from mx-out.facebook.com (outmail021.snc1.tfbnw.net [69.63.178.180]) by core3.amsl.com (Postfix) with ESMTP id 6476B3A67ED for ; Sun, 15 Aug 2010 22:16:21 -0700 (PDT) Received: from [10.18.255.140] ([10.18.255.140:19237] helo=mail.thefacebook.com) by mta011.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 64/49-04646-9C9C86C4; Sun, 15 Aug 2010 22:16:57 -0700 Received: from SC-MBX05.TheFacebook.com ([169.254.4.91]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Sun, 15 Aug 2010 22:16:56 -0700 From: Luke Shepard To: Paul Tarjan Thread-Topic: [OAUTH-WG] Returning HTTP 200 on Error for JSONP Thread-Index: AQHLPQI+gG+TVKVrt0q8LNtlx+EW4g== Date: Mon, 16 Aug 2010 05:16:51 +0000 Message-ID: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> In-Reply-To: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D274280691804A5B98D5BFD68AF74EEAfacebookcom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 05:16:28 -0000 --_000_D274280691804A5B98D5BFD68AF74EEAfacebookcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote: Hi Fellow OAuthers, If a resource wants to return data via the JSONP mechanism then it MUST ret= urn an HTTP 200 error code, or else the browser won't actually call the cal= lback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on error= s which won't ever tell the client that an error happens. For example: GET /me?callback=3Djsonp_cb HTTP/1.1 Host: graph.facebook.com HTTP/1.1 200 OK Content-Type: text/javascript; charset=3DUTF-8 Content-Length: 152 jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query infor= mation about the current user." }); would never get sent to the browser if we obeyed the spec and sent it as an= HTTP 400. --- So, I recommend we add wording to 5.2.1 like: If the protected resource is issuing a response that requires a different H= TTP status code than the one specified (for example, JSONP), then it MAY us= e an alternate HTTP code. The server should make it clear which parameters = trigger this mode so that clients know not to rely on the HTTP status code = for error detection. Paul _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_D274280691804A5B98D5BFD68AF74EEAfacebookcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <296cacc0-9e71-4f70-8e1c-ff8a09c88abb> Content-Transfer-Encoding: quoted-printable +1

On Aug 1= 3, 2010, at 2:31 PM, Paul Tarjan wrote:

Hi Fellow = OAuthers,

If a resource wants to return data via the JSONP mechanism= then it MUST return an HTTP 200 error code, or else the browser won't actu= ally call the callback. The OAuth spec as it stands requires HTTP 400 or 40= 1 or 403 on errors which won't ever tell the client that an error happens.&= nbsp;

For example:

GET /me?callback=3Djsonp_cb HTTP/1.1<= br>Host: graph.facebook.com=

HTTP/1.1 200 OK
Content-Type: text/javascript; charset=3DUTF-8Content-Length: 152

jsonp_cb({
  = ; "error": "invalid_request",
   &q= uot;error_description": "An active access token must be used to q= uery information about the current user."
});

would never get sent to the browser if we obeyed the spec and sent it= as an HTTP 400.

---
So, I recommend we add wording to 5.2.1 like= :

If the protected resource is issuing a response that requires a di= fferent HTTP status code than the one specified (for example, JSONP), then = it MAY use an alternate HTTP code. The server should make it clear which pa= rameters trigger this mode so that clients know not to rely on the HTTP sta= tus code for error detection.


Paul
__________________= _____________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/o= auth

= --_000_D274280691804A5B98D5BFD68AF74EEAfacebookcom_-- From aaron@parecki.com Mon Aug 16 08:48:58 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F1D3A67F9 for ; Mon, 16 Aug 2010 08:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.732, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLGnXUWuTL1A for ; Mon, 16 Aug 2010 08:48:57 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 165DF3A67F1 for ; Mon, 16 Aug 2010 08:48:56 -0700 (PDT) Received: by eyb7 with SMTP id 7so2674884eyb.31 for ; Mon, 16 Aug 2010 08:49:32 -0700 (PDT) Received: by 10.213.48.193 with SMTP id s1mr2903828ebf.20.1281973772309; Mon, 16 Aug 2010 08:49:32 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx.google.com with ESMTPS id u9sm10211607eeh.5.2010.08.16.08.49.30 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Aug 2010 08:49:30 -0700 (PDT) Received: by eyb7 with SMTP id 7so2674838eyb.31 for ; Mon, 16 Aug 2010 08:49:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.236.226 with SMTP id w76mr4560967weq.7.1281973769582; Mon, 16 Aug 2010 08:49:29 -0700 (PDT) Received: by 10.216.139.27 with HTTP; Mon, 16 Aug 2010 08:49:29 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> Date: Mon, 16 Aug 2010 08:49:29 -0700 Message-ID: From: Aaron Parecki To: OAuth WG Content-Type: multipart/alternative; boundary=000e0cd402c425ba81048df2c721 Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 15:48:58 -0000 --000e0cd402c425ba81048df2c721 Content-Type: text/plain; charset=UTF-8 Excellent point. Would it be worth it to include a new error_code parameter in the JSON response so that clients have a way to get the http status code from the data available in the jsonp response? The response in this case might look like this jsonp_cb({ "error_code": 400, "error": "invalid_request", "error_description": "An active access token must be used to query information about the current user." }); Aaron On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard wrote: > +1 > > On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote: > > Hi Fellow OAuthers, > > If a resource wants to return data via the JSONP mechanism then it MUST > return an HTTP 200 error code, or else the browser won't actually call the > callback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on > errors which won't ever tell the client that an error happens. > > For example: > > GET /me?callback=jsonp_cb HTTP/1.1 > Host: graph.facebook.com > > HTTP/1.1 200 OK > Content-Type: text/javascript; charset=UTF-8 > Content-Length: 152 > > jsonp_cb({ > "error": "invalid_request", > "error_description": "An active access token must be used to query > information about the current user." > }); > > would never get sent to the browser if we obeyed the spec and sent it as an > HTTP 400. > > --- > So, I recommend we add wording to 5.2.1 like: > > If the protected resource is issuing a response that requires a different > HTTP status code than the one specified (for example, JSONP), then it MAY > use an alternate HTTP code. The server should make it clear which parameters > trigger this mode so that clients know not to rely on the HTTP status code > for error detection. > > > Paul > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --000e0cd402c425ba81048df2c721 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Excellent point. Would it be worth it to include a new error_code parameter in the JSON response so that clients have a way to get the http status code from the data available in the jsonp response?

The response in this case might look like this
jsonp_cb({
=C2=A0=C2=A0 "error_code": 400,
=C2=A0=C2=A0 "error": "invalid_request&quo= t;,
=C2=A0=C2=A0 "error_description": "An active access token mu= st be used to query
information about the current user."
});

Aaron


On Sun, Aug 15, 2010 at 1= 0:16 PM, Luke Shepard <lshepard@facebook.com> wrote:
+1

<= div class=3D"h5">
On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote:
=
Hi Fellow OAuthers,

If a resource wants to return data via the JSONP= mechanism then it MUST return an HTTP 200 error code, or else the browser = won't actually call the callback. The OAuth spec as it stands requires = HTTP 400 or 401 or 403 on errors which won't ever tell the client that = an error happens.=C2=A0

For example:

GET /me?callback=3Djsonp_cb HTTP/1.1
Host:= =C2=A0graph.facebo= ok.com

HTTP/1.1 200 OK
Content-Type: text/javascript; charset= =3DUTF-8
Content-Length:=C2=A0152

jsonp_cb({
=C2=A0=C2=A0 "error": "invalid_request",
=C2= =A0=C2=A0 "error_description": "An active access token must = be used to query information about the current user."
});

would never get sent to the browser if we obey= ed the spec and sent it as an HTTP 400.

---
So, I recommend we ad= d wording to 5.2.1 like:

If the protected resource is issuing a resp= onse that requires a different HTTP status code than the one specified (for= example, JSONP), then it MAY use an alternate HTTP code. The server should= make it clear which parameters trigger this mode so that clients know not = to rely on the HTTP status code for error detection.


Paul
_____________________= __________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mail= man/listinfo/oauth


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


--000e0cd402c425ba81048df2c721-- From jpanzer@google.com Mon Aug 16 09:11:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CB683A67FE for ; Mon, 16 Aug 2010 09:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.917 X-Spam-Level: X-Spam-Status: No, score=-100.917 tagged_above=-999 required=5 tests=[AWL=3.571, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkYs--4jcd9C for ; Mon, 16 Aug 2010 09:11:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id C99CF3A67F1 for ; Mon, 16 Aug 2010 09:11:18 -0700 (PDT) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id o7GGBrlj015580 for ; Mon, 16 Aug 2010 09:11:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1281975114; bh=5DD5e7qRqukIPsu4hpHo0OoCWbg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=qiul8MGUO0pa+7XK4HEKM1aGjVXoeEaFTGU2fl4ERgzT/5++eIOsBbaXTRliGttWo r4YXMlHACznF2uJbJ2/vQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Wfc57Gau7dSiTsnJul4NgOiPoZ2Ejf9ND1YJw7sEad7zt85sPqwbN8FRwcKPmIymm Ep5kvQ9LLjMkwjThHfsLA== Received: from ywa8 (ywa8.prod.google.com [10.192.1.8]) by kpbe13.cbf.corp.google.com with ESMTP id o7GGBaRP024579 for ; Mon, 16 Aug 2010 09:11:52 -0700 Received: by ywa8 with SMTP id 8so2358432ywa.17 for ; Mon, 16 Aug 2010 09:11:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.87.12 with SMTP id p12mr6026935anl.73.1281975111732; Mon, 16 Aug 2010 09:11:51 -0700 (PDT) Received: by 10.100.6.6 with HTTP; Mon, 16 Aug 2010 09:11:51 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> Date: Mon, 16 Aug 2010 09:11:51 -0700 Message-ID: From: John Panzer To: Aaron Parecki Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 16:11:21 -0000 Is there ever a case other than jsonp where this is necessary? On Monday, August 16, 2010, Aaron Parecki wrote: > Excellent point. Would it be worth it to include a new error_code > parameter in the JSON response so that clients have a way to get the > http status code from the data available in the jsonp response? > > The response in this case might look like this > jsonp_cb({ > =A0=A0 "error_code": 400, > =A0=A0 "error": "invalid_request", > =A0=A0 "error_description": "An active access token must be used to query > information about the current user." > }); > > Aaron > > > On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard wr= ote: > > > +1 > > On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote: > > Hi Fellow OAuthers, > > If a resource wants to return data via the JSONP mechanism then it MUST r= eturn an HTTP 200 error code, or else the browser won't actually call the c= allback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on err= ors which won't ever tell the client that an error happens. > > For example: > > GET /me?callback=3Djsonp_cb HTTP/1.1 > Host:=A0graph.facebook.com=A0 > > HTTP/1.1 200 OK > Content-Type: text/javascript; charset=3DUTF-8 > Content-Length:=A0152 > > jsonp_cb({=A0=A0 "error": "invalid_request",=A0=A0 "error_description": "= An active access token must be used to query information about the current = user." > }); > would never get sent to the browser if we obeyed the spec and sent it as = an HTTP 400. > > --- > So, I recommend we add wording to 5.2.1 like: > > If the protected resource is issuing a response that requires a different= HTTP status code than the one specified (for example, JSONP), then it MAY = use an alternate HTTP code. The server should make it clear which parameter= s trigger this mode so that clients know not to rely on the HTTP status cod= e for error detection. > > > Paul_______________________________________________ > OAuth mailing 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 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From lvh@laurensvh.be Mon Aug 16 12:48:56 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126CB3A6A2B for ; Mon, 16 Aug 2010 12:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.155 X-Spam-Level: X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZxgBUEQ1H5X for ; Mon, 16 Aug 2010 12:48:54 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 9B9183A6A5C for ; Mon, 16 Aug 2010 12:48:54 -0700 (PDT) Received: by qyk1 with SMTP id 1so2504514qyk.10 for ; Mon, 16 Aug 2010 12:49:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.213.131 with SMTP id gw3mr4091036qcb.47.1281988170153; Mon, 16 Aug 2010 12:49:30 -0700 (PDT) Received: by 10.229.21.9 with HTTP; Mon, 16 Aug 2010 12:49:30 -0700 (PDT) In-Reply-To: <24D1D8FA-51B7-4385-9008-0DEF7BB2A786@facebook.com> References: <24D1D8FA-51B7-4385-9008-0DEF7BB2A786@facebook.com> Date: Mon, 16 Aug 2010 21:49:30 +0200 Message-ID: From: Laurens Van Houtven To: Luke Shepard Content-Type: multipart/alternative; boundary=0016361e82707d00bd048df62185 Cc: OAuth WG Subject: Re: [OAUTH-WG] Scope: why is the format predetermined? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 19:48:56 -0000 --0016361e82707d00bd048df62185 Content-Type: text/plain; charset=UTF-8 Whoops, turns out we were just abusing scope (ie not in the SAML sense). Sorry; my bad. Laurens --0016361e82707d00bd048df62185 Content-Type: text/html; charset=UTF-8
Whoops, turns out we were just abusing scope (ie not in the SAML sense). Sorry; my bad.

Laurens
--0016361e82707d00bd048df62185-- From torsten@lodderstedt.net Mon Aug 16 14:08:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4ACF3A6AB8 for ; Mon, 16 Aug 2010 14:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ncp84FgiFITW for ; Mon, 16 Aug 2010 14:08:58 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) by core3.amsl.com (Postfix) with ESMTP id 317113A6AB7 for ; Mon, 16 Aug 2010 14:08:56 -0700 (PDT) Received: from p4ffd392e.dip.t-dialin.net ([79.253.57.46] helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ol6vz-0006AG-FR for oauth@ietf.org; Mon, 16 Aug 2010 23:09:31 +0200 Message-ID: <4C69A909.2060006@lodderstedt.net> Date: Mon, 16 Aug 2010 23:09:29 +0200 From: Torsten Lodderstedt User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] survey: token revocation design options X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 21:09:00 -0000 Hi all, I intend to submit a I-D for token revocation. Based on previous discussions on the mailing list and here at Deutsche Telekom, I see a couple of design options. I would like to share those options with the WG and try to reach consensus on a single option before investing the time to write the I-D. 1) HTTP Delete on tokens endpoint DELETE seems a natural way for revoking (deleting) tokens. Although the HTTP spec is a bit vaque in this concern, current practice prohibits a body for DELETE requests. So the token must be addressed by the request's URI. Lets assume the token is passed as URI query parameter as follows: DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1 Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N But is it advisable to pass tokens as URI query parameters? The current character set definition for access tokens (§5.1.1) is not URL-safe since it includes URI reserved characters (e.g. '/'). Additionally, there is no definition of a refresh tokens character set. So compliant authorization servers could issue tokens, which cannot be safely passed as URI query parameters. Note: As an additional challenge, self-contained tokens can be very large. So passing them as URI parameter may exceed URL length limits. I see the following alternatives to cope with the encoding problem: a) Force usage of a URL-safe character set for access and request tokens. - rather restrictive, will most likely collide with existing token formats - does not solve URL length problem b) Force base64-URL-safe encoding for all tokens on transit. - does not solve URL length problem - significant API change c) Authorization servers supporting revocation may additionally issue a URL-safe token id in the access token response. This id is used to reference the token in DELETE requests. HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "access_token":"SlAV32hkKG/hhh/&%", "access_token_id":"234567890", "expires_in":3600, "refresh_token":"8xLOxBtZp8&&&#&", "refresh_token_id":"asdfghjklhgf" } DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N Note: Since tokens become addressable resources on the authz server, one could also query or modify token data using a GET/PUT requests GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store { "scope":"abc", "issued_on":"08/11/2010", "last_usage":"08/13/2010" } 2) HTTP Post on dedicated revocation endpoint An additional endpoint is used to revoke tokens. The token to be revoked is sent as request body parameter. POST /revocation HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N refresh_token=n4E9O119d This option requires some support for the client to discover the revocation endpoint. Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest additional design options. regards, Torsten. From torsten@lodderstedt.net Mon Aug 16 15:09:20 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CBB83A689E for ; Mon, 16 Aug 2010 15:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWlzYc1S7BRm for ; Mon, 16 Aug 2010 15:09:13 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id BEF473A689D for ; Mon, 16 Aug 2010 15:09:04 -0700 (PDT) Received: from p4ffd392e.dip.t-dialin.net ([79.253.57.46] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ol7s3-0003I8-Hb; Tue, 17 Aug 2010 00:09:31 +0200 Message-ID: <4C69B719.3060303@lodderstedt.net> Date: Tue, 17 Aug 2010 00:09:29 +0200 From: Torsten Lodderstedt User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Panzer References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 22:09:20 -0000 I would like to furthermore track down the relevant use cases. Assuming you are referring to section 5.2.1, how does your client send the access token to the resource server? I'm asking because I think error handling for URI query parameters, Body parameters and Authorization headers could be handled differently. For URI query parameters and Body parameters, returning the error code in the payload instead of the status code would be acceptable from my point of view since authentication is also pushed to the application level. In contrast when using HTTP authentication, 40(x) status codes together with WWW-Authenticate are a must have. Would such a differentiation help you? regards, Torsten. John Panzer schrieb: > Is there ever a case other than jsonp where this is necessary? > > On Monday, August 16, 2010, Aaron Parecki wrote: > >> Excellent point. Would it be worth it to include a new error_code >> parameter in the JSON response so that clients have a way to get the >> http status code from the data available in the jsonp response? >> >> The response in this case might look like this >> jsonp_cb({ >> "error_code": 400, >> "error": "invalid_request", >> "error_description": "An active access token must be used to query >> information about the current user." >> }); >> >> Aaron >> >> >> On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard wrote: >> >> >> +1 >> >> On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote: >> >> Hi Fellow OAuthers, >> >> If a resource wants to return data via the JSONP mechanism then it MUST return an HTTP 200 error code, or else the browser won't actually call the callback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on errors which won't ever tell the client that an error happens. >> >> For example: >> >> GET /me?callback=jsonp_cb HTTP/1.1 >> Host: graph.facebook.com >> >> HTTP/1.1 200 OK >> Content-Type: text/javascript; charset=UTF-8 >> Content-Length: 152 >> >> jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query information about the current user." >> }); >> would never get sent to the browser if we obeyed the spec and sent it as an HTTP 400. >> >> --- >> So, I recommend we add wording to 5.2.1 like: >> >> If the protected resource is issuing a response that requires a different HTTP status code than the one specified (for example, JSONP), then it MAY use an alternate HTTP code. The server should make it clear which parameters trigger this mode so that clients know not to rely on the HTTP status code for error detection. >> >> >> Paul_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > > From igor.faynberg@alcatel-lucent.com Mon Aug 16 15:22:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718AD3A6765 for ; Mon, 16 Aug 2010 15:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD+jH5VLoJyG for ; Mon, 16 Aug 2010 15:22:16 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id CD7023A682D for ; Mon, 16 Aug 2010 15:22:15 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o7GMMp3d005035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 17:22:51 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o7GMMp9c010489; Mon, 16 Aug 2010 17:22:51 -0500 (CDT) Message-ID: <4C69BA3A.8060005@alcatel-lucent.com> Date: Mon, 16 Aug 2010 18:22:50 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <4C69A909.2060006@lodderstedt.net> In-Reply-To: <4C69A909.2060006@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: OAuth WG Subject: Re: [OAUTH-WG] survey: token revocation design options X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 22:22:19 -0000 Torsten, This really captures everything! Option 1a is the best fit for me (and this is really only my personal opinion). (Incidentally, 1c, looks to me like it is not a separate option as it could be implemented along both 1a and 1b. I suspect I missed something; if not, I would change my vote to 1c or 1a+1c.) Looking forward to seening the new I-D, Igor Torsten Lodderstedt wrote: > Hi all, > > I intend to submit a I-D for token revocation. Based on previous > discussions on the mailing list and here at Deutsche Telekom, I see a > couple of design options. I would like to share those options with the > WG and try to reach consensus on a single option before investing the > time to write the I-D. > > 1) HTTP Delete on tokens endpoint > > DELETE seems a natural way for revoking (deleting) tokens. Although > the HTTP spec is a bit vaque in this concern, current practice > prohibits a body for DELETE requests. So the token must be addressed > by the request's URI. Lets assume the token is passed as URI query > parameter as follows: > > DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > But is it advisable to pass tokens as URI query parameters? The > current character set definition for access tokens (§5.1.1) is not > URL-safe since it includes URI reserved characters (e.g. '/'). > Additionally, there is no definition of a refresh tokens character > set. So compliant authorization servers could issue tokens, which > cannot be safely passed as URI query parameters. > > Note: As an additional challenge, self-contained tokens can be very > large. So passing them as URI parameter may exceed URL length limits. > > I see the following alternatives to cope with the encoding problem: > > a) Force usage of a URL-safe character set for access and request tokens. > - rather restrictive, will most likely collide with existing token > formats > - does not solve URL length problem > > b) Force base64-URL-safe encoding for all tokens on transit. > - does not solve URL length problem > - significant API change > > c) Authorization servers supporting revocation may additionally issue > a URL-safe token id in the access token response. This id is used to > reference the token in DELETE requests. > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > { > "access_token":"SlAV32hkKG/hhh/&%", > "access_token_id":"234567890", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8&&&#&", > "refresh_token_id":"asdfghjklhgf" > } > > > DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > Note: Since tokens become addressable resources on the authz server, > one could also query or modify token data using a GET/PUT requests > > GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "scope":"abc", > "issued_on":"08/11/2010", > "last_usage":"08/13/2010" } > > > 2) HTTP Post on dedicated revocation endpoint > > An additional endpoint is used to revoke tokens. The token to be > revoked is sent as request body parameter. > > POST /revocation HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > refresh_token=n4E9O119d > > This option requires some support for the client to discover the > revocation endpoint. > > Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest > additional design options. > > regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lr@lukasrosenstock.net Mon Aug 16 15:51:19 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922653A67EE for ; Mon, 16 Aug 2010 15:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpfUp0wGBgEF for ; Mon, 16 Aug 2010 15:51:17 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id AAF183A6359 for ; Mon, 16 Aug 2010 15:51:17 -0700 (PDT) Received: by qyk9 with SMTP id 9so2901192qyk.10 for ; Mon, 16 Aug 2010 15:51:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.217.83 with SMTP id hl19mr4209102qcb.15.1281999113116; Mon, 16 Aug 2010 15:51:53 -0700 (PDT) Received: by 10.229.241.204 with HTTP; Mon, 16 Aug 2010 15:51:53 -0700 (PDT) In-Reply-To: <4C69A909.2060006@lodderstedt.net> References: <4C69A909.2060006@lodderstedt.net> Date: Tue, 17 Aug 2010 00:51:53 +0200 Message-ID: From: Lukas Rosenstock To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=0016361e82fcbd5d3c048df8ad24 Cc: OAuth WG Subject: Re: [OAUTH-WG] survey: token revocation design options X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 22:51:19 -0000 --0016361e82fcbd5d3c048df8ad24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for your option 1a or 1b - 1c introduces another "token" to manage with the id, which I feel should be avoided. - 2 would also be fine, though not so "beautiful" in terms of architecture. 2010/8/16 Torsten Lodderstedt > But is it advisable to pass tokens as URI query parameters? The current > character set definition for access tokens (=A75.1.1) is not URL-safe sin= ce it > includes URI reserved characters (e.g. '/'). Additionally, there is no > definition of a refresh tokens character set. So compliant authorization > servers could issue tokens, which cannot be safely passed as URI query > parameters. Passing URLs in the query string is already defined in section 5.1.2 of OAuth, though it is optional for servers to support this method. The class of services who want to support 5.1.2 and those who want to support revocation might not match, though ... --=20 http://lukasrosenstock.net/ --0016361e82fcbd5d3c048df8ad24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for your option 1a or 1b

- 1c introduces another &quo= t;token" to manage with the id, which I feel should be avoided.
<= div>- 2 would also be fine, though not so "beautiful" in terms of= architecture.

2010/8/16 Torsten Lodderstedt=A0<torsten@lodderstedt.net>
But is it advisable to pass tokens as URI query parameters? The current cha= racter set definition for access tokens (=A75.1.1) is not URL-safe since it= includes URI reserved characters (e.g. '/'). Additionally, there i= s no definition of a refresh tokens character set. So compliant authorizati= on servers could issue tokens, which cannot be safely passed as URI query p= arameters.

Passing URLs in the query string is already defined in = section 5.1.2 of OAuth, though it is optional for servers to support this m= ethod.
The class of services who want to support 5.1.2 and those = who want to support revocation might not match, though ...

--
http:/= /lukasrosenstock.net/
--0016361e82fcbd5d3c048df8ad24-- From paul.tarjan@facebook.com Mon Aug 16 17:28:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA1F33A67E3 for ; Mon, 16 Aug 2010 17:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.242 X-Spam-Level: X-Spam-Status: No, score=-101.242 tagged_above=-999 required=5 tests=[AWL=0.559, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97sv02Ty4+L9 for ; Mon, 16 Aug 2010 17:28:48 -0700 (PDT) Received: from mx-out.facebook.com (outmail009.snc1.tfbnw.net [69.63.178.168]) by core3.amsl.com (Postfix) with ESMTP id E35B53A67B1 for ; Mon, 16 Aug 2010 17:28:46 -0700 (PDT) Received: from [10.18.255.139] ([10.18.255.139:20063] helo=mail.thefacebook.com) by mta020.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 67/66-18462-0E7D96C4; Mon, 16 Aug 2010 17:29:20 -0700 Received: from SC-MBX03.TheFacebook.com ([169.254.2.61]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Mon, 16 Aug 2010 17:29:19 -0700 From: Paul Tarjan To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Returning HTTP 200 on Error for JSONP Thread-Index: AQHLPQI/cobWXYl540Ky9U9zH0lxpZLksIyAgAAGQICAAGPsgIAAJvsA Date: Tue, 17 Aug 2010 00:29:00 +0000 Message-ID: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> In-Reply-To: <4C69B719.3060303@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <59522336-5400-4d3c-8538-dcdc962a346f> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 00:28:49 -0000 Yes, I'm talking about 5.2.1 For JSONP the user's browser is the client. It will make a request by execu= ting some HTML like this: (this is done instead of an AJAX request, because of cross-domain restricti= ons). As to Aaron's point, Google sends 3 parameters to the callback function, wh= ich I kind of like since the user can choose to get the code or not. Someth= ing like: jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query information about the current user." }. 400, 'Bad Request'); which you can grab with function jsonp_cb(response, code, status) { } or ignore it with function jsonp_cb(response) { } But all of this is outside of the spec. I just want to make sure the spec s= ays that the HTTP status code can send as 200 if the server+client need it = for errors. Paul On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote: > I would like to furthermore track down the relevant use cases. Assuming y= ou are referring to section 5.2.1, how does your client send the access tok= en to the resource server? I'm asking because I think error handling for UR= I query parameters, Body parameters and Authorization headers could be hand= led differently. For URI query parameters and Body parameters, returning th= e error code in the payload instead of the status code would be acceptable = from my point of view since authentication is also pushed to the applicatio= n level. In contrast when using HTTP authentication, 40(x) status codes tog= ether with WWW-Authenticate are a must have. >=20 > Would such a differentiation help you? >=20 > regards, > Torsten. >=20 > John Panzer schrieb: >> Is there ever a case other than jsonp where this is necessary? >>=20 >> On Monday, August 16, 2010, Aaron Parecki wrote: >> =20 >>> Excellent point. Would it be worth it to include a new error_code >>> parameter in the JSON response so that clients have a way to get the >>> http status code from the data available in the jsonp response? >>>=20 >>> The response in this case might look like this >>> jsonp_cb({ >>> "error_code": 400, >>> "error": "invalid_request", >>> "error_description": "An active access token must be used to query >>> information about the current user." >>> }); >>>=20 >>> Aaron >>>=20 >>>=20 >>> On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard = wrote: >>>=20 >>>=20 >>> +1 >>>=20 >>> On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote: >>>=20 >>> Hi Fellow OAuthers, >>>=20 >>> If a resource wants to return data via the JSONP mechanism then it MUST= return an HTTP 200 error code, or else the browser won't actually call the= callback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on e= rrors which won't ever tell the client that an error happens. >>>=20 >>> For example: >>>=20 >>> GET /me?callback=3Djsonp_cb HTTP/1.1 >>> Host: graph.facebook.com >>>=20 >>> HTTP/1.1 200 OK >>> Content-Type: text/javascript; charset=3DUTF-8 >>> Content-Length: 152 >>>=20 >>> jsonp_cb({ "error": "invalid_request", "error_description": "An act= ive access token must be used to query information about the current user." >>> }); >>> would never get sent to the browser if we obeyed the spec and sent it a= s an HTTP 400. >>>=20 >>> --- >>> So, I recommend we add wording to 5.2.1 like: >>>=20 >>> If the protected resource is issuing a response that requires a differe= nt HTTP status code than the one specified (for example, JSONP), then it MA= Y use an alternate HTTP code. The server should make it clear which paramet= ers trigger this mode so that clients know not to rely on the HTTP status c= ode for error detection. >>>=20 >>>=20 >>> Paul_______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>> =20 >>=20 >> =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Mon Aug 16 23:02:07 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61E13A68D6 for ; Mon, 16 Aug 2010 23:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.783 X-Spam-Level: X-Spam-Status: No, score=-1.783 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVbl0zVWsCU0 for ; Mon, 16 Aug 2010 23:02:01 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by core3.amsl.com (Postfix) with ESMTP id 5290E3A68A7 for ; Mon, 16 Aug 2010 23:02:00 -0700 (PDT) Received: from p4ffd1428.dip.t-dialin.net ([79.253.20.40] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1OlFFr-00076W-2r; Tue, 17 Aug 2010 08:02:35 +0200 Message-ID: <4C6A25F7.8060301@lodderstedt.net> Date: Tue, 17 Aug 2010 08:02:31 +0200 From: Torsten Lodderstedt User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Paul Tarjan References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 06:02:07 -0000 Paul Tarjan schrieb: > Yes, I'm talking about 5.2.1 > > For JSONP the user's browser is the client. It will make a request by executing some HTML like this: > > > > > (this is done instead of an AJAX request, because of cross-domain restrictions). > > As to Aaron's point, Google sends 3 parameters to the callback function, which I kind of like since the user can choose to get the code or not. Something like: > > jsonp_cb({ > "error": "invalid_request", > "error_description": "An active access token must be used to query > information about the current user." > }. > 400, > 'Bad Request'); > > which you can grab with > > function jsonp_cb(response, code, status) { > } > > or ignore it with > > function jsonp_cb(response) { > } > > But all of this is outside of the spec. I just want to make sure the spec says that the HTTP status code can send as 200 if the server+client need it for errors. > I think this can be achieved in two ways: (a) either the client tells the server using a parameter or (b) the server always responds with status code 200 in some cases. From my understanding, status code 200 is relevant for requests following the rules of section 5.1.2 only. So my sugesstion would be to go with option (b) and modify the spec to always return status code 200 for such requests. This keeps the spec simpler and preserves the behavior of requests following the rules of section 5.1.1.. regards, Torsten. > Paul > > On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote: > > >> I would like to furthermore track down the relevant use cases. Assuming you are referring to section 5.2.1, how does your client send the access token to the resource server? I'm asking because I think error handling for URI query parameters, Body parameters and Authorization headers could be handled differently. For URI query parameters and Body parameters, returning the error code in the payload instead of the status code would be acceptable from my point of view since authentication is also pushed to the application level. In contrast when using HTTP authentication, 40(x) status codes together with WWW-Authenticate are a must have. >> >> Would such a differentiation help you? >> >> regards, >> Torsten. >> >> John Panzer schrieb: >> >>> Is there ever a case other than jsonp where this is necessary? >>> >>> On Monday, August 16, 2010, Aaron Parecki wrote: >>> >>> >>>> Excellent point. Would it be worth it to include a new error_code >>>> parameter in the JSON response so that clients have a way to get the >>>> http status code from the data available in the jsonp response? >>>> >>>> The response in this case might look like this >>>> jsonp_cb({ >>>> "error_code": 400, >>>> "error": "invalid_request", >>>> "error_description": "An active access token must be used to query >>>> information about the current user." >>>> }); >>>> >>>> Aaron >>>> >>>> >>>> On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard wrote: >>>> >>>> >>>> +1 >>>> >>>> On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote: >>>> >>>> Hi Fellow OAuthers, >>>> >>>> If a resource wants to return data via the JSONP mechanism then it MUST return an HTTP 200 error code, or else the browser won't actually call the callback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on errors which won't ever tell the client that an error happens. >>>> >>>> For example: >>>> >>>> GET /me?callback=jsonp_cb HTTP/1.1 >>>> Host: graph.facebook.com >>>> >>>> HTTP/1.1 200 OK >>>> Content-Type: text/javascript; charset=UTF-8 >>>> Content-Length: 152 >>>> >>>> jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query information about the current user." >>>> }); >>>> would never get sent to the browser if we obeyed the spec and sent it as an HTTP 400. >>>> >>>> --- >>>> So, I recommend we add wording to 5.2.1 like: >>>> >>>> If the protected resource is issuing a response that requires a different HTTP status code than the one specified (for example, JSONP), then it MAY use an alternate HTTP code. The server should make it clear which parameters trigger this mode so that clients know not to rely on the HTTP status code for error detection. >>>> >>>> >>>> Paul_______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > From jpanzer@google.com Tue Aug 17 00:28:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD663A6818 for ; Tue, 17 Aug 2010 00:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=3.825, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF-i2BsjQS-7 for ; Tue, 17 Aug 2010 00:28:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D21053A67F2 for ; Tue, 17 Aug 2010 00:28:21 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id o7H7SuvS023394 for ; Tue, 17 Aug 2010 00:28:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282030136; bh=0qlX67BzrYA+tzDrz5KwgCk5KZI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=b86jzi2HmwgXrzd5CqyPN3VP90le3xMgnAMVk9T1YLSXP8dwgfHdEz/uTr/pZBrzO MK7gWgAgEHbjQAthgbhpw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=xCVPd5ha6zK3mtMvIMeTYDF2UFl+KLL/5qMR10JoGJIaw9kz7ltN+2g+r0hVAHAhF ISNwXuPVop62hnt4Ht94A== Received: from gyd10 (gyd10.prod.google.com [10.243.49.202]) by hpaq6.eem.corp.google.com with ESMTP id o7H7SsDt023489 for ; Tue, 17 Aug 2010 00:28:55 -0700 Received: by gyd10 with SMTP id 10so2616960gyd.18 for ; Tue, 17 Aug 2010 00:28:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.165.18 with SMTP id n18mr7050508ane.252.1282030134176; Tue, 17 Aug 2010 00:28:54 -0700 (PDT) Received: by 10.101.126.6 with HTTP; Tue, 17 Aug 2010 00:28:54 -0700 (PDT) In-Reply-To: <4C6A25F7.8060301@lodderstedt.net> References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> Date: Tue, 17 Aug 2010 00:28:54 -0700 Message-ID: From: John Panzer To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 07:28:25 -0000 Except you cannot guarantee that result of course (proxies, apache plus tomcat separate processes etc. will all result in error codes). Doesn't this all depend on a jsonp extension in the first place - the client has to request a special jsonp response by specifying the callback, thus making the server both use 200s where possible and also wrap its response data in a callback call? That's not part of the spec either, why not just define both pieces of behavior in a jsonp extension spec? (Assuming this can be done without violating the letter of the core spec, which might take some wordsmithing.) On Monday, August 16, 2010, Torsten Lodderstedt w= rote: > Paul Tarjan schrieb: > > Yes, I'm talking about 5.2.1 > > For JSONP the user's browser is the client. It will make a request by exe= cuting some HTML like this: > > > > > (this is done instead of an AJAX request, because of cross-domain restric= tions). > > As to Aaron's point, Google sends 3 parameters to the callback function, = which I kind of like since the user can choose to get the code or not. Some= thing like: > > jsonp_cb({ > =A0"error": "invalid_request", > =A0"error_description": "An active access token must be used to query > information about the current user." > }. > 400, > 'Bad Request'); > > which you can grab with > > function jsonp_cb(response, code, status) { > } > > or ignore it with > > function jsonp_cb(response) { > } > > But all of this is outside of the spec. I just want to make sure the spec= says that the HTTP status code can send as 200 if the server+client need i= t for errors. > > > I think this can be achieved in two ways: (a) either the client tells the= server using a parameter or (b) the server always responds with status cod= e 200 in some cases. From my understanding, status code 200 is relevant for= requests following the rules of section 5.1.2 only. So my sugesstion would= be to go with option (b) and modify the spec to always return status code = 200 for such requests. This keeps the spec simpler and preserves the behavi= or of requests following the rules of section 5.1.1.. > > regards, > Torsten. > > > Paul > > On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote: > > > > I would like to furthermore track down the relevant use cases. Assuming y= ou are referring to section 5.2.1, how does your client send the access tok= en to the resource server? I'm asking because I think error handling for UR= I query parameters, Body parameters and Authorization headers could be hand= led differently. For URI query parameters and Body parameters, returning th= e error code in the payload instead of the status code would be acceptable = from my point of view since authentication is also pushed to the applicatio= n level. In contrast when using HTTP authentication, 40(x) status codes tog= ether with WWW-Authenticate are a must have. > > Would such a differentiation help you? > > regards, > Torsten. > > John Panzer schrieb: > > > Is there ever a case other than jsonp where this is necessary? > > On Monday, August 16, 2010, Aaron Parecki wrote: > > > Excellent point. Would it be worth it to include a new error_code > parameter in the JSON response so that clients have a way to get the > http status code from the data available in the jsonp response? > > The response in this case might look like this > jsonp_cb({ > =A0 "error_code": 400, > =A0"error": "invalid_request", > =A0"error_description": "An active access token must be used to query > information about the current user." > }); > > Aaron > > > On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard wr= ote: > > > +1 > > On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote: > > Hi Fellow OAuthers, > > If a resource wants to return data via the JSONP mechanism then it MUST r= eturn an HTTP 200 error code, or else the browser won't actually call the c= allback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on err= ors which won't ever tell the client that an error happens. > > For example: > > GET /me?callback=3Djsonp_cb HTTP/1.1 > Host: graph.facebook.com > > HTTP/1.1 200 OK > Content-Type: text/javascript; charset=3DUTF-8 > Content-Length: 152 > > jsonp_cb({ =A0 "error": "invalid_request", =A0 "error_description": "An a= ctive access token must be used to query information about the current user= ." > }); > would never get sent to the browser if we obeyed the spec and sent it as = an HTTP 400. > > --- > So, I recommend we add wording to 5.2.1 like: > > If the protected resource is issuing a response that requires a different= HTTP status code than the one specified (for example, JSONP), then it MAY = use an alternate HTTP code. The server should make it clear which parameter= s trigger this mode so that clients know not to rely on the HTTP status cod= e for error detection. > > > Paul_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing 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 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From torsten@lodderstedt.net Tue Aug 17 00:44:18 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F263A68C6 for ; Tue, 17 Aug 2010 00:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.364 X-Spam-Level: X-Spam-Status: No, score=-1.364 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JiZJwu0kktnI for ; Tue, 17 Aug 2010 00:43:59 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 435BD3A68E1 for ; Tue, 17 Aug 2010 00:43:47 -0700 (PDT) Received: from [80.187.98.186] (helo=[10.175.136.186]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1OlGqK-0006j8-Fg; Tue, 17 Aug 2010 09:44:21 +0200 References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8A293) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> X-Mailer: iPhone Mail (8A293) From: Torsten Lodderstedt Date: Tue, 17 Aug 2010 09:43:28 +0200 To: John Panzer X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 07:44:18 -0000 Good point. The server will have to provide special JSONP support anyway. Th= is is the only place where the requested status code handling is needed. +1 for a JSONP extension spec This might also result in much cleaner JSONP support. regards, Torsten. Am 17.08.2010 um 09:28 schrieb John Panzer : > Except you cannot guarantee that result of course (proxies, apache > plus tomcat separate processes etc. will all result in error codes). >=20 > Doesn't this all depend on a jsonp extension in the first place - the > client has to request a special jsonp response by specifying the > callback, thus making the server both use 200s where possible and also > wrap its response data in a callback call? That's not part of the > spec either, why not just define both pieces of behavior in a jsonp > extension spec? (Assuming this can be done without violating the > letter of the core spec, which might take some wordsmithing.) >=20 > On Monday, August 16, 2010, Torsten Lodderstedt w= rote: >> Paul Tarjan schrieb: >>=20 >> Yes, I'm talking about 5.2.1 >>=20 >> For JSONP the user's browser is the client. It will make a request by exe= cuting some HTML like this: >>=20 >> >> >>=20 >> (this is done instead of an AJAX request, because of cross-domain restric= tions). >>=20 >> As to Aaron's point, Google sends 3 parameters to the callback function, w= hich I kind of like since the user can choose to get the code or not. Someth= ing like: >>=20 >> jsonp_cb({ >> "error": "invalid_request", >> "error_description": "An active access token must be used to query >> information about the current user." >> }. >> 400, >> 'Bad Request'); >>=20 >> which you can grab with >>=20 >> function jsonp_cb(response, code, status) { >> } >>=20 >> or ignore it with >>=20 >> function jsonp_cb(response) { >> } >>=20 >> But all of this is outside of the spec. I just want to make sure the spec= says that the HTTP status code can send as 200 if the server+client need it= for errors. >>=20 >>=20 >> I think this can be achieved in two ways: (a) either the client tells the= server using a parameter or (b) the server always responds with status code= 200 in some cases. =46rom my understanding, status code 200 is relevant for= requests following the rules of section 5.1.2 only. So my sugesstion would b= e to go with option (b) and modify the spec to always return status code 200= for such requests. This keeps the spec simpler and preserves the behavior o= f requests following the rules of section 5.1.1.. >>=20 >> regards, >> Torsten. >>=20 >>=20 >> Paul >>=20 >> On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote: >>=20 >>=20 >>=20 >> I would like to furthermore track down the relevant use cases. Assuming y= ou are referring to section 5.2.1, how does your client send the access toke= n to the resource server? I'm asking because I think error handling for URI q= uery parameters, Body parameters and Authorization headers could be handled d= ifferently. For URI query parameters and Body parameters, returning the erro= r code in the payload instead of the status code would be acceptable from my= point of view since authentication is also pushed to the application level.= In contrast when using HTTP authentication, 40(x) status codes together wit= h WWW-Authenticate are a must have. >>=20 >> Would such a differentiation help you? >>=20 >> regards, >> Torsten. >>=20 >> John Panzer schrieb: >>=20 >>=20 >> Is there ever a case other than jsonp where this is necessary? >>=20 >> On Monday, August 16, 2010, Aaron Parecki wrote: >>=20 >>=20 >> Excellent point. Would it be worth it to include a new error_code >> parameter in the JSON response so that clients have a way to get the >> http status code from the data available in the jsonp response? >>=20 >> The response in this case might look like this >> jsonp_cb({ >> "error_code": 400, >> "error": "invalid_request", >> "error_description": "An active access token must be used to query >> information about the current user." >> }); >>=20 >> Aaron >>=20 >>=20 >> On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard wr= ote: >>=20 >>=20 >> +1 >>=20 >> On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote: >>=20 >> Hi Fellow OAuthers, >>=20 >> If a resource wants to return data via the JSONP mechanism then it MUST r= eturn an HTTP 200 error code, or else the browser won't actually call the ca= llback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on error= s which won't ever tell the client that an error happens. >>=20 >> For example: >>=20 >> GET /me?callback=3Djsonp_cb HTTP/1.1 >> Host: graph.facebook.com >>=20 >> HTTP/1.1 200 OK >> Content-Type: text/javascript; charset=3DUTF-8 >> Content-Length: 152 >>=20 >> jsonp_cb({ "error": "invalid_request", "error_description": "An activ= e access token must be used to query information about the current user." >> }); >> would never get sent to the browser if we obeyed the spec and sent it as a= n HTTP 400. >>=20 >> --- >> So, I recommend we add wording to 5.2.1 like: >>=20 >> If the protected resource is issuing a response that requires a different= HTTP status code than the one specified (for example, JSONP), then it MAY u= se an alternate HTTP code. The server should make it clear which parameters t= rigger this mode so that clients know not to rely on the HTTP status code fo= r error detection. >>=20 >>=20 >> Paul_______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer From jricher@mitre.org Tue Aug 17 06:53:13 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4473A687B for ; Tue, 17 Aug 2010 06:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXcRDzH7-Z7P for ; Tue, 17 Aug 2010 06:53:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 2781E3A6855 for ; Tue, 17 Aug 2010 06:53:12 -0700 (PDT) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7HDrlFK009014 for ; Tue, 17 Aug 2010 09:53:47 -0400 Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7HDrkjG009007; Tue, 17 Aug 2010 09:53:46 -0400 Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Tue, 17 Aug 2010 09:53:46 -0400 From: Justin Richer To: Torsten Lodderstedt In-Reply-To: <4C69A909.2060006@lodderstedt.net> References: <4C69A909.2060006@lodderstedt.net> Content-Type: text/plain; charset="UTF-8" Date: Tue, 17 Aug 2010 09:53:46 -0400 Message-ID: <1282053226.12385.43.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: OAuth WG Subject: Re: [OAUTH-WG] survey: token revocation design options X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 13:53:13 -0000 +2 ;) I don't like the use of the DELETE method, it feels too much like overloading the semantics of the HTTP definitions. And as you outline below, there are a few obstacles on it to make it really workable anyway. Another option not laid out below is a parameter on the token endpoint to suggest revocation and/or modification. However, with the new language around grant_types and the like, this makes less sense than it used to. -- Justin On Mon, 2010-08-16 at 17:09 -0400, Torsten Lodderstedt wrote: > Hi all, > > I intend to submit a I-D for token revocation. Based on previous > discussions on the mailing list and here at Deutsche Telekom, I see a > couple of design options. I would like to share those options with the > WG and try to reach consensus on a single option before investing the > time to write the I-D. > > 1) HTTP Delete on tokens endpoint > > DELETE seems a natural way for revoking (deleting) tokens. Although the > HTTP spec is a bit vaque in this concern, current practice prohibits a > body for DELETE requests. So the token must be addressed by the > request's URI. Lets assume the token is passed as URI query parameter as > follows: > > DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > But is it advisable to pass tokens as URI query parameters? The current > character set definition for access tokens (§5.1.1) is not URL-safe > since it includes URI reserved characters (e.g. '/'). Additionally, > there is no definition of a refresh tokens character set. So compliant > authorization servers could issue tokens, which cannot be safely passed > as URI query parameters. > > Note: As an additional challenge, self-contained tokens can be very > large. So passing them as URI parameter may exceed URL length limits. > > I see the following alternatives to cope with the encoding problem: > > a) Force usage of a URL-safe character set for access and request tokens. > - rather restrictive, will most likely collide with existing token formats > - does not solve URL length problem > > b) Force base64-URL-safe encoding for all tokens on transit. > - does not solve URL length problem > - significant API change > > c) Authorization servers supporting revocation may additionally issue a > URL-safe token id in the access token response. This id is used to > reference the token in DELETE requests. > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > { > "access_token":"SlAV32hkKG/hhh/&%", > "access_token_id":"234567890", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8&&&#&", > "refresh_token_id":"asdfghjklhgf" > } > > > DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > Note: Since tokens become addressable resources on the authz server, one > could also query or modify token data using a GET/PUT requests > > GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "scope":"abc", > "issued_on":"08/11/2010", > "last_usage":"08/13/2010" > } > > > 2) HTTP Post on dedicated revocation endpoint > > An additional endpoint is used to revoke tokens. The token to be revoked > is sent as request body parameter. > > POST /revocation HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > refresh_token=n4E9O119d > > This option requires some support for the client to discover the > revocation endpoint. > > Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest > additional design options. > > regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From lshepard@facebook.com Tue Aug 17 08:32:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F6B3A68EA for ; Tue, 17 Aug 2010 08:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.797 X-Spam-Level: X-Spam-Status: No, score=-102.797 tagged_above=-999 required=5 tests=[AWL=1.004, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWs7QCaj-9tL for ; Tue, 17 Aug 2010 08:32:23 -0700 (PDT) Received: from mx-out.facebook.com (outmail005.ash1.tfbnw.net [69.63.184.105]) by core3.amsl.com (Postfix) with ESMTP id 6EB3D3A6862 for ; Tue, 17 Aug 2010 08:32:22 -0700 (PDT) Received: from [10.18.255.128] ([10.18.255.128:48468] helo=mail.thefacebook.com) by mta007.ash1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id B7/B1-01346-249AA6C4; Tue, 17 Aug 2010 08:22:42 -0700 Received: from SC-MBX05.TheFacebook.com ([169.254.4.134]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Tue, 17 Aug 2010 08:22:41 -0700 From: Luke Shepard To: Torsten Lodderstedt Thread-Topic: [OAUTH-WG] Returning HTTP 200 on Error for JSONP Thread-Index: AQHLPQI+gG+TVKVrt0q8LNtlx+EW4pLksIyAgAAGQICAAGPsgIAAJvsAgABdL4CAABgjAIAABBIAgACATAA= Date: Tue, 17 Aug 2010 15:22:40 +0000 Message-ID: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> In-Reply-To: <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <970b2b8b-2c8b-42b0-96fd-ce5e5ef45602> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:32:26 -0000 >From the perspective of OAuth, a JSONP endpoint is just another protected r= esource. I'd rather not need us to write an extension for every type of pro= tected resource we might need to access. I think the wordsmithing you discussed is what Paul's proposing - just sayi= ng essentially "look, these are the HTTP error codes you can expect, but it= 's okay for the server sometimes to give 200 on an error response anyway". = That would be necessary even if we wrote an extension. On Aug 17, 2010, at 12:43 AM, Torsten Lodderstedt wrote: > Good point. The server will have to provide special JSONP support anyway.= This is the only place where the requested status code handling is needed. >=20 > +1 for a JSONP extension spec >=20 > This might also result in much cleaner JSONP support. >=20 > regards, > Torsten. >=20 > Am 17.08.2010 um 09:28 schrieb John Panzer : >=20 >> Except you cannot guarantee that result of course (proxies, apache >> plus tomcat separate processes etc. will all result in error codes). >>=20 >> Doesn't this all depend on a jsonp extension in the first place - the >> client has to request a special jsonp response by specifying the >> callback, thus making the server both use 200s where possible and also >> wrap its response data in a callback call? That's not part of the >> spec either, why not just define both pieces of behavior in a jsonp >> extension spec? (Assuming this can be done without violating the >> letter of the core spec, which might take some wordsmithing.) >>=20 >> On Monday, August 16, 2010, Torsten Lodderstedt wrote: >>> Paul Tarjan schrieb: >>>=20 >>> Yes, I'm talking about 5.2.1 >>>=20 >>> For JSONP the user's browser is the client. It will make a request by e= xecuting some HTML like this: >>>=20 >>> >>> >>>=20 >>> (this is done instead of an AJAX request, because of cross-domain restr= ictions). >>>=20 >>> As to Aaron's point, Google sends 3 parameters to the callback function= , which I kind of like since the user can choose to get the code or not. So= mething like: >>>=20 >>> jsonp_cb({ >>> "error": "invalid_request", >>> "error_description": "An active access token must be used to query >>> information about the current user." >>> }. >>> 400, >>> 'Bad Request'); >>>=20 >>> which you can grab with >>>=20 >>> function jsonp_cb(response, code, status) { >>> } >>>=20 >>> or ignore it with >>>=20 >>> function jsonp_cb(response) { >>> } >>>=20 >>> But all of this is outside of the spec. I just want to make sure the sp= ec says that the HTTP status code can send as 200 if the server+client need= it for errors. >>>=20 >>>=20 >>> I think this can be achieved in two ways: (a) either the client tells t= he server using a parameter or (b) the server always responds with status c= ode 200 in some cases. From my understanding, status code 200 is relevant f= or requests following the rules of section 5.1.2 only. So my sugesstion wou= ld be to go with option (b) and modify the spec to always return status cod= e 200 for such requests. This keeps the spec simpler and preserves the beha= vior of requests following the rules of section 5.1.1.. >>>=20 >>> regards, >>> Torsten. >>>=20 >>>=20 >>> Paul >>>=20 >>> On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote: >>>=20 >>>=20 >>>=20 >>> I would like to furthermore track down the relevant use cases. Assuming= you are referring to section 5.2.1, how does your client send the access t= oken to the resource server? I'm asking because I think error handling for = URI query parameters, Body parameters and Authorization headers could be ha= ndled differently. For URI query parameters and Body parameters, returning = the error code in the payload instead of the status code would be acceptabl= e from my point of view since authentication is also pushed to the applicat= ion level. In contrast when using HTTP authentication, 40(x) status codes t= ogether with WWW-Authenticate are a must have. >>>=20 >>> Would such a differentiation help you? >>>=20 >>> regards, >>> Torsten. >>>=20 >>> John Panzer schrieb: >>>=20 >>>=20 >>> Is there ever a case other than jsonp where this is necessary? >>>=20 >>> On Monday, August 16, 2010, Aaron Parecki wrote: >>>=20 >>>=20 >>> Excellent point. Would it be worth it to include a new error_code >>> parameter in the JSON response so that clients have a way to get the >>> http status code from the data available in the jsonp response? >>>=20 >>> The response in this case might look like this >>> jsonp_cb({ >>> "error_code": 400, >>> "error": "invalid_request", >>> "error_description": "An active access token must be used to query >>> information about the current user." >>> }); >>>=20 >>> Aaron >>>=20 >>>=20 >>> On Sun, Aug 15, 2010 at 10:16 PM, Luke Shepard = wrote: >>>=20 >>>=20 >>> +1 >>>=20 >>> On Aug 13, 2010, at 2:31 PM, Paul Tarjan wrote: >>>=20 >>> Hi Fellow OAuthers, >>>=20 >>> If a resource wants to return data via the JSONP mechanism then it MUST= return an HTTP 200 error code, or else the browser won't actually call the= callback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on e= rrors which won't ever tell the client that an error happens. >>>=20 >>> For example: >>>=20 >>> GET /me?callback=3Djsonp_cb HTTP/1.1 >>> Host: graph.facebook.com >>>=20 >>> HTTP/1.1 200 OK >>> Content-Type: text/javascript; charset=3DUTF-8 >>> Content-Length: 152 >>>=20 >>> jsonp_cb({ "error": "invalid_request", "error_description": "An act= ive access token must be used to query information about the current user." >>> }); >>> would never get sent to the browser if we obeyed the spec and sent it a= s an HTTP 400. >>>=20 >>> --- >>> So, I recommend we add wording to 5.2.1 like: >>>=20 >>> If the protected resource is issuing a response that requires a differe= nt HTTP status code than the one specified (for example, JSONP), then it MA= Y use an alternate HTTP code. The server should make it clear which paramet= ers trigger this mode so that clients know not to rely on the HTTP status c= ode for error detection. >>>=20 >>>=20 >>> Paul_______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> --=20 >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jpanzer@google.com Tue Aug 17 09:05:49 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A0E3A6AC8 for ; Tue, 17 Aug 2010 09:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.508 X-Spam-Level: X-Spam-Status: No, score=-104.508 tagged_above=-999 required=5 tests=[AWL=2.869, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4phXjH4pOct for ; Tue, 17 Aug 2010 09:05:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 4CD943A6AE9 for ; Tue, 17 Aug 2010 09:05:33 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id o7HG67cf009033 for ; Tue, 17 Aug 2010 09:06:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282061167; bh=h14ttIOzPTPL92J2ScEvgg3pPgg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=jyrHj5enIWglShyfF8JWB7BNowJg9qXHUnLrk2P28Sm14ABfjQq9PULjln6xp3pKX FRolOqUZrxWaHQzfDSl6A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=PdOYabXzB66nmUHJ3FmQul+mzHo4yKs2lOUWRTn7GfZ4ggrJp2BghdWiU+I2Q3N4D Oc+ODxzr8+kJiABGvKjfA== Received: from gwaa18 (gwaa18.prod.google.com [10.200.27.18]) by hpaq12.eem.corp.google.com with ESMTP id o7HG5eJf016750 for ; Tue, 17 Aug 2010 09:06:06 -0700 Received: by gwaa18 with SMTP id a18so3168524gwa.17 for ; Tue, 17 Aug 2010 09:06:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.170.5 with SMTP id x5mr7848689ano.29.1282061165724; Tue, 17 Aug 2010 09:06:05 -0700 (PDT) Received: by 10.101.126.6 with HTTP; Tue, 17 Aug 2010 09:06:05 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> Date: Tue, 17 Aug 2010 09:06:05 -0700 Message-ID: From: John Panzer To: Luke Shepard Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 16:05:49 -0000 Well, no, jsonp is a special transport layer inside http. Making that fuzzy will cause (interop and security) problems. On Tuesday, August 17, 2010, Luke Shepard wrote: > From the perspective of OAuth, a JSONP endpoint is just another protected= resource. I'd rather not need us to write an extension for every type of p= rotected resource we might need to access. > > I think the wordsmithing you discussed is what Paul's proposing - just sa= ying essentially "look, these are the HTTP error codes you can expect, but = it's okay for the server sometimes to give 200 on an error response anyway"= . That would be necessary even if we wrote an extension. > > On Aug 17, 2010, at 12:43 AM, Torsten Lodderstedt wrote: > >> Good point. The server will have to provide special JSONP support anyway= . This is the only place where the requested status code handling is needed= . >> >> +1 for a JSONP extension spec >> >> This might also result in much cleaner JSONP support. >> >> regards, >> Torsten. >> >> Am 17.08.2010 um 09:28 schrieb John Panzer : >> >>> Except you cannot guarantee that result of course (proxies, apache >>> plus tomcat separate processes etc. will all result in error codes). >>> >>> Doesn't this all depend on a jsonp extension in the first place - the >>> client has to request a special jsonp response by specifying the >>> callback, thus making the server both use 200s where possible and also >>> wrap its response data in a callback call? =A0That's not part of the >>> spec either, why not just define both pieces of behavior in a jsonp >>> extension spec? =A0(Assuming this can be done without violating the >>> letter of the core spec, which might take some wordsmithing.) >>> >>> On Monday, August 16, 2010, Torsten Lodderstedt wrote: >>>> Paul Tarjan schrieb: >>>> >>>> Yes, I'm talking about 5.2.1 >>>> >>>> For JSONP the user's browser is the client. It will make a request by = executing some HTML like this: >>>> >>>> >>>> >>>> >>>> (this is done instead of an AJAX request, because of cross-domain rest= rictions). >>>> >>>> As to Aaron's point, Google sends 3 parameters to the callback functio= n, which I kind of like since the user can choose to get the code or not. S= omething like: >>>> >>>> jsonp_cb({ >>>> "error": "invalid_request", >>>> "error_description": "An active access token must be used to query >>>> information about the current user." >>>> }. >>>> 400, >>>> 'Bad Request'); >>>> >>>> which you can grab with >>>> >>>> function jsonp_cb(response, code, status) { >>>> } >>>> >>>> or ignore it with >>>> >>>> function jsonp_cb(response) { >>>> } >>>> >>>> But all of this is outside of the spec. I just want to make sure the s= pec says that the HTTP status code can send as 200 if the server+client nee= d it for errors. >>>> >>>> >>>> I think this can be achieved in two ways: (a) either the client tells = the server using a parameter or (b) the server always responds with status = code 200 in some cases. From my understanding, status code 200 is relevant = for requests following the rules of section 5.1.2 only. So my sugesstion wo= uld be to go with option (b) and modify the spec to always return status co= de 200 for such requests. This keeps the spec simpler and preserves the beh= avior of requests following the rules of section 5.1.1.. >>>> >>>> regards, >>>> Torsten. >>>> >>>> >>>> Paul >>>> >>>> On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote: >>>> >>>> >>>> >>>> I would like to furthermore track down the relevant use cases. Assumin= g you are referring to section 5.2.1, how does your client send the access = token to the resource server? I'm asking because I think error handling for= URI query parameters, Body parameters and Authorization headers could be h= andled differently. For URI query parameters and Body parameters, returning= the error code in the payload instead of the status code would be acceptab= le from my point of view since authentication is also pushed to the applica= tion level. In contrast when using HTTP authentication, 40(x) status codes = together with WWW-Authenticate are a must have. >>>> >>>> Would such a --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From recordond@gmail.com Tue Aug 17 11:48:06 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85C043A67EB for ; Tue, 17 Aug 2010 11:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.124 X-Spam-Level: X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=0.874, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KLnXBrjOPeq for ; Tue, 17 Aug 2010 11:48:05 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7D5C23A659C for ; Tue, 17 Aug 2010 11:48:04 -0700 (PDT) Received: by bwz9 with SMTP id 9so3173813bwz.31 for ; Tue, 17 Aug 2010 11:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3TEi6I4nFIERSb6tPjhHhodoZ+0551s8gAZvWav3UAM=; b=idxBgBJiiZIiDWDKxc9gxy28qxfEXHTnFsM6aih7nPDHbuNR4HkwPCtvgTOVKmfnWO R21BDoRlsLOCsFFQqOg2jEA2+ThYtYiutbe4Gk0eafwgmEzkdZ8WNUL+y9uOlFokLsCU 5zUuhqhF++zvKhxviwo7fckvXLzl36r536GZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=M6FwAb31aHweYzcyip98nlBaCLEWauSaGsp2Hs91wIIC/iwzIY+orf6CRQ4KBT/qQb IPSoDMknpFp64Ymzc10Vuu/G8uroZixR2ZQOvN/xjOv3qZ+vkhJtCZJd7byo3CLrk/hc KrHAmHXFRUz/uUBdpA6yW0K9Oq9LjM+ejgiWk= MIME-Version: 1.0 Received: by 10.204.131.200 with SMTP id y8mr4732515bks.107.1282070919263; Tue, 17 Aug 2010 11:48:39 -0700 (PDT) Received: by 10.204.132.155 with HTTP; Tue, 17 Aug 2010 11:48:39 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> Date: Tue, 17 Aug 2010 11:48:39 -0700 Message-ID: From: David Recordon To: John Panzer Content-Type: multipart/alternative; boundary=0015174479dab8365d048e096525 Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:48:06 -0000 --0015174479dab8365d048e096525 Content-Type: text/plain; charset=ISO-8859-1 Luke's point still holds true of the core spec needing to allow a 200 status code on an error in this scenario. I'd also rather see this as part of the core spec as it reduces the number of things that implementors will need to read for common use cases. --David On Tue, Aug 17, 2010 at 9:06 AM, John Panzer wrote: > Well, no, jsonp is a special transport layer inside http. Making that > fuzzy will cause (interop and security) problems. > > On Tuesday, August 17, 2010, Luke Shepard wrote: > > From the perspective of OAuth, a JSONP endpoint is just another protected > resource. I'd rather not need us to write an extension for every type of > protected resource we might need to access. > > > > I think the wordsmithing you discussed is what Paul's proposing - just > saying essentially "look, these are the HTTP error codes you can expect, but > it's okay for the server sometimes to give 200 on an error response anyway". > That would be necessary even if we wrote an extension. > > > > On Aug 17, 2010, at 12:43 AM, Torsten Lodderstedt wrote: > > > >> Good point. The server will have to provide special JSONP support > anyway. This is the only place where the requested status code handling is > needed. > >> > >> +1 for a JSONP extension spec > >> > >> This might also result in much cleaner JSONP support. > >> > >> regards, > >> Torsten. > >> > >> Am 17.08.2010 um 09:28 schrieb John Panzer : > >> > >>> Except you cannot guarantee that result of course (proxies, apache > >>> plus tomcat separate processes etc. will all result in error codes). > >>> > >>> Doesn't this all depend on a jsonp extension in the first place - the > >>> client has to request a special jsonp response by specifying the > >>> callback, thus making the server both use 200s where possible and also > >>> wrap its response data in a callback call? That's not part of the > >>> spec either, why not just define both pieces of behavior in a jsonp > >>> extension spec? (Assuming this can be done without violating the > >>> letter of the core spec, which might take some wordsmithing.) > >>> > >>> On Monday, August 16, 2010, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >>>> Paul Tarjan schrieb: > >>>> > >>>> Yes, I'm talking about 5.2.1 > >>>> > >>>> For JSONP the user's browser is the client. It will make a request by > executing some HTML like this: > >>>> > >>>> > >>>> > >>>> > >>>> (this is done instead of an AJAX request, because of cross-domain > restrictions). > >>>> > >>>> As to Aaron's point, Google sends 3 parameters to the callback > function, which I kind of like since the user can choose to get the code or > not. Something like: > >>>> > >>>> jsonp_cb({ > >>>> "error": "invalid_request", > >>>> "error_description": "An active access token must be used to query > >>>> information about the current user." > >>>> }. > >>>> 400, > >>>> 'Bad Request'); > >>>> > >>>> which you can grab with > >>>> > >>>> function jsonp_cb(response, code, status) { > >>>> } > >>>> > >>>> or ignore it with > >>>> > >>>> function jsonp_cb(response) { > >>>> } > >>>> > >>>> But all of this is outside of the spec. I just want to make sure the > spec says that the HTTP status code can send as 200 if the server+client > need it for errors. > >>>> > >>>> > >>>> I think this can be achieved in two ways: (a) either the client tells > the server using a parameter or (b) the server always responds with status > code 200 in some cases. From my understanding, status code 200 is relevant > for requests following the rules of section 5.1.2 only. So my sugesstion > would be to go with option (b) and modify the spec to always return status > code 200 for such requests. This keeps the spec simpler and preserves the > behavior of requests following the rules of section 5.1.1.. > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> > >>>> Paul > >>>> > >>>> On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote: > >>>> > >>>> > >>>> > >>>> I would like to furthermore track down the relevant use cases. > Assuming you are referring to section 5.2.1, how does your client send the > access token to the resource server? I'm asking because I think error > handling for URI query parameters, Body parameters and Authorization headers > could be handled differently. For URI query parameters and Body parameters, > returning the error code in the payload instead of the status code would be > acceptable from my point of view since authentication is also pushed to the > application level. In contrast when using HTTP authentication, 40(x) status > codes together with WWW-Authenticate are a must have. > >>>> > >>>> Would such a > > -- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --0015174479dab8365d048e096525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Luke's point still holds true of the core spec needing to allow a 200 s= tatus code on an error in this scenario. I'd also rather see this as pa= rt of the core spec as it reduces the number of things that implementors wi= ll need to read for common use cases.

--David


On Tue,= Aug 17, 2010 at 9:06 AM, John Panzer <jpanzer@google.com> wrote:
Well, no, jsonp is a special transport layer inside http. =A0Making that fuzzy will cause (interop and security) problems.

On Tuesday, August 17, 2010, Luke Shepard <lshepard@facebook.com> wrote:
> From the perspective of OAuth, a JSONP endpoint is just another protec= ted resource. I'd rather not need us to write an extension for every ty= pe of protected resource we might need to access.
>
> I think the wordsmithing you discussed is what Paul's proposing - = just saying essentially "look, these are the HTTP error codes you can = expect, but it's okay for the server sometimes to give 200 on an error = response anyway". That would be necessary even if we wrote an extensio= n.
>
> On Aug 17, 2010, at 12:43 AM, Torsten Lodderstedt wrote:
>
>> Good point. The server will have to provide special JSONP support = anyway. This is the only place where the requested status code handling is = needed.
>>
>> +1 for a JSONP extension spec
>>
>> This might also result in much cleaner JSONP support.
>>
>> regards,
>> Torsten.
>>
>> Am 17.08.2010 um 09:28 schrieb John Panzer <jpanzer@google.com>:
>>
>>> Except you cannot guarantee that result of course (proxies, ap= ache
>>> plus tomcat separate processes etc. will all result in error c= odes).
>>>
>>> Doesn't this all depend on a jsonp extension in the first = place - the
>>> client has to request a special jsonp response by specifying t= he
>>> callback, thus making the server both use 200s where possible = and also
>>> wrap its response data in a callback call? =A0That's not p= art of the
>>> spec either, why not just define both pieces of behavior in a = jsonp
>>> extension spec? =A0(Assuming this can be done without violatin= g the
>>> letter of the core spec, which might take some wordsmithing.)<= br> >>>
>>> On Monday, August 16, 2010, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>> Paul Tarjan schrieb:
>>>>
>>>> Yes, I'm talking about 5.2.1
>>>>
>>>> For JSONP the user's browser is the client. It will ma= ke a request by executing some HTML like this:
>>>>
>>>> <script src=3D"http://g= raph.facebook.com/me?access_token=3D...&callback=3Djsonp_cb"&g= t;</script>
>>>> <script>
>>>> function jsonp_cb(response) {
>>>> if (response.error) {
>>>> =A0 // error out
>>>> =A0return;
>>>> }
>>>> // do cool things
>>>> }
>>>> </script>
>>>>
>>>> (this is done instead of an AJAX request, because of cross= -domain restrictions).
>>>>
>>>> As to Aaron's point, Google sends 3 parameters to the = callback function, which I kind of like since the user can choose to get th= e code or not. Something like:
>>>>
>>>> jsonp_cb({
>>>> "error": "invalid_request",
>>>> "error_description": "An active access toke= n must be used to query
>>>> information about the current user."
>>>> }.
>>>> 400,
>>>> 'Bad Request');
>>>>
>>>> which you can grab with
>>>>
>>>> function jsonp_cb(response, code, status) {
>>>> }
>>>>
>>>> or ignore it with
>>>>
>>>> function jsonp_cb(response) {
>>>> }
>>>>
>>>> But all of this is outside of the spec. I just want to mak= e sure the spec says that the HTTP status code can send as 200 if the serve= r+client need it for errors.
>>>>
>>>>
>>>> I think this can be achieved in two ways: (a) either the c= lient tells the server using a parameter or (b) the server always responds = with status code 200 in some cases. From my understanding, status code 200 = is relevant for requests following the rules of section 5.1.2 only. So my s= ugesstion would be to go with option (b) and modify the spec to always retu= rn status code 200 for such requests. This keeps the spec simpler and prese= rves the behavior of requests following the rules of section 5.1.1..
>>>>
>>>> regards,
>>>> Torsten.
>>>>
>>>>
>>>> Paul
>>>>
>>>> On Aug 16, 2010, at 3:09 PM, Torsten Lodderstedt wrote: >>>>
>>>>
>>>>
>>>> I would like to furthermore track down the relevant use ca= ses. Assuming you are referring to section 5.2.1, how does your client send= the access token to the resource server? I'm asking because I think er= ror handling for URI query parameters, Body parameters and Authorization he= aders could be handled differently. For URI query parameters and Body param= eters, returning the error code in the payload instead of the status code w= ould be acceptable from my point of view since authentication is also pushe= d to the application level. In contrast when using HTTP authentication, 40(= x) status codes together with WWW-Authenticate are a must have.
>>>>
>>>> Would such a

--
--
John Panzer / Google
jpanzer@google.com / abstractioneer.org / @jpanz= er
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

--0015174479dab8365d048e096525-- From torsten@lodderstedt.net Tue Aug 17 11:57:47 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A403A6859 for ; Tue, 17 Aug 2010 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPg44qCRHoIN for ; Tue, 17 Aug 2010 11:57:46 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) by core3.amsl.com (Postfix) with ESMTP id E25463A67EB for ; Tue, 17 Aug 2010 11:57:45 -0700 (PDT) Received: from [79.253.20.40] (helo=[192.168.71.22]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OlRMZ-0007Ha-AG; Tue, 17 Aug 2010 20:58:19 +0200 Message-ID: <4C6ADBD4.9010500@lodderstedt.net> Date: Tue, 17 Aug 2010 20:58:28 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: igor.faynberg@alcatel-lucent.com References: <4C69A909.2060006@lodderstedt.net> <4C69BA3A.8060005@alcatel-lucent.com> In-Reply-To: <4C69BA3A.8060005@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] survey: token revocation design options X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:57:47 -0000 Igor, 1c does not further narrow down the character set for tokens. It instead establishes an additional (URL-safe) id. That way no change is needed on existing token formats and the existing protocol definition. This could be combined with 1a or 1b but why? To cope with URL length restrictions? regards, Torsten. Am 17.08.2010 00:22, schrieb Igor Faynberg: > Torsten, > > This really captures everything! > > Option 1a is the best fit for me (and this is really only my personal > opinion). (Incidentally, 1c, looks to me like it is not a separate > option as it could be implemented along both 1a and 1b. I suspect I > missed something; if not, I would change my vote to 1c or 1a+1c.) > > Looking forward to seening the new I-D, > > Igor > > Torsten Lodderstedt wrote: >> Hi all, >> >> I intend to submit a I-D for token revocation. Based on previous >> discussions on the mailing list and here at Deutsche Telekom, I see a >> couple of design options. I would like to share those options with >> the WG and try to reach consensus on a single option before investing >> the time to write the I-D. >> >> 1) HTTP Delete on tokens endpoint >> >> DELETE seems a natural way for revoking (deleting) tokens. Although >> the HTTP spec is a bit vaque in this concern, current practice >> prohibits a body for DELETE requests. So the token must be addressed >> by the request's URI. Lets assume the token is passed as URI query >> parameter as follows: >> >> DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1 >> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >> >> But is it advisable to pass tokens as URI query parameters? The >> current character set definition for access tokens (§5.1.1) is not >> URL-safe since it includes URI reserved characters (e.g. '/'). >> Additionally, there is no definition of a refresh tokens character >> set. So compliant authorization servers could issue tokens, which >> cannot be safely passed as URI query parameters. >> >> Note: As an additional challenge, self-contained tokens can be very >> large. So passing them as URI parameter may exceed URL length limits. >> >> I see the following alternatives to cope with the encoding problem: >> >> a) Force usage of a URL-safe character set for access and request >> tokens. >> - rather restrictive, will most likely collide with existing token >> formats >> - does not solve URL length problem >> >> b) Force base64-URL-safe encoding for all tokens on transit. >> - does not solve URL length problem >> - significant API change >> >> c) Authorization servers supporting revocation may additionally issue >> a URL-safe token id in the access token response. This id is used to >> reference the token in DELETE requests. >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> Cache-Control: no-store >> { >> "access_token":"SlAV32hkKG/hhh/&%", >> "access_token_id":"234567890", >> "expires_in":3600, >> "refresh_token":"8xLOxBtZp8&&&#&", >> "refresh_token_id":"asdfghjklhgf" >> } >> >> >> DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 >> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >> >> Note: Since tokens become addressable resources on the authz server, >> one could also query or modify token data using a GET/PUT requests >> >> GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 >> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >> >> HTTP/1.1 200 OK >> Content-Type: application/json >> Cache-Control: no-store >> >> { >> "scope":"abc", >> "issued_on":"08/11/2010", >> "last_usage":"08/13/2010" } >> >> >> 2) HTTP Post on dedicated revocation endpoint >> >> An additional endpoint is used to revoke tokens. The token to be >> revoked is sent as request body parameter. >> >> POST /revocation HTTP/1.1 >> Host: server.example.com >> Content-Type: application/x-www-form-urlencoded >> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >> >> refresh_token=n4E9O119d >> >> This option requires some support for the client to discover the >> revocation endpoint. >> >> Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest >> additional design options. >> >> regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Tue Aug 17 12:03:46 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04653A6804 for ; Tue, 17 Aug 2010 12:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoYR94OaNoIs for ; Tue, 17 Aug 2010 12:03:45 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by core3.amsl.com (Postfix) with ESMTP id 842813A6807 for ; Tue, 17 Aug 2010 12:03:45 -0700 (PDT) Received: from [79.253.20.40] (helo=[192.168.71.22]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OlRSN-0006j3-Fz; Tue, 17 Aug 2010 21:04:19 +0200 Message-ID: <4C6ADD3C.1010402@lodderstedt.net> Date: Tue, 17 Aug 2010 21:04:28 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Lukas Rosenstock References: <4C69A909.2060006@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070205050609030700090201" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] survey: token revocation design options X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 19:03:47 -0000 This is a multi-part message in MIME format. --------------070205050609030700090201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Lukas, thanks for your feedback. I think 1c not neccessarily introduces something new to manage. I would rather expect implementations use either a ID already contained in the token (like the SAML assertion ID) or a base64-encoded version of the token itself. regards, Torsten. Am 17.08.2010 00:51, schrieb Lukas Rosenstock: > +1 for your option 1a or 1b > > - 1c introduces another "token" to manage with the id, which I feel > should be avoided. > - 2 would also be fine, though not so "beautiful" in terms of > architecture. > > 2010/8/16 Torsten Lodderstedt > > > But is it advisable to pass tokens as URI query parameters? The > current character set definition for access tokens (§5.1.1) is not > URL-safe since it includes URI reserved characters (e.g. '/'). > Additionally, there is no definition of a refresh tokens character > set. So compliant authorization servers could issue tokens, which > cannot be safely passed as URI query parameters. > > > Passing URLs in the query string is already defined in section 5.1.2 > of OAuth, though it is optional for servers to support this method. > The class of services who want to support 5.1.2 and those who want to > support revocation might not match, though ... > > -- > http://lukasrosenstock.net/ --------------070205050609030700090201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lukas,

thanks for your feedback.

I think 1c not neccessarily introduces something new to manage. I would rather expect implementations use either a ID already contained in the token (like the SAML assertion ID) or a base64-encoded version of the token itself.

regards,
Torsten.

Am 17.08.2010 00:51, schrieb Lukas Rosenstock:
+1 for your option 1a or 1b

- 1c introduces another "token" to manage with the id, which I feel should be avoided.
- 2 would also be fine, though not so "beautiful" in terms of architecture.

2010/8/16 Torsten Lodderstedt <torsten@lodderstedt.net>
But is it advisable to pass tokens as URI query parameters? The current character set definition for access tokens (§5.1.1) is not URL-safe since it includes URI reserved characters (e.g. '/'). Additionally, there is no definition of a refresh tokens character set. So compliant authorization servers could issue tokens, which cannot be safely passed as URI query parameters.

Passing URLs in the query string is already defined in section 5.1.2 of OAuth, though it is optional for servers to support this method.
The class of services who want to support 5.1.2 and those who want to support revocation might not match, though ...

--
http://lukasrosenstock.net/

--------------070205050609030700090201-- From lvh@laurensvh.be Tue Aug 17 12:52:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4891C3A67FC for ; Tue, 17 Aug 2010 12:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npU5ZCxwku9t for ; Tue, 17 Aug 2010 12:52:36 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9F8363A6802 for ; Tue, 17 Aug 2010 12:52:36 -0700 (PDT) Received: by qwc9 with SMTP id 9so7030220qwc.31 for ; Tue, 17 Aug 2010 12:53:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.51.221 with SMTP id e29mr33915qcg.229.1282074791810; Tue, 17 Aug 2010 12:53:11 -0700 (PDT) Received: by 10.229.21.9 with HTTP; Tue, 17 Aug 2010 12:53:11 -0700 (PDT) Date: Tue, 17 Aug 2010 21:53:11 +0200 Message-ID: From: Laurens Van Houtven To: OAuth WG Content-Type: multipart/alternative; boundary=0016367d5c8e8aa6f2048e0a4c57 Subject: [OAUTH-WG] Repeating of client identifier? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 19:52:38 -0000 --0016367d5c8e8aa6f2048e0a4c57 Content-Type: text/plain; charset=UTF-8 Hi, In the most recent draft version of the spec, section 2.1. Client Password Credentials, the following example request is given: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&client_id=s6BhdRkqt3&code=i1WsRn1uB1& redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb Why is the client_id both in the body and in the Authorization header? thanks lvh --0016367d5c8e8aa6f2048e0a4c57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,


In the most recent draft version of t= he spec, section=C2=A02.1.=C2=A0Client Password Credentials, the following = example request is given:


POST= /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-= Type: application/x-www-form-urlencoded
grant_type=3Dauthorizatio= n_code&client_id=3Ds6BhdRkqt3&code=3Di1WsRn1uB1&
redirect_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb


Why is the client_id both in the body and = in the Authorization header?


thanks=
lvh
--0016367d5c8e8aa6f2048e0a4c57-- From igor.faynberg@alcatel-lucent.com Tue Aug 17 13:29:04 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 826CE3A67D9 for ; Tue, 17 Aug 2010 13:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUG9bQGxs7se for ; Tue, 17 Aug 2010 13:29:03 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 621843A68C4 for ; Tue, 17 Aug 2010 13:29:03 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o7HKTbH9011902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Aug 2010 15:29:38 -0500 (CDT) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o7HKTbk3016744; Tue, 17 Aug 2010 15:29:37 -0500 (CDT) Message-ID: <4C6AF130.5090400@alcatel-lucent.com> Date: Tue, 17 Aug 2010 16:29:36 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <4C69A909.2060006@lodderstedt.net> <4C69BA3A.8060005@alcatel-lucent.com> <4C6ADBD4.9010500@lodderstedt.net> In-Reply-To: <4C6ADBD4.9010500@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: OAuth WG Subject: Re: [OAUTH-WG] survey: token revocation design options X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:29:04 -0000 Yes, as I thought we HAD to cope with it. Anyway, both 1a and 1c look attractive to me. (BTW, I saw a comment on overloading of DELETE, with which I sympathize in principle, but it looks to me that all methods have been already overloaded, while DELETE semantically resonates with the very nature of the task at hand.) Igor Torsten Lodderstedt wrote: > ... [1c] could be combined with 1a or 1b but why? To cope with URL > length restrictions? > > ... > > Am 17.08.2010 00:22, schrieb Igor Faynberg: >> Torsten, >> >> This really captures everything! >> >> Option 1a is the best fit for me (and this is really only my >> personal opinion). (Incidentally, 1c, looks to me like it is not a >> separate option as it could be implemented along both 1a and 1b. I >> suspect I missed something; if not, I would change my vote to 1c or >> 1a+1c.) >> >> Looking forward to seening the new I-D, >> >> Igor >> >> Torsten Lodderstedt wrote: >>> Hi all, >>> >>> I intend to submit a I-D for token revocation. Based on previous >>> discussions on the mailing list and here at Deutsche Telekom, I see >>> a couple of design options. I would like to share those options with >>> the WG and try to reach consensus on a single option before >>> investing the time to write the I-D. >>> >>> 1) HTTP Delete on tokens endpoint >>> >>> DELETE seems a natural way for revoking (deleting) tokens. Although >>> the HTTP spec is a bit vaque in this concern, current practice >>> prohibits a body for DELETE requests. So the token must be addressed >>> by the request's URI. Lets assume the token is passed as URI query >>> parameter as follows: >>> >>> DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1 >>> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >>> >>> But is it advisable to pass tokens as URI query parameters? The >>> current character set definition for access tokens (§5.1.1) is not >>> URL-safe since it includes URI reserved characters (e.g. '/'). >>> Additionally, there is no definition of a refresh tokens character >>> set. So compliant authorization servers could issue tokens, which >>> cannot be safely passed as URI query parameters. >>> >>> Note: As an additional challenge, self-contained tokens can be very >>> large. So passing them as URI parameter may exceed URL length limits. >>> >>> I see the following alternatives to cope with the encoding problem: >>> >>> a) Force usage of a URL-safe character set for access and request >>> tokens. >>> - rather restrictive, will most likely collide with existing token >>> formats >>> - does not solve URL length problem >>> >>> b) Force base64-URL-safe encoding for all tokens on transit. >>> - does not solve URL length problem >>> - significant API change >>> >>> c) Authorization servers supporting revocation may additionally >>> issue a URL-safe token id in the access token response. This id is >>> used to reference the token in DELETE requests. >>> >>> HTTP/1.1 200 OK >>> Content-Type: application/json >>> Cache-Control: no-store >>> { >>> "access_token":"SlAV32hkKG/hhh/&%", >>> "access_token_id":"234567890", >>> "expires_in":3600, >>> "refresh_token":"8xLOxBtZp8&&&#&", >>> "refresh_token_id":"asdfghjklhgf" >>> } >>> >>> >>> DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 >>> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >>> >>> Note: Since tokens become addressable resources on the authz server, >>> one could also query or modify token data using a GET/PUT requests >>> >>> GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 >>> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >>> >>> HTTP/1.1 200 OK >>> Content-Type: application/json >>> Cache-Control: no-store >>> >>> { >>> "scope":"abc", >>> "issued_on":"08/11/2010", >>> "last_usage":"08/13/2010" } >>> >>> >>> 2) HTTP Post on dedicated revocation endpoint >>> >>> An additional endpoint is used to revoke tokens. The token to be >>> revoked is sent as request body parameter. >>> >>> POST /revocation HTTP/1.1 >>> Host: server.example.com >>> Content-Type: application/x-www-form-urlencoded >>> Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N >>> >>> refresh_token=n4E9O119d >>> >>> This option requires some support for the client to discover the >>> revocation endpoint. >>> >>> Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest >>> additional design options. >>> >>> regards, >>> Torsten. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth > From jpanzer@google.com Tue Aug 17 16:06:01 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171753A6828 for ; Tue, 17 Aug 2010 16:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.777 X-Spam-Level: X-Spam-Status: No, score=-105.777 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFMhKVYkXnt0 for ; Tue, 17 Aug 2010 16:05:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 71DF93A6817 for ; Tue, 17 Aug 2010 16:05:59 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o7HN6Yhj015324 for ; Tue, 17 Aug 2010 16:06:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282086394; bh=yKiZzAS4sqtSAEQPK2cvy9oPycI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=igZUnN4IAqbyc+ZdEpNCmXiTVqILIZLEW430pk3Xc9ce3FeQ7UHuI5ahW+adexLsq V9XgtOQx8B1yKs2+K9UHg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Jq+BFvkDCDkrNwRINsBWrwFooqAbU49WH9vy/F7ujJwbI5MyAgdUHCsjWmELorgJv WE5sGxP3j+eyScqO6i7cA== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by hpaq3.eem.corp.google.com with ESMTP id o7HN6S2h022594 for ; Tue, 17 Aug 2010 16:06:32 -0700 Received: by gwb11 with SMTP id 11so3040705gwb.4 for ; Tue, 17 Aug 2010 16:06:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.144.8 with SMTP id w8mr8308006ann.231.1282086392299; Tue, 17 Aug 2010 16:06:32 -0700 (PDT) Received: by 10.101.126.6 with HTTP; Tue, 17 Aug 2010 16:06:32 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> Date: Tue, 17 Aug 2010 16:06:32 -0700 Message-ID: From: John Panzer To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 23:06:01 -0000 Sure - as long as this is tied to the very special case of a tunneled protocol over http. On Tuesday, August 17, 2010, David Recordon wrote: > Luke's point still holds true of the core spec needing to allow a 200 sta= tus code on an error in this scenario. I'd also rather see this as part of = the core spec as it reduces the number of things that implementors will nee= d to read for common use cases. > > --David > > On Tue, Aug 17, 2010 at 9:06 AM, John Panzer wrote: > > Well, no, jsonp is a special transport layer inside http. =A0Making that > fuzzy will cause (interop and security) problems. > > On Tuesday, August 17, 2010, Luke Shepard wrote: >> From the perspective of OAuth, a JSONP endpoint is just another protecte= d resource. I'd rather not need us to write an extension for every type of = protected resource we might need to access. >> >> I think the wordsmithing you discussed is what Paul's proposing - just s= aying essentially "look, these are the HTTP error codes you can expect, but= it's okay for the server sometimes to give 200 on an error response anyway= ". That would be necessary even if we wrote an extension. >> >> On Aug 17, 2010, at 12:43 AM, Torsten Lodderstedt wrote: >> >>> Good point. The server will have to provide special JSONP support anywa= y. This is the only place where the requested status code handling is neede= d. >>> >>> +1 for a JSONP extension spec >>> >>> This might also result in much cleaner JSONP support. >>> >>> regards, >>> Torsten. >>> >>> Am 17.08.2010 um 09:28 schrieb John Panzer : >>> >>>> Except you cannot guarantee that result of course (proxies, apache >>>> plus tomcat separate processes etc. will all result in error codes). >>>> >>>> Doesn't this all depend on a jsonp extension in the first place - the >>>> client has to request a special jsonp response by specifying the >>>> callback, thus making the server both use 200s where possible and also >>>> wrap its response data in a callback call? =A0That's not part of the >>>> spec either, why not just define both pieces of behavior in a jsonp >>>> extension spec? =A0(Assuming this can be done without violating the >>>> letter of the core spec, which might take some wordsmithing.) >>>> >>>> On Monday, August 16, 2010, Torsten Lodderstedt wrote: >>>>> Paul Tarjan schrieb: >>>>> >>>>> Yes, I'm talking about 5.2.1 >>>>> >>>>> For JSONP the user's browser is the client. It will make a request by= executing some HTML like this: >>>>> >>>>> >>>>> >>>>> >>>>> (this is done instead of an AJAX request, because of cross-domain res= trictions). >>>>> >>>>> As to Aaron's point, Google sends 3 parameters to the callback functi= on, which I kind of like since the user can choose to get the code or not. = Something like: >>>>> >>>>> jsonp_cb({ >>>>> "error": "invalid_request", >>>>> "error_description": "An active access token must be used to query >>>>> information about the current user." >>>>> }. >>>>> 400, >>>>> 'Bad Request'); >>>>> >>>>> which you can grab with >>>>> >>>>> function jsonp_cb(response, code, status) { >>>>> } >>>>> >>>>> or ignore it with >>>>> >>>>> function jsonp_cb(response) { >>>>> } >>>>> >>>>> But all of this is outside of the spec. I just want to make sure the = spec says that the HTTP status code can send as 200 if the server+client ne= ed it for errors. >>>>> >>>>> >>>>> I think this can be achieved in two ways: (a) either the client tells= the server using a parameter or (b) the server always responds with status= code 200 in some cases. From my understanding, status code 200 is relevant= for requests following the rules of section 5.1.2 only. So my sugesstion w= ould be to go with option (b) and modify the spec to always return status c= ode 200 for such requests. This keeps the spec simpler and preserves the be= havior of requests-- > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From beaton@google.com Tue Aug 17 17:29:51 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F82D3A6765 for ; Tue, 17 Aug 2010 17:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.85 X-Spam-Level: X-Spam-Status: No, score=-105.85 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbcfc1FTRJvh for ; Tue, 17 Aug 2010 17:29:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3F4933A635F for ; Tue, 17 Aug 2010 17:29:50 -0700 (PDT) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o7I0UPFC031819 for ; Tue, 17 Aug 2010 17:30:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282091425; bh=6Kiod89BO3tG4a1tVQthcWi4KUA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=bhIMJcx+G12ZPfMH33p5GHfy6i4JjdDtf5mPVRatn4McHmipZUd70uK2PBwiwUwye H/EOL4bdOl2uxoSkznVRw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=Of16m80cRd47VCIHzZoo8PbHQhUVDyjrdM9uaq0ITM4lSmoluCxs4+B4MCsf9TN+M n47XHtpASi6SZMaKJolag== Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by kpbe14.cbf.corp.google.com with ESMTP id o7I0UNJQ028001 for ; Tue, 17 Aug 2010 17:30:24 -0700 Received: by pwj3 with SMTP id 3so79848pwj.37 for ; Tue, 17 Aug 2010 17:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.73.1 with SMTP id v1mr6519294wfa.29.1282091423569; Tue, 17 Aug 2010 17:30:23 -0700 (PDT) Received: by 10.142.170.17 with HTTP; Tue, 17 Aug 2010 17:30:23 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> Date: Tue, 17 Aug 2010 17:30:23 -0700 Message-ID: From: Brian Eaton To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 00:29:51 -0000 On Tue, Aug 17, 2010 at 11:48 AM, David Recordon wrote: > Luke's point still holds true of the core spec needing to allow a 200 status > code on an error in this scenario. I'd also rather see this as part of the > core spec as it reduces the number of things that implementors will need to > read for common use cases. For the record, I think any implementer that is relying on protected resources returning special response codes for any type of OAuth protocol issue is probably going to get burned. Variation in protected resource behavior has been a consistent problem in OAuth 1.0, and I doubt that can change in OAuth 2. It's tough to get protected resource servers to be consistent; they frequently have good reasons (e.g. jsonp) to be inconsistent. Authorization servers are simpler beasts. From jpanzer@google.com Tue Aug 17 19:33:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 887F53A6858 for ; Tue, 17 Aug 2010 19:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08DM5n1OAYP9 for ; Tue, 17 Aug 2010 19:33:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id D0FAC3A684F for ; Tue, 17 Aug 2010 19:33:26 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o7I2Y0DH031473 for ; Tue, 17 Aug 2010 19:34:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282098841; bh=cbPMiewWmp7HEHTFuk8aH9vf1+I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=oo/Mj9y3GgZRtdXbGQoz9izSNo8Rqjs6gBzKazGE9jLYrDBn6eGPCxMulnqWlNR8J VMff2S8yPAJt+YnKNmCtA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Brk4FpkCD2d8y/52PU183rWQocJ/GlodchvPQYqSjqLRTLoFe810Gxn1XjlqWvoVO 6Sa4mgboVKbI/tCsgc0wA== Received: from gyf2 (gyf2.prod.google.com [10.243.50.66]) by hpaq13.eem.corp.google.com with ESMTP id o7I2XoKV030895 for ; Tue, 17 Aug 2010 19:33:59 -0700 Received: by gyf2 with SMTP id 2so15831gyf.22 for ; Tue, 17 Aug 2010 19:33:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.32.19 with SMTP id f19mr8463955anf.257.1282098838979; Tue, 17 Aug 2010 19:33:58 -0700 (PDT) Received: by 10.101.126.6 with HTTP; Tue, 17 Aug 2010 19:33:58 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> Date: Tue, 17 Aug 2010 19:33:58 -0700 Message-ID: From: John Panzer To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 02:33:30 -0000 Is there any legit reason other than jsonp specifically? In the wild I mean. On Tuesday, August 17, 2010, Brian Eaton wrote: > On Tue, Aug 17, 2010 at 11:48 AM, David Recordon wr= ote: >> Luke's point still holds true of the core spec needing to allow a 200 st= atus >> code on an error in this scenario. I'd also rather see this as part of t= he >> core spec as it reduces the number of things that implementors will need= to >> read for common use cases. > > For the record, I think any implementer that is relying on protected > resources returning special response codes for any type of OAuth > protocol issue is probably going to get burned. =A0Variation in > protected resource behavior has been a consistent problem in OAuth > 1.0, and I doubt that can change in OAuth 2. > > It's tough to get protected resource servers to be consistent; they > frequently have good reasons (e.g. jsonp) to be inconsistent. > > Authorization servers are simpler beasts. > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From mnot@mnot.net Tue Aug 17 23:15:30 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858F83A6A09 for ; Tue, 17 Aug 2010 23:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.673 X-Spam-Level: X-Spam-Status: No, score=-105.673 tagged_above=-999 required=5 tests=[AWL=-1.674, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_66=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFuZ2DV0smII for ; Tue, 17 Aug 2010 23:15:19 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id AB23D3A690A for ; Tue, 17 Aug 2010 23:15:11 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.248.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 02189509DB; Wed, 18 Aug 2010 02:15:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 18 Aug 2010 16:15:37 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <6370EF39-166D-4E28-B77A-67504BF7725B@mnot.net> References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> To: John Panzer X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 06:15:31 -0000 ...and tunneling protocols over HTTP have worked *so* well in the = past... *makes another drink to help forget the SOAP nightmares* back to your regular programming... On 18/08/2010, at 9:06 AM, John Panzer wrote: > Sure - as long as this is tied to the very special case of a tunneled > protocol over http. >=20 > On Tuesday, August 17, 2010, David Recordon = wrote: >> Luke's point still holds true of the core spec needing to allow a 200 = status code on an error in this scenario. I'd also rather see this as = part of the core spec as it reduces the number of things that = implementors will need to read for common use cases. >>=20 >> --David >>=20 >> On Tue, Aug 17, 2010 at 9:06 AM, John Panzer = wrote: >>=20 >> Well, no, jsonp is a special transport layer inside http. Making = that >> fuzzy will cause (interop and security) problems. >>=20 >> On Tuesday, August 17, 2010, Luke Shepard = wrote: >>> =46rom the perspective of OAuth, a JSONP endpoint is just another = protected resource. I'd rather not need us to write an extension for = every type of protected resource we might need to access. >>>=20 >>> I think the wordsmithing you discussed is what Paul's proposing - = just saying essentially "look, these are the HTTP error codes you can = expect, but it's okay for the server sometimes to give 200 on an error = response anyway". That would be necessary even if we wrote an extension. >>>=20 >>> On Aug 17, 2010, at 12:43 AM, Torsten Lodderstedt wrote: >>>=20 >>>> Good point. The server will have to provide special JSONP support = anyway. This is the only place where the requested status code handling = is needed. >>>>=20 >>>> +1 for a JSONP extension spec >>>>=20 >>>> This might also result in much cleaner JSONP support. >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>> Am 17.08.2010 um 09:28 schrieb John Panzer : >>>>=20 >>>>> Except you cannot guarantee that result of course (proxies, apache >>>>> plus tomcat separate processes etc. will all result in error = codes). >>>>>=20 >>>>> Doesn't this all depend on a jsonp extension in the first place - = the >>>>> client has to request a special jsonp response by specifying the >>>>> callback, thus making the server both use 200s where possible and = also >>>>> wrap its response data in a callback call? That's not part of the >>>>> spec either, why not just define both pieces of behavior in a = jsonp >>>>> extension spec? (Assuming this can be done without violating the >>>>> letter of the core spec, which might take some wordsmithing.) >>>>>=20 >>>>> On Monday, August 16, 2010, Torsten Lodderstedt = wrote: >>>>>> Paul Tarjan schrieb: >>>>>>=20 >>>>>> Yes, I'm talking about 5.2.1 >>>>>>=20 >>>>>> For JSONP the user's browser is the client. It will make a = request by executing some HTML like this: >>>>>>=20 >>>>>> >>>>>> >>>>>>=20 >>>>>> (this is done instead of an AJAX request, because of cross-domain = restrictions). >>>>>>=20 >>>>>> As to Aaron's point, Google sends 3 parameters to the callback = function, which I kind of like since the user can choose to get the code = or not. Something like: >>>>>>=20 >>>>>> jsonp_cb({ >>>>>> "error": "invalid_request", >>>>>> "error_description": "An active access token must be used to = query >>>>>> information about the current user." >>>>>> }. >>>>>> 400, >>>>>> 'Bad Request'); >>>>>>=20 >>>>>> which you can grab with >>>>>>=20 >>>>>> function jsonp_cb(response, code, status) { >>>>>> } >>>>>>=20 >>>>>> or ignore it with >>>>>>=20 >>>>>> function jsonp_cb(response) { >>>>>> } >>>>>>=20 >>>>>> But all of this is outside of the spec. I just want to make sure = the spec says that the HTTP status code can send as 200 if the = server+client need it for errors. >>>>>>=20 >>>>>>=20 >>>>>> I think this can be achieved in two ways: (a) either the client = tells the server using a parameter or (b) the server always responds = with status code 200 in some cases. =46rom my understanding, status code = 200 is relevant for requests following the rules of section 5.1.2 only. = So my sugesstion would be to go with option (b) and modify the spec to = always return status code 200 for such requests. This keeps the spec = simpler and preserves the behavior of requests-- >> -- >> John Panzer / Google >> jpanzer@google.com / abstractioneer.org / @jpanzer >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >=20 > --=20 > -- > John Panzer / Google > jpanzer@google.com / abstractioneer.org / @jpanzer > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Mark Nottingham http://www.mnot.net/ From beaton@google.com Tue Aug 17 23:29:48 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B783A68BB for ; Tue, 17 Aug 2010 23:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.139 X-Spam-Level: X-Spam-Status: No, score=-104.139 tagged_above=-999 required=5 tests=[AWL=1.838, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t7gW0XYs8Nd for ; Tue, 17 Aug 2010 23:29:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D57243A67E1 for ; Tue, 17 Aug 2010 23:29:46 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o7I5w0ip002736 for ; Tue, 17 Aug 2010 22:58:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282111081; bh=4UAjwcr7/wR1/ceCz2X7Gy3dFHw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=a0tS2DQTMiF+pKxRO95SE81T0eLxW1HP5QWUwuf8jvWa2CLBxhEknH8q696cw69vO oR7tPk6rrlaShSPAB5aKQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=EU6VGsfz/9JCUe5fSWmzkobI4/hAKVfWh8BXb5M7kB6GY2TRGF43IkryI1x73RERi Zrj9q1Fpfe5WaPW6uofDQ== Received: from pvc30 (pvc30.prod.google.com [10.241.209.158]) by wpaz5.hot.corp.google.com with ESMTP id o7I5vxFb030721 for ; Tue, 17 Aug 2010 22:57:59 -0700 Received: by pvc30 with SMTP id 30so110864pvc.28 for ; Tue, 17 Aug 2010 22:57:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.211.5 with SMTP id j5mr6665824wfg.261.1282111078875; Tue, 17 Aug 2010 22:57:58 -0700 (PDT) Received: by 10.142.170.17 with HTTP; Tue, 17 Aug 2010 22:57:58 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> Date: Tue, 17 Aug 2010 22:57:58 -0700 Message-ID: From: Brian Eaton To: John Panzer Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 06:29:48 -0000 On Tue, Aug 17, 2010 at 7:33 PM, John Panzer wrote: > Is there any legit reason other than jsonp specifically? Protected resource authors are slack and are not going to read the spec. That might not be a great reason, but it's not a bad one either. The other reason people get funny with these status codes has to do with browser behavior. Sometimes browsers react in funny ways to funny HTTP status codes. To be on the safe side, developers tend to return an HTTP 200 with whatever they want the user to see. The last reason is that servers fail, and instead of returning the error they meant to return they serve up a bit of static HTML that says, more or less, "Whoa. That sucked." From mnot@mnot.net Tue Aug 17 23:36:38 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FEF3A6A15 for ; Tue, 17 Aug 2010 23:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.936 X-Spam-Level: X-Spam-Status: No, score=-104.936 tagged_above=-999 required=5 tests=[AWL=-2.337, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVAvjsoYHg1p for ; Tue, 17 Aug 2010 23:36:31 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id C69AB3A6A1C for ; Tue, 17 Aug 2010 23:36:17 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.248.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DEAD2509DB; Wed, 18 Aug 2010 02:36:37 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 18 Aug 2010 16:36:34 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> To: Brian Eaton X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 06:36:38 -0000 On 18/08/2010, at 3:57 PM, Brian Eaton wrote: > On Tue, Aug 17, 2010 at 7:33 PM, John Panzer = wrote: >> Is there any legit reason other than jsonp specifically? >=20 > Protected resource authors are slack and are not going to read the > spec. That might not be a great reason, but it's not a bad one > either. >=20 > The other reason people get funny with these status codes has to do > with browser behavior. Sometimes browsers react in funny ways to > funny HTTP status codes. To be on the safe side, developers tend to > return an HTTP 200 with whatever they want the user to see. Can you give concrete examples, please? What browsers do what exactly, = under what circumstances? > The last reason is that servers fail, and instead of returning the > error they meant to return they serve up a bit of static HTML that > says, more or less, "Whoa. That sucked." > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Mark Nottingham http://www.mnot.net/ From eran@hueniverse.com Tue Aug 17 23:59:34 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 174383A6821 for ; Tue, 17 Aug 2010 23:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd9Xi4iEUXmH for ; Tue, 17 Aug 2010 23:59:27 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A74C83A690A for ; Tue, 17 Aug 2010 23:59:27 -0700 (PDT) Received: (qmail 32027 invoked from network); 18 Aug 2010 07:00:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2010 07:00:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 18 Aug 2010 00:00:01 -0700 From: Eran Hammer-Lahav To: Paul Tarjan , OAuth WG Date: Wed, 18 Aug 2010 00:00:09 -0700 Thread-Topic: Returning HTTP 200 on Error for JSONP Thread-Index: AQHLOy7WyjYGNn3uj0G9ZJ7bfvdE15Lmy+NA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F1D7219@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> In-Reply-To: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D7219P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 06:59:34 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D7219P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree. The sole purpose of the specification is to achieve interop. By creating th= is exception for JSONP calls, you are breaking interop with non JSONP clien= ts. For this to work, you need to specify exactly when this exception happe= ns, and how to deliver the HTTP status code to the client. This sounds like= a specification. For example, how is the client going to get the original = HTTP status code? This is not a legal document, and you are free to implemented it differentl= y if you do it in a way that does not harm interop. In this case, you are b= asically proposing changing a MUST to a SHOULD, which takes away any intero= p value the requirement has in the first place (ie. being predictable and c= onsistent). If JSONP is an important use case, and if it should be consistently impleme= nted across services, then it needs to be specified and such a specificatio= n can clear override the core specification directive on HTTP status code. = I don't know where people got the idea that other specifications cannot mod= ify requirements in the core specification - that's just silly. As long as = you spell it out and provide enough detail to maintain interop with the new= work, it is perfectly fine. This is not the constitution. As for the argument that developers are not going to read so many specifica= tion, so core should address it - that's also silly. Most developers are ne= ver going to read the specification. At best, they will read the vendor API= docs. For the record, I have no objection to the core specification fully address= ing the JSONP use case. But I'm opposed to making such an underspecified ex= ception. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= aul Tarjan Sent: Friday, August 13, 2010 2:31 PM To: OAuth WG Subject: [OAUTH-WG] Returning HTTP 200 on Error for JSONP Hi Fellow OAuthers, If a resource wants to return data via the JSONP mechanism then it MUST ret= urn an HTTP 200 error code, or else the browser won't actually call the cal= lback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on error= s which won't ever tell the client that an error happens. For example: GET /me?callback=3Djsonp_cb HTTP/1.1 Host: graph.facebook.com HTTP/1.1 200 OK Content-Type: text/javascript; charset=3DUTF-8 Content-Length: 152 jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query infor= mation about the current user." }); would never get sent to the browser if we obeyed the spec and sent it as an= HTTP 400. --- So, I recommend we add wording to 5.2.1 like: If the protected resource is issuing a response that requires a different H= TTP status code than the one specified (for example, JSONP), then it MAY us= e an alternate HTTP code. The server should make it clear which parameters = trigger this mode so that clients know not to rely on the HTTP status code = for error detection. Paul --_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D7219P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I disagre= e.

 

The sole purpose of the specification is t= o achieve interop. By creating this exception for JSONP calls, you are brea= king interop with non JSONP clients. For this to work, you need to specify = exactly when this exception happens, and how to deliver the HTTP status cod= e to the client. This sounds like a specification. For example, how is the = client going to get the original HTTP status code?

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>This is not a legal document, and you are free to implemented it diff= erently if you do it in a way that does not harm interop. In this case, you= are basically proposing changing a MUST to a SHOULD, which takes away any = interop value the requirement has in the first place (ie. being predictable= and consistent).

&nb= sp;

If JSONP is an important us= e case, and if it should be consistently implemented across services, then = it needs to be specified and such a specification can clear override the co= re specification directive on HTTP status code. I don’t know where pe= ople got the idea that other specifications cannot modify requirements in t= he core specification – that’s just silly. As long as you spell= it out and provide enough detail to maintain interop with the new work, it= is perfectly fine. This is not the constitution.

 

As for the argument that developers are not going to read so many spec= ification, so core should address it – that’s also silly. Most = developers are never going to read the specification. At best, they will re= ad the vendor API docs.

 

For the record, I hav= e no objection to the core specification fully addressing the JSONP use cas= e. But I’m opposed to making such an underspecified exception.

 

EHL

 

 =

 

<= div>

From: oauth-bounces@ietf.org [mailto:oauth-= bounces@ietf.org] On Behalf Of Paul Tarjan
Sent: Friday, A= ugust 13, 2010 2:31 PM
To: OAuth WG
Subject: [OAUTH-WG]= Returning HTTP 200 on Error for JSONP

 

Hi Fellow OAuthers,

If a resource wants to return da= ta via the JSONP mechanism then it MUST return an HTTP 200 error code, or e= lse the browser won't actually call the callback. The OAuth spec as it stan= ds requires HTTP 400 or 401 or 403 on errors which won't ever tell the clie= nt that an error happens. 

For example:

GET /me?callback=3Djsonp_cb= HTTP/1.1
Host: graph.facebo= ok.com

HTTP/1.1 200 OK
Content-Type: text/javascript; charset= =3DUTF-8
Content-Length: 152=

jsonp_cb({

   "error": "invalid_request",

   "error_descr= iption": "An active access token must be used to query informatio= n about the current user."

});

 

=

would never get sent to the browser if we obeyed = the spec and sent it as an HTTP 400.

---
So, I recommend we add w= ording to 5.2.1 like:

If the protected resource is issuing a respons= e that requires a different HTTP status code than the one specified (for ex= ample, JSONP), then it MAY use an alternate HTTP code. The server should ma= ke it clear which parameters trigger this mode so that clients know not to = rely on the HTTP status code for error detection.


Paul

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D7219P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Aug 18 00:10:55 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D95A03A6A1F for ; Wed, 18 Aug 2010 00:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1PbHemYdK2t for ; Wed, 18 Aug 2010 00:10:49 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D38673A68C0 for ; Wed, 18 Aug 2010 00:10:49 -0700 (PDT) Received: (qmail 11550 invoked from network); 18 Aug 2010 07:11:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Aug 2010 07:11:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 18 Aug 2010 00:11:24 -0700 From: Eran Hammer-Lahav To: "OAuth WG (oauth@ietf.org)" Date: Wed, 18 Aug 2010 00:11:31 -0700 Thread-Topic: Quick update Thread-Index: Acs+oyn45t7eOkwSSmSbLl05V/6iVg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F1D721B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D721BP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Quick update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 07:10:56 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D721BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I plan to start working on the next core draft next week and publish it in = early September. Please submit all change requests and feedback to the list= by 8/27 to be discussed, considered, and included. Changes received after = that time will be queued for the next draft. As for authoring or editing additional drafts (such as discovery), I have d= ecided to focus on getting core completed and at this point have no plans t= o work on any other document in an official capacity. Those interested in d= iscovery or other topics should submit proposals and take the lead on pushi= ng them through. EHL --_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D721BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I plan to start = working on the next core draft next week and publish it in early September.= Please submit all change requests and feedback to the list by 8/27 to be d= iscussed, considered, and included. Changes received after that time will b= e queued for the next draft.

 =

As for authoring or editing additional draft= s (such as discovery), I have decided to focus on getting core completed an= d at this point have no plans to work on any other document in an official = capacity. Those interested in discovery or other topics should submit propo= sals and take the lead on pushing them through.

 

EHL

 

= --_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D721BP3PW5EX1MB01E_-- From lshepard@facebook.com Wed Aug 18 00:11:59 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714E93A6A15 for ; Wed, 18 Aug 2010 00:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.168 X-Spam-Level: X-Spam-Status: No, score=-102.168 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMcJTNpdeWMu for ; Wed, 18 Aug 2010 00:11:57 -0700 (PDT) Received: from mx-out.facebook.com (outmail003.snc1.tfbnw.net [69.63.178.162]) by core3.amsl.com (Postfix) with ESMTP id C74823A6A1E for ; Wed, 18 Aug 2010 00:11:57 -0700 (PDT) Received: from [10.18.255.125] ([10.18.255.125:49292] helo=mail.thefacebook.com) by mta014.snc1.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34067)) with ESMTP id 84/3E-21639-1E78B6C4; Wed, 18 Aug 2010 00:12:33 -0700 Received: from SC-MBX05.TheFacebook.com ([169.254.4.134]) by sc-hub04.TheFacebook.com ([fe80::8df5:7f90:d4a0:bb9%11]) with mapi; Wed, 18 Aug 2010 00:12:32 -0700 From: Luke Shepard To: Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Returning HTTP 200 on Error for JSONP Thread-Index: AQHLPqS5pAQSxMChcE2IAPt7ryHRWw== Date: Wed, 18 Aug 2010 07:12:28 +0000 Message-ID: <2A2D3A70-1202-443E-9263-5AEA66F246CC@facebook.com> References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3F1D7219@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F1D7219@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_2A2D3A701202443E92635AEA66F246CCfacebookcom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 07:11:59 -0000 --_000_2A2D3A701202443E92635AEA66F246CCfacebookcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable For example, how is the client going to get the original HTTP status code? Why does the client need the HTTP status code? It seems like the real data = is the OAuth error code (i.e., "invalid request"). The HTTP status code is = just gravy so that we're consistent with HTTP. This is not a legal document, and you are free to implemented it differentl= y if you do it in a way that does not harm interop. In this case, you are b= asically proposing changing a MUST to a SHOULD, which takes away any intero= p value the requirement has in the first place (ie. being predictable and c= onsistent). Okay ... so why are we specifying HTTP codes at all then? Since we have cle= arly defined the error types, why is it wrong to say "use whatever HTTP cod= e you think is right, here are some suggestions"? If JSONP is an important use case It is. and if it should be consistently implemented across services, then it needs= to be specified and such a specification can clear override the core speci= fication directive on HTTP status code. I dunno, JSONP is pretty commonly implemented across lots of services today= . You typically pass in the parameter "callback" and then that prepends you= r response. I'm not aware of a specification for it, but convention + copyi= ng each other has made services somewhat consistent in this. In any case, I don't think this group should be held up by writing a new sp= ec just to address this one use case. I don=92t know where people got the idea that other specifications cannot m= odify requirements in the core specification =96 that=92s just silly. As lo= ng as you spell it out and provide enough detail to maintain interop with t= he new work, it is perfectly fine. This is not the constitution. (The Constitution allows amendments, too - but similarly, it's a lot of wor= k) From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Paul Tarjan Sent: Friday, August 13, 2010 2:31 PM To: OAuth WG Subject: [OAUTH-WG] Returning HTTP 200 on Error for JSONP Hi Fellow OAuthers, If a resource wants to return data via the JSONP mechanism then it MUST ret= urn an HTTP 200 error code, or else the browser won't actually call the cal= lback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on error= s which won't ever tell the client that an error happens. For example: GET /me?callback=3Djsonp_cb HTTP/1.1 Host: graph.facebook.com HTTP/1.1 200 OK Content-Type: text/javascript; charset=3DUTF-8 Content-Length: 152 jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query infor= mation about the current user." }); would never get sent to the browser if we obeyed the spec and sent it as an= HTTP 400. --- So, I recommend we add wording to 5.2.1 like: If the protected resource is issuing a response that requires a different H= TTP status code than the one specified (for example, JSONP), then it MAY us= e an alternate HTTP code. The server should make it clear which parameters = trigger this mode so that clients know not to rely on the HTTP status code = for error detection. Paul _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_2A2D3A701202443E92635AEA66F246CCfacebookcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
For example, how is the client going to get the original H= TTP status code?

Why does the client need the HTTP sta= tus code? It seems like the real data is the OAuth error code (i.e., "= invalid request"). The HTTP status code is just gravy so that we're co= nsistent with HTTP.

<= div style=3D"margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; m= argin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; ">= This is not a legal document, = and you are free to implemented it differently if you do it in a way that d= oes not harm interop. In this case, you are basically proposing changing a = MUST to a SHOULD, which takes away any interop value the requirement has in= the first place (ie. being predictable and consistent).
=

Okay ... so why are we specif= ying HTTP codes at all then? Since we have clearly defined the error types,= why is it wrong to say "use whatever HTTP code you think is right, he= re are some suggestions"?

and if it should = be consistently implemented across services, then it needs to be specified = and such a specification can clear override the core specification directiv= e on HTTP status code.
I dunno, JSONP is pretty commonly implemented across lots of se= rvices today. You typically pass in the parameter "callback" and = then that prepends your response. I'm not aware of a specification for it, = but convention + copying each other has made services somewhat consiste= nt in this.

In any case, I don't think this group = should be held up by writing a new spec just to address this one use case.<= /div>
= I don=92t know where people got the idea that other specifications cannot m= odify requirements in the core specification =96 that=92s just silly. As lo= ng as you spell it out and provide enough detail to maintain interop with t= he new work, it is perfectly fine. This is not the constitution.

(The Constitution all= ows amendments, too - but similarly, it's a lot of work)

&n= bsp;

&n= bsp;
 
=
From= : o= auth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] = ;On Behalf Of <= /b>Paul Tarjan
Sent: <= /span>Friday, August 13, 2010 2:31 PM
To: OAuth WG
Subject: [OAUTH-WG] Returning HTTP 200 on Error for JS= ONP
 

GE= T /me?callback=3Djsonp_cb HTTP/1.1
Host: graph.face= book.com

HTTP/1.1 200 OK
Content-Type: text/javascript; chars= et=3DUTF-8
Content-Length: 152

jsonp_cb({
   &quo= t;error": "invalid_request",
&nb= sp;  "error_description": "An active access token must = be used to query information about the current user."
=
 
w= ould never get sent to the browser if we obeyed the spec and sent it as an = HTTP 400.

---
So, I recommend we add wording to 5.2.1 like:
If the protected resource is issuing a response that requires a different= HTTP status code than the one specified (for example, JSONP), then it MAY = use an alternate HTTP code. The server should make it clear which parameter= s trigger this mode so that clients know not to rely on the HTTP status cod= e for error detection.


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

<= /body>= --_000_2A2D3A701202443E92635AEA66F246CCfacebookcom_-- From eran@hueniverse.com Wed Aug 18 00:17:42 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87B143A68C0 for ; Wed, 18 Aug 2010 00:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylsXrG3UiDZv for ; Wed, 18 Aug 2010 00:17:31 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 26BC93A681A for ; Wed, 18 Aug 2010 00:17:31 -0700 (PDT) Received: (qmail 17570 invoked from network); 18 Aug 2010 07:18:06 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Aug 2010 07:18:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 18 Aug 2010 00:18:06 -0700 From: Eran Hammer-Lahav To: Luke Shepard Date: Wed, 18 Aug 2010 00:18:13 -0700 Thread-Topic: [OAUTH-WG] Returning HTTP 200 on Error for JSONP Thread-Index: AQHLPqS5pAQSxMChcE2IAPt7ryHRW5LmzTaA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F1D721D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <90C41DD21FB7C64BB94121FBBC2E72343B3F1D7219@P3PW5EX1MB01.EX1.SECURESERVER.NET> <2A2D3A70-1202-443E-9263-5AEA66F246CC@facebook.com> In-Reply-To: <2A2D3A70-1202-443E-9263-5AEA66F246CC@facebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D721DP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 07:17:42 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D721DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Luke Shepard [mailto:lshepard@facebook.com] Sent: Wednesday, August 18, 2010 12:12 AM To: Eran Hammer-Lahav Cc: Paul Tarjan; OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP For example, how is the client going to get the original HTTP status code? Why does the client need the HTTP status code? It seems like the real data = is the OAuth error code (i.e., "invalid request"). The HTTP status code is = just gravy so that we're consistent with HTTP. This is not a legal document, and you are free to implemented it differentl= y if you do it in a way that does not harm interop. In this case, you are b= asically proposing changing a MUST to a SHOULD, which takes away any intero= p value the requirement has in the first place (ie. being predictable and c= onsistent). Okay ... so why are we specifying HTTP codes at all then? Since we have cle= arly defined the error types, why is it wrong to say "use whatever HTTP cod= e you think is right, here are some suggestions"? There is nothing wrong with saying that, if we decide that there is no inte= rop value in specifying them. Pointing to the HTTP spec and say follow that= is perfectly fine. But as currently written, since the codes are prescribe= d, clients are allowed to rely on them, which will lead to problems. EHL If JSONP is an important use case It is. and if it should be consistently implemented across services, then it needs= to be specified and such a specification can clear override the core speci= fication directive on HTTP status code. I dunno, JSONP is pretty commonly implemented across lots of services today= . You typically pass in the parameter "callback" and then that prepends you= r response. I'm not aware of a specification for it, but convention + copyi= ng each other has made services somewhat consistent in this. In any case, I don't think this group should be held up by writing a new sp= ec just to address this one use case. I don't know where people got the idea that other specifications cannot mod= ify requirements in the core specification - that's just silly. As long as = you spell it out and provide enough detail to maintain interop with the new= work, it is perfectly fine. This is not the constitution. (The Constitution allows amendments, too - but similarly, it's a lot of wor= k) From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Paul Tarjan Sent: Friday, August 13, 2010 2:31 PM To: OAuth WG Subject: [OAUTH-WG] Returning HTTP 200 on Error for JSONP Hi Fellow OAuthers, If a resource wants to return data via the JSONP mechanism then it MUST ret= urn an HTTP 200 error code, or else the browser won't actually call the cal= lback. The OAuth spec as it stands requires HTTP 400 or 401 or 403 on error= s which won't ever tell the client that an error happens. For example: GET /me?callback=3Djsonp_cb HTTP/1.1 Host: graph.facebook.com HTTP/1.1 200 OK Content-Type: text/javascript; charset=3DUTF-8 Content-Length: 152 jsonp_cb({ "error": "invalid_request", "error_description": "An active access token must be used to query infor= mation about the current user." }); would never get sent to the browser if we obeyed the spec and sent it as an= HTTP 400. --- So, I recommend we add wording to 5.2.1 like: If the protected resource is issuing a response that requires a different H= TTP status code than the one specified (for example, JSONP), then it MAY us= e an alternate HTTP code. The server should make it clear which parameters = trigger this mode so that clients know not to rely on the HTTP status code = for error detection. Paul _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D721DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&nbs= p;

 

=

From: Luke Shep= ard [mailto:lshepard@facebook.com]
Sent: Wednesday, August 18, 2= 010 12:12 AM
To: Eran Hammer-Lahav
Cc: Paul Tarjan; OAu= th WG
Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSO= NP

 

For example, how is the client goin= g to get the original HTTP status code?

<= /div>

 

Why does the client need the HTTP status code? It seems like the real data= is the OAuth error code (i.e., "invalid request"). The HTTP stat= us code is just gravy so that we're consistent with HTTP.



<= div>

This is not a legal document, and you are free to imple= mented it differently if you do it in a way that does not harm interop. In = this case, you are basically proposing changing a MUST to a SHOULD, which t= akes away any interop value the requirement has in the first place (ie. bei= ng predictable and consistent).

 

Okay ... so why are = we specifying HTTP codes at all then? Since we have clearly defined the err= or types, why is it wrong to say "use whatever HTTP code you think is = right, here are some suggestions"?

 <= /o:p>

There is nothing wrong with say= ing that, if we decide that there is no interop value in specifying them. P= ointing to the HTTP spec and say follow that is perfectly fine. But as curr= ently written, since the codes are prescribed, clients are allowed to rely = on them, which will lead to problems.

 

EHL

 

<= div>

If JSONP is= an important use case

 

It is.



and if it should be co= nsistently implemented across services, then it needs to be specified and s= uch a specification can clear override the core specification directive on = HTTP status code.

 

I dunno, JSONP is pretty commonly impleme= nted across lots of services today. You typically pass in the parameter &qu= ot;callback" and then that prepends your response. I'm not aware of a = specification for it, but convention + copying each other has made services= somewhat consistent in this.

 

In any case, I don't think this group shou= ld be held up by writing a new spec just to address this one use case.=



I don’t know where people got the idea that other specifications ca= nnot modify requirements in the core specification – that’s jus= t silly. As long as you spell it out and provide enough detail to maintain = interop with the new work, it is perfectly fine. This is not the constituti= on.

 

(The Constitution allows amendments, too - but simila= rly, it's a lot of work)

&nb= sp;

 

 

 

From: oauth-b= ounces@ietf.org [mailto= :oauth-bounces@ietf.org] On Behalf Of Paul Tarj= an
Sent: Friday, = August 13, 2010 2:31 PM
To:&n= bsp;OAuth WG
Subject:&= nbsp;[OAUTH-WG] Returning HTTP 200 on Error for JSONP

 

Hi Fellow O= Authers,

If a resource wants to return data via the JSONP mechanism = then it MUST return an HTTP 200 error code, or else the browser won't actua= lly call the callback. The OAuth spec as it stands requires HTTP 400 or 401= or 403 on errors which won't ever tell the client that an error happens.&n= bsp;

For example:

GET /me?callback=3Djsonp_cb HTTP/1.1
Host: graph.facebook.com

HTTP/1.1 200 OK
Content-= Type: text/javascript; charset=3DUTF-8
Content-Length: _______________________________________________
OAu= th mailing list
OAuth@ietf.org
= https://www.ietf.or= g/mailman/listinfo/oauth

=

 

= = --_000_90C41DD21FB7C64BB94121FBBC2E72343B3F1D721DP3PW5EX1MB01E_-- From eran@hueniverse.com Wed Aug 18 00:19:25 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E363A681A for ; Wed, 18 Aug 2010 00:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNHtdp-DORCc for ; Wed, 18 Aug 2010 00:19:24 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9F08A3A6821 for ; Wed, 18 Aug 2010 00:19:24 -0700 (PDT) Received: (qmail 3293 invoked from network); 18 Aug 2010 07:20:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Aug 2010 07:20:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 18 Aug 2010 00:20:00 -0700 From: Eran Hammer-Lahav To: Brian Campbell , David Recordon Date: Wed, 18 Aug 2010 00:20:07 -0700 Thread-Topic: [OAUTH-WG] more than one assertion? Thread-Index: Acs7KeM6i9hEwAC6Q5OZrPAVBjVqdgDe8VIA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F1D721E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 07:19:25 -0000 The assertion flow has been "upgraded" from an edge case to the way new acc= ess grants are defined. It's part of the extensibility model, and as such, = is going to stay in the core spec. EHL -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Friday, August 13, 2010 1:55 PM To: David Recordon Cc: oauth Subject: Re: [OAUTH-WG] more than one assertion? On Thu, Aug 12, 2010 at 2:04 PM, David Recordon wrote= : > Given that, would you strongly object to these proposals being written=20 > in a separate document than the core spec? The device flow is a good=20 > example of where we're doing this. We really think that it will be=20 > useful, are working on implementations, but it hasn't yet been proven=20 > in production. The assertion flow should stay in core (others have expressed this opinion = as well). I've got interop tested code built on that that is about to GA. As far as the client assertions, I do believe there's real value in having = a clean extension point for stronger forms of client authentication. Yaron= 's proposed language does a pretty good job I think. But if it can be done= in a simpler way, let's discuss. I'll probably regret saying this, but wha= t about not using the word "assertion" for stronger client auth options? T= hat might help eliminate some confusion. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From sDronia@gmx.de Wed Aug 18 06:04:15 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D213A6981 for ; Wed, 18 Aug 2010 06:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.135 X-Spam-Level: X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hJBq-VuQxj0 for ; Wed, 18 Aug 2010 06:04:14 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 3CD663A6965 for ; Wed, 18 Aug 2010 06:04:13 -0700 (PDT) Received: (qmail invoked by alias); 18 Aug 2010 13:04:46 -0000 Received: from tmo-099-101.customers.d1-online.com (EHLO [10.171.177.149]) [80.187.99.101] by mail.gmx.net (mp065) with SMTP; 18 Aug 2010 15:04:46 +0200 X-Authenticated: #3259608 X-Provags-ID: V01U2FsdGVkX19ka9xYpV9ki57veNSmlbTlAt553BfC8XCPwDKaJ2 ZkOjD4ncqUlxYC Message-ID: <4C6BDA6B.1020805@gmx.de> Date: Wed, 18 Aug 2010 15:04:43 +0200 From: Stefanie Dronia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.1.11) Gecko/20100711 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Torsten Lodderstedt References: <4C69A909.2060006@lodderstedt.net> In-Reply-To: <4C69A909.2060006@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] survey: token revocation design options X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 13:04:15 -0000 Hi Torsten, ++2. No care about token formats or URL length problem. -1: all options bring some problems along (as you already indicated). Additionally, an overloading of HTTP DELETE (as Igor mentioned) is not an option from my point of view. Every overloading would be deployment specific (or has to be defined by the OAuth spec???) and I doubt that it is possible to overload this method with widely-used frameworks. -1c: Introduction of token ids: If a token is addressed by its ID, it is IMO not possible to verify in all cases that the client (who requests revocation/modification) is same client that the token was issued for before if the authorization server is stateless. So someone might catch a token and then revokes it. May there be other security issues? Another drawback is that the access token response has to be extended. What kind of modifications of tokens do you have in mind? (as you commented with 1c) Regards, Stefanie Am 16.08.2010 23:09, schrieb Torsten Lodderstedt: > Hi all, > > I intend to submit a I-D for token revocation. Based on previous > discussions on the mailing list and here at Deutsche Telekom, I see a > couple of design options. I would like to share those options with the > WG and try to reach consensus on a single option before investing the > time to write the I-D. > > 1) HTTP Delete on tokens endpoint > > DELETE seems a natural way for revoking (deleting) tokens. Although > the HTTP spec is a bit vaque in this concern, current practice > prohibits a body for DELETE requests. So the token must be addressed > by the request's URI. Lets assume the token is passed as URI query > parameter as follows: > > DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > But is it advisable to pass tokens as URI query parameters? The > current character set definition for access tokens (§5.1.1) is not > URL-safe since it includes URI reserved characters (e.g. '/'). > Additionally, there is no definition of a refresh tokens character > set. So compliant authorization servers could issue tokens, which > cannot be safely passed as URI query parameters. > > Note: As an additional challenge, self-contained tokens can be very > large. So passing them as URI parameter may exceed URL length limits. > > I see the following alternatives to cope with the encoding problem: > > a) Force usage of a URL-safe character set for access and request tokens. > - rather restrictive, will most likely collide with existing token > formats > - does not solve URL length problem > > b) Force base64-URL-safe encoding for all tokens on transit. > - does not solve URL length problem > - significant API change > > c) Authorization servers supporting revocation may additionally issue > a URL-safe token id in the access token response. This id is used to > reference the token in DELETE requests. > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > { > "access_token":"SlAV32hkKG/hhh/&%", > "access_token_id":"234567890", > "expires_in":3600, > "refresh_token":"8xLOxBtZp8&&&#&", > "refresh_token_id":"asdfghjklhgf" > } > > > DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > Note: Since tokens become addressable resources on the authz server, > one could also query or modify token data using a GET/PUT requests > > GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1 > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > HTTP/1.1 200 OK > Content-Type: application/json > Cache-Control: no-store > > { > "scope":"abc", > "issued_on":"08/11/2010", > "last_usage":"08/13/2010" } > > > 2) HTTP Post on dedicated revocation endpoint > > An additional endpoint is used to revoke tokens. The token to be > revoked is sent as request body parameter. > > POST /revocation HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N > > refresh_token=n4E9O119d > > This option requires some support for the client to discover the > revocation endpoint. > > Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest > additional design options. > > regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From beaton@google.com Wed Aug 18 08:55:16 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9613A68A7 for ; Wed, 18 Aug 2010 08:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.191 X-Spam-Level: X-Spam-Status: No, score=-104.191 tagged_above=-999 required=5 tests=[AWL=1.786, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrTatCb67ifu for ; Wed, 18 Aug 2010 08:55:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D282E3A6848 for ; Wed, 18 Aug 2010 08:55:14 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id o7IFtnlC022887 for ; Wed, 18 Aug 2010 08:55:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282146949; bh=3Wm8ECrw+5J1VYE8NCUk7EIikLM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=gi5G1rMMIhaIDlRKnHKsifR8nccqRzEK9vTYTzWWtm158Sug8o9ZJE+/O0N9MHLmu UAsDZJmkL4HoQR/BDFdgA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=OP6rWMNcvkzge7772MGx9RaWsFbVN5ogpDbitRCiMvvUqD7tk2ygB0uJRsW5YBmOG k7NlIMl0I4FFUO2EZ7L9A== Received: from pzk9 (pzk9.prod.google.com [10.243.19.137]) by hpaq2.eem.corp.google.com with ESMTP id o7IFtlY0008968 for ; Wed, 18 Aug 2010 08:55:48 -0700 Received: by pzk9 with SMTP id 9so296655pzk.12 for ; Wed, 18 Aug 2010 08:55:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.174.4 with SMTP id w4mr7230978wfe.264.1282146946110; Wed, 18 Aug 2010 08:55:46 -0700 (PDT) Received: by 10.142.170.17 with HTTP; Wed, 18 Aug 2010 08:55:46 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> Date: Wed, 18 Aug 2010 08:55:46 -0700 Message-ID: From: Brian Eaton To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:55:16 -0000 On Tue, Aug 17, 2010 at 11:36 PM, Mark Nottingham wrote: >> The other reason people get funny with these status codes has to do >> with browser behavior. =A0Sometimes browsers react in funny ways to >> funny HTTP status codes. =A0To be on the safe side, developers tend to >> return an HTTP 200 with whatever they want the user to see. > > Can you give concrete examples, please? What browsers do what exactly, un= der what circumstances? Here's a well-known example: http://malektips.com/internet-explorer-8-disable-friendly-error-messages.ht= ml. Fuzzier stuff is in handling of things like WWW-Authenticate headers on HTTP 200 responses, or 401s with unknown authorization challenges. From jpanzer@google.com Wed Aug 18 09:18:05 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7473A67F9 for ; Wed, 18 Aug 2010 09:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.91 X-Spam-Level: X-Spam-Status: No, score=-105.91 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4x1Ww4yHRzQ for ; Wed, 18 Aug 2010 09:18:04 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CD7BB3A65A6 for ; Wed, 18 Aug 2010 09:18:03 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id o7IGIcL8013999 for ; Wed, 18 Aug 2010 09:18:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282148318; bh=cwgF7beVyw3eivvhSm2914k96JM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=HDsID6SRB5soi87x3G3FmJzSEIapgt/O5Y9QNtg+wN2BvhFtkZjswDSuRLdWEy81m Cxhkv1Mj/qT0VFXtjYN0A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=GLzwOmthVwIXfmBOL+iYBWmlyO5aZVyEUBQT5NRUsiKhQplXXl1E+nrS/mUN8NNT7 JntkeeIJyeVBBPaqDWMcw== Received: from gwb19 (gwb19.prod.google.com [10.200.2.19]) by wpaz37.hot.corp.google.com with ESMTP id o7IGIbYO011079 for ; Wed, 18 Aug 2010 09:18:37 -0700 Received: by gwb19 with SMTP id 19so351819gwb.29 for ; Wed, 18 Aug 2010 09:18:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.87.12 with SMTP id p12mr9607236anl.73.1282148317311; Wed, 18 Aug 2010 09:18:37 -0700 (PDT) Received: by 10.101.126.6 with HTTP; Wed, 18 Aug 2010 09:18:37 -0700 (PDT) In-Reply-To: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> Date: Wed, 18 Aug 2010 09:18:37 -0700 Message-ID: From: John Panzer To: Brian Eaton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:18:05 -0000 For ie silliness, sop is to include a lot of text in the 5xx so it'll show your message instead of its own. I've done lots of www-authenticate with 200's, always heard worries from web engineers, never had a bug report. Ymmv. On Wednesday, August 18, 2010, Brian Eaton wrote: > On Tue, Aug 17, 2010 at 11:36 PM, Mark Nottingham wrote: >>> The other reason people get funny with these status codes has to do >>> with browser behavior. =A0Sometimes browsers react in funny ways to >>> funny HTTP status codes. =A0To be on the safe side, developers tend to >>> return an HTTP 200 with whatever they want the user to see. >> >> Can you give concrete examples, please? What browsers do what exactly, u= nder what circumstances? > > Here's a well-known example: > http://malektips.com/internet-explorer-8-disable-friendly-error-messages.= html. > > Fuzzier stuff is in handling of things like WWW-Authenticate headers > on HTTP 200 responses, or 401s with unknown authorization challenges. > --=20 -- John Panzer / Google jpanzer@google.com / abstractioneer.org / @jpanzer From mnot@mnot.net Wed Aug 18 15:47:21 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7C7D3A687D for ; Wed, 18 Aug 2010 15:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.885 X-Spam-Level: X-Spam-Status: No, score=-104.885 tagged_above=-999 required=5 tests=[AWL=-2.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpfQCj+tIijh for ; Wed, 18 Aug 2010 15:47:20 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 9038B3A677D for ; Wed, 18 Aug 2010 15:47:20 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.248.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id A0F9B509DB; Wed, 18 Aug 2010 18:47:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Thu, 19 Aug 2010 08:47:45 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> To: Brian Eaton X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 22:47:21 -0000 See: http://support.microsoft.com/kb/294807 On 19/08/2010, at 1:55 AM, Brian Eaton wrote: > On Tue, Aug 17, 2010 at 11:36 PM, Mark Nottingham = wrote: >>> The other reason people get funny with these status codes has to do >>> with browser behavior. Sometimes browsers react in funny ways to >>> funny HTTP status codes. To be on the safe side, developers tend to >>> return an HTTP 200 with whatever they want the user to see. >>=20 >> Can you give concrete examples, please? What browsers do what = exactly, under what circumstances? >=20 > Here's a well-known example: > = http://malektips.com/internet-explorer-8-disable-friendly-error-messages.h= tml. >=20 > Fuzzier stuff is in handling of things like WWW-Authenticate headers > on HTTP 200 responses, or 401s with unknown authorization challenges. -- Mark Nottingham http://www.mnot.net/ From hardjono@mit.edu Thu Aug 19 12:41:23 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A19A3A659C for ; Thu, 19 Aug 2010 12:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-2.929, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNqrY4x4OjD7 for ; Thu, 19 Aug 2010 12:41:22 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by core3.amsl.com (Postfix) with ESMTP id 2B8E33A68B6 for ; Thu, 19 Aug 2010 12:41:22 -0700 (PDT) X-AuditID: 12074425-b7cccae000005f17-bc-4c6d88fe410c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-8.mit.edu (Symantec Brightmail Gateway) with SMTP id 0D.08.24343.EF88D6C4; Thu, 19 Aug 2010 15:41:50 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o7JJfufJ020198; Thu, 19 Aug 2010 15:41:56 -0400 Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o7JJfs1v007364; Thu, 19 Aug 2010 15:41:55 -0400 Received: from w92exhub8.exchange.mit.edu (18.7.73.14) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 19 Aug 2010 15:41:30 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub8.exchange.mit.edu ([18.7.73.14]) with mapi; Thu, 19 Aug 2010 15:41:54 -0400 From: Thomas Hardjono To: Brian Campbell Date: Thu, 19 Aug 2010 15:41:53 -0400 Thread-Topic: [OAUTH-WG] SAML profile comments/questions from the SAML people Thread-Index: Acs6WiRY6x7yH44vQvCfhw8Nc2FnKgFe321w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: oauth Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML people X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:41:23 -0000 Hi Brian, Apologies for the late comments (below). __________________________________________ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Campbell > Sent: Thursday, August 12, 2010 4:08 PM > To: Chuck Mortimore > Cc: oauth > Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML > people > ..... > What about the two bullets on AuthnStatement? >=20 > o If the assertion issuer authenticated the subject, the assertion > SHOULD contain a single representing that > authentication event. >=20 > o If the assertion was issued with the intention that the client > act > autonomously on behalf of the subject, an SHOULD > NOT be included. My first reaction on seeing the first bullet is that the assertion MUST (instead of SHOULD) contain a single representing that authentication event. Not sure if this is too strong. Secondly, is it implicit in Oauth-v2-10 that the=20 Authorization Server is able to process=20 XML signatures (xmldsig). I'm presuming that if=20 the Authorization Server can deal with SAML assertions,=20 then it can handle digital signatures. Thanks. /thomas/ From hardjono@mit.edu Thu Aug 19 12:51:33 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C52283A6900 for ; Thu, 19 Aug 2010 12:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.18 X-Spam-Level: X-Spam-Status: No, score=-4.18 tagged_above=-999 required=5 tests=[AWL=-1.582, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCi-HvxeuEhp for ; Thu, 19 Aug 2010 12:51:32 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by core3.amsl.com (Postfix) with ESMTP id 702153A698B for ; Thu, 19 Aug 2010 12:51:32 -0700 (PDT) X-AuditID: 12074423-b7b19ae0000059ef-e3-4c6d8b579c12 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-6.mit.edu (Symantec Brightmail Gateway) with SMTP id D8.24.23023.75B8D6C4; Thu, 19 Aug 2010 15:51:51 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id o7JJq6Fq021219; Thu, 19 Aug 2010 15:52:06 -0400 Received: from w92exedge4.exchange.mit.edu (W92EXEDGE4.EXCHANGE.MIT.EDU [18.7.73.16]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id o7JJq6xa008845; Thu, 19 Aug 2010 15:52:06 -0400 Received: from oc11exhub4.exchange.mit.edu (18.9.3.14) by w92exedge4.exchange.mit.edu (18.7.73.16) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 19 Aug 2010 15:51:38 -0400 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by oc11exhub4.exchange.mit.edu ([18.9.3.14]) with mapi; Thu, 19 Aug 2010 15:52:05 -0400 From: Thomas Hardjono To: Brian Campbell , oauth Date: Thu, 19 Aug 2010 15:52:04 -0400 Thread-Topic: [OAUTH-WG] SAML profile comments/questions from the SAML people Thread-Index: Acs34EEn4vNeZz+NRby6lt941qsNXQH9qdJw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML people X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:51:34 -0000 Again apologies for my late comments. __________________________________________ > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Campbell > Sent: Monday, August 09, 2010 12:30 PM > To: oauth > Subject: [OAUTH-WG] SAML profile comments/questions from the SAML > people >=20 > I received some feedback on the SAML profile from a cross posting on > the OASIS SSTC (SAML) list. Links to the thread topic index are > below[1], if you are interested, but I'll try and summarize the two > primary issues here. >=20 > First, concern was expressed that restricting the assertion to only > allow for a single element was too limiting. > The restriction basically limits the ability of a single assertion to > be issued for use across multiple use-cases/profiles. A good example > is the use-case that Prateek recently brought up in a different thread > on this list[2] where the assertion is delivered to an SP via Web SSO > and then that SP uses that same assertion to acquire an access token > for data services at a 3rd party site. As currently written, > draft-campbell-oauth-saml-00[3], wouldn't allow for that use-case. > I'm starting to think that my attempt at simplification was is indeed > too restrictive. Allowing for more than one will > make the wording in the profile a bit more complicated (as well as > implementing validation) but I think, in the longer term, it's probably > the right thing to do from a spec perspective. At this point I'm > planning on loosening that restriction in the next draft. I'm curious, > however, if anyone has any strong opinions on it one way or the other? I was under the impression that the Oauth use-case was=20 intentionally made to be simple, where the client talks direct to=20 the Authorization Server (not via Web-SSO and the SP,=20 as in the classic SAML use-case). Does Oauth-v2 today allow=20 the Authorization Server to delegate/relegate the actual=20 obtaining of the access token to a 3rd Party? > The second issue involves my assumption and requirement in the profile > that the subject of the assertion be the resource owner. To me, it > seemed like a reasonable and useful constraint that was generally > inline with the spirit of the assertion flow, ... I think there are a large number of SAML-based use cases that=20 can be interestingly "layered" atop OAuth. I guess the question=20 is how complex should we get in Oauth-v2. Perhaps for now you=20 should make the subject of the assertion be the resource owner,=20 to be in-line with the basic Oauth design assumptions. /thomas/ From mnot@mnot.net Thu Aug 19 16:00:29 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09CD63A691A for ; Thu, 19 Aug 2010 16:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.908 X-Spam-Level: X-Spam-Status: No, score=-104.908 tagged_above=-999 required=5 tests=[AWL=-2.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQfxO4kdd+ws for ; Thu, 19 Aug 2010 16:00:28 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id D9D6D3A6899 for ; Thu, 19 Aug 2010 16:00:27 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.102.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3A3DA509DA; Thu, 19 Aug 2010 19:00:55 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Fri, 20 Aug 2010 09:00:55 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> To: OAuth WG X-Mailer: Apple Mail (2.1081) Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 23:00:29 -0000 How fortuitous:=20 = http://blogs.msdn.com/b/ieinternals/archive/2010/08/19/http-error-pages-in= -internet-explorer.aspx=20 On 19/08/2010, at 8:47 AM, Mark Nottingham wrote: > See: > http://support.microsoft.com/kb/294807 >=20 >=20 > On 19/08/2010, at 1:55 AM, Brian Eaton wrote: >=20 >> On Tue, Aug 17, 2010 at 11:36 PM, Mark Nottingham = wrote: >>>> The other reason people get funny with these status codes has to do >>>> with browser behavior. Sometimes browsers react in funny ways to >>>> funny HTTP status codes. To be on the safe side, developers tend = to >>>> return an HTTP 200 with whatever they want the user to see. >>>=20 >>> Can you give concrete examples, please? What browsers do what = exactly, under what circumstances? >>=20 >> Here's a well-known example: >> = http://malektips.com/internet-explorer-8-disable-friendly-error-messages.h= tml. >>=20 >> Fuzzier stuff is in handling of things like WWW-Authenticate headers >> on HTTP 200 responses, or 401s with unknown authorization challenges. >=20 >=20 > -- > Mark Nottingham http://www.mnot.net/ >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Mark Nottingham http://www.mnot.net/ From Axel.Nennker@telekom.de Fri Aug 20 04:19:26 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF333A69D6 for ; Fri, 20 Aug 2010 04:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTpCGGN7JKq3 for ; Fri, 20 Aug 2010 04:19:25 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 63E413A6A7B for ; Fri, 20 Aug 2010 04:19:25 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 20 Aug 2010 13:19:55 +0200 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Aug 2010 13:19:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 13:19:53 +0200 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA304FB3A95@S4DE9JSAAID.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OAUTH-WG] Returning HTTP 200 on Error for JSONP Thread-Index: Acs+8ROc/WRWeeTCQHueXI1suzOgQABaGM9g References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com><4C69B719.3060303@lodderstedt.net><4C6A25F7.8060301@lodderstedt.net><241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> From: To: X-OriginalArrivalTime: 20 Aug 2010 11:19:55.0759 (UTC) FILETIME=[9E050FF0:01CB4059] Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 11:19:26 -0000 http://www.readwriteweb.com/cloud/2010/08/the-new-api-movement-may.php See #10 =20 -Axel From gffletch@aol.com Fri Aug 20 06:09:27 2010 Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E531B3A6768 for ; Fri, 20 Aug 2010 06:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzmV+0z1fjLG for ; Fri, 20 Aug 2010 06:09:20 -0700 (PDT) Received: from imr-db01.mx.aol.com (imr-db01.mx.aol.com [205.188.91.95]) by core3.amsl.com (Postfix) with ESMTP id 193E13A68F1 for ; Fri, 20 Aug 2010 06:09:19 -0700 (PDT) Received: from mtaout-ma02.r1000.mx.aol.com (mtaout-ma02.r1000.mx.aol.com [172.29.41.2]) by imr-db01.mx.aol.com (8.14.1/8.14.1) with ESMTP id o7KD9XEL021927; Fri, 20 Aug 2010 09:09:33 -0400 Received: from palantir.local (unknown [10.172.0.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-ma02.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id E257CE000098; Fri, 20 Aug 2010 09:09:32 -0400 (EDT) Message-ID: <4C6E7E8A.3010107@aol.com> Date: Fri, 20 Aug 2010 09:09:30 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: John Panzer References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com> <4C69B719.3060303@lodderstedt.net> <4C6A25F7.8060301@lodderstedt.net> <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010508080205000208070606" x-aol-global-disposition: G X-AOL-SCOLL-SCORE: 0:2:467328128:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d29024c6e7e8c02c1 X-AOL-IP: 10.172.0.205 Cc: OAuth WG Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 13:09:27 -0000 This is a multi-part message in MIME format. --------------010508080205000208070606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I believe Flash (in the browser) has similar constraints. Don't know about Silverlight. Thanks, George On 8/17/10 10:33 PM, John Panzer wrote: > Is there any legit reason other than jsonp specifically? > > In the wild I mean. > > On Tuesday, August 17, 2010, Brian Eaton wrote: >> On Tue, Aug 17, 2010 at 11:48 AM, David Recordon wrote: >>> Luke's point still holds true of the core spec needing to allow a 200 status >>> code on an error in this scenario. I'd also rather see this as part of the >>> core spec as it reduces the number of things that implementors will need to >>> read for common use cases. >> For the record, I think any implementer that is relying on protected >> resources returning special response codes for any type of OAuth >> protocol issue is probably going to get burned. Variation in >> protected resource behavior has been a consistent problem in OAuth >> 1.0, and I doubt that can change in OAuth 2. >> >> It's tough to get protected resource servers to be consistent; they >> frequently have good reasons (e.g. jsonp) to be inconsistent. >> >> Authorization servers are simpler beasts. >> --------------010508080205000208070606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I believe Flash (in the browser) has similar constraints. Don't know about Silverlight.

Thanks,
George

On 8/17/10 10:33 PM, John Panzer wrote: 
Is there any legit reason other than jsonp specifically?

In the wild I mean.

On Tuesday, August 17, 2010, Brian Eaton <beaton@google.com> wrote:

On Tue, Aug 17, 2010 at 11:48 AM, David Recordon <recordond@gmail.com> wrote:

Luke's point still holds true of the core spec needing to allow a 200 status
code on an error in this scenario. I'd also rather see this as part of the
core spec as it reduces the number of things that implementors will need to
read for common use cases.

For the record, I think any implementer that is relying on protected
resources returning special response codes for any type of OAuth
protocol issue is probably going to get burned.  Variation in
protected resource behavior has been a consistent problem in OAuth
1.0, and I doubt that can change in OAuth 2.

It's tough to get protected resource servers to be consistent; they
frequently have good reasons (e.g. jsonp) to be inconsistent.

Authorization servers are simpler beasts.



    

    

  


--------------010508080205000208070606--

From tonynad@microsoft.com  Fri Aug 20 11:18:47 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA0C3A6B0F for ; Fri, 20 Aug 2010 11:18:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.024
X-Spam-Level: 
X-Spam-Status: No, score=-9.024 tagged_above=-999 required=5 tests=[AWL=-1.575, BAYES_40=-0.185, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWbzwA8t0LYL for ; Fri, 20 Aug 2010 11:18:42 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 0D48F3A6B08 for ; Fri, 20 Aug 2010 11:18:42 -0700 (PDT)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 20 Aug 2010 11:19:16 -0700
Received: from TK5EX14MBXC103.redmond.corp.microsoft.com ([169.254.3.147]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0218.010; Fri, 20 Aug 2010 11:19:16 -0700
From: Anthony Nadalin 
To: Chuck Mortimore , Eran Hammer-Lahav , Brian Campbell 
Thread-Topic: [OAUTH-WG] more than one assertion?
Thread-Index: AQHLN/nn+pWzYl6T5UKTKi41Ej4aj5LakquAgAC9twCAAANjgIADN/wAgAwa+aA=
Date: Fri, 20 Aug 2010 18:19:15 +0000
Message-ID: 
References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.75]
Content-Type: multipart/alternative; boundary="_000_A08279DC79B11C48AD587060CD93977132746E2ATK5EX14MBXC103r_"
MIME-Version: 1.0
Cc: oauth 
Subject: Re: [OAUTH-WG] more than one assertion?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Aug 2010 18:18:47 -0000

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

So the UK Government Gateway project is a concrete use case. The use case f=
or the UK government is that the government has many assertion providers; t=
his is due to both legal and historical reasons. The first assertion provid=
er is UK Department of Works and Pension (DWP), the second one is Departmen=
t of Motor Vehicles and the third is the Department of Revenue (and so on .=
..). A citizen may need and assertion from each one of these government dep=
artments attesting to various things. A person wants a parking permit, so D=
WP and Department of Motor Vehicles are involved; DWP is the authoritative =
source of address and DMV is the authoritative source of vehicle informatio=
n. So in order to obtain a parking permit, I have to live on the street tha=
t I obtain the parking permit for and I also need to own the vehicle for wh=
ich I'm obtaining the parking permit. So these 2 assertions under different=
 subject identifiers would have to be submitted to obtain the parking permi=
t. So there has to be a way to carry the 2 assertions to obtain the token t=
o get the parking permit.


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C=
huck Mortimore
Sent: Thursday, August 12, 2010 10:24 AM
To: Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

Personally, I'd first like to see more concrete use-cases of how multiple a=
ssertions are going to be used in practice.   Tony alluded to some abstract=
 use-cases, but fuller descriptions would probably help everyone out.

-cmort


On 8/10/10 9:15 AM, "Eran Hammer-Lahav"  wrote:
WFM.

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Tuesday, August 10, 2010 9:03 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] more than one assertion?
>
> To be honest, I somehow overlooked that particular text - my mistake and
> apologies. Reading it again, it probably does preclude parameters from
> repeating, however, I can see some room for varied interpretations as to =
if
> that's a strong normative requirement or a looser suggestion about an err=
or
> code that could be used in that circumstance.
>
> Perhaps it could be made more clear by adding some wording about it to th=
e
> end of the first part of sections 3&4 where it says: "Parameters sent wit=
hout
> a value MUST be treated as if they were omitted from the request.  The
> authorization server SHOULD ignore unrecognized request parameters."?
>
> That said, does it make sense to relax the ban on repeating parameters in
> some situations, like for the assertion parameter, to facilitate
> easy encoding of multiple assertions?   Anthony (Tony?) Nadalin
> suggested that multiple assertions might be a common use case and I think
> allowing for that via repeating assertion parameters is a cleaner and mor=
e
> reusable way to do it.
>
> The text at the bottom of section for could say something like:
>
> "Parameters sent without a value MUST be treated as if they were omitted
> from the request.  The authorization server SHOULD ignore unrecognized
> request parameters.  Parameters MUST NOT repeat unless otherwise noted
> in the parameter definition."
>
> Then in 4.1.3. the assertion parameter could be something like this:
>
>   "assertion
>          REQUIRED.  The assertion(s).  This parameter MAY be repeated in =
the
> request,  if more than one
>           assertion is needed for the access grant"
>
>
> Obviously Eran could improve on the actual text but hopefully that gets t=
he
> concept across?
>
>
>
> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
>  wrote:
> > Do we need to clarify 4.3.1 "repeats a parameter" description for
> "invalid_request" error code does not preclude parameters from repeating?
> I'm not sure.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Brian Campbell
> >> Sent: Monday, August 09, 2010 12:34 PM
> >> To: oauth
> >> Subject: [OAUTH-WG] more than one assertion?
> >>
> >> The question of allowing for multiple assertions in the SAML profile
> >> came up recently.  See http://www.ietf.org/mail-
> >> archive/web/oauth/current/msg04068.html and several subsequent
> >> messages in the thread.
> >>
> >> I pushed back on the idea at first due to added complexity.  There
> >> are a number of things that need to be addressed that aren't present
> >> in the single assertion case.   One of the sticker ones, to me, was
> >> how to encode the assertions into the request.   A SAML 
> >> element is a nice container for multiple assertions but using it in
> >> this context seemed awkward at best.  A new schema could be defined
> >> or a special deliminator character could be used but that seems excess=
ive
> and kludgy respectively.
> >>
> >> What about pushing it up into the HTTP layer and allowing for
> >> multiple occurrences of the assertion=3DXXX parameter in the POST body=
?
> >> I don't see anything in core OAuth that would necessarily preclude doi=
ng
> this.
> >>  It seems cleaner and more lightweight than some of the other options.
> >>  And perhaps it could be a more general (not just SAML) method of
> >> sending multiple assertions in a single assertion grant type request?
> >>
> >> It'd look something like this:
> >>
> >>   POST /token.oauth2 HTTP/1.1
> >>   Host: authz.example.net
> >>   Content-Type: application/x-www-form-urlencoded
> >>
> >>    grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%2Fa
> sse
> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st
> >> assertion...]&assertion=3D
> >>    [...2nd assertion...]&assertion=3D[...3nd assertion...]
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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





Re: [OAUTH-WG] more than one assertion?






So the UK Government Gate=
way project is a concrete use case. The use case for the UK government is t=
hat the government has many assertion providers; this is
 due to both legal and historical reasons. The first assertion provider is =
UK Department of Works and Pension (DWP), the second one is Department of M=
otor Vehicles and the third is the Department of Revenue (and so on …=
). A citizen may need and assertion from
 each one of these government departments attesting to various things. A pe=
rson wants a parking permit, so DWP and Department of Motor Vehicles are in=
volved; DWP is the authoritative source of address and DMV is the authorita=
tive source of vehicle information.
 So in order to obtain a parking permit, I have to live on the street that =
I obtain the parking permit for and I also need to own the vehicle for whic=
h I’m obtaining the parking permit. So these 2 assertions under diffe=
rent subject identifiers would have to
 be submitted to obtain the parking permit. So there has to be a way to car=
ry the 2 assertions to obtain the token to get the parking permit.


 <=
/p>

 <=
/p>





From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Chuck Mortimore

Sent: Thursday, August 12, 2010 10:24 AM

To: Eran Hammer-Lahav; Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] more than one assertion?





 


Persona=
lly, I’d first like to see more concrete use-cases of how multiple as=
sertions are going to be used in practice.   Tony alluded to some
 abstract use-cases, but fuller descriptions would probably help everyone o=
ut.



-cmort





On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:


WFM.


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

> From: Brian Campbell [ma=
ilto:bcampbell@pingidentity.com]

> Sent: Tuesday, August 10, 2010 9:03 AM

> To: Eran Hammer-Lahav

> Cc: oauth

> Subject: Re: [OAUTH-WG] more than one assertion?

>

> To be honest, I somehow overlooked that particular text - my mistake a=
nd

> apologies. Reading it again, it probably does preclude parameters from=


> repeating, however, I can see some room for varied interpretations as =
to if

> that's a strong normative requirement or a looser suggestion about an =
error

> code that could be used in that circumstance.

>

> Perhaps it could be made more clear by adding some wording about it to=
 the

> end of the first part of sections 3&4 where it says: "Paramet=
ers sent without

> a value MUST be treated as if they were omitted from the request. &nbs=
p;The

> authorization server SHOULD ignore unrecognized request parameters.&qu=
ot;?

>

> That said, does it make sense to relax the ban on repeating parameters=
 in

> some situations, like for the assertion parameter, to facilitate

> easy encoding of multiple assertions?   Anthony (Tony?) Nada=
lin

> suggested that multiple assertions might be a common use case and I th=
ink

> allowing for that via repeating assertion parameters is a cleaner and =
more

> reusable way to do it.

>

> The text at the bottom of section for could say something like:

>

> "Parameters sent without a value MUST be treated as if they were =
omitted

> from the request.  The authorization server SHOULD ignore unrecog=
nized

> request parameters.  Parameters MUST NOT repeat unless otherwise =
noted

> in the parameter definition."

>

> Then in 4.1.3. the assertion parameter could be something like this:
>

>   "assertion

>          REQUIRED.  =
The assertion(s).  This parameter MAY be repeated in the

> request,  if more than one

>           assertion =
is needed for the access grant"

>

>

> Obviously Eran could improve on the actual text but hopefully that get=
s the

> concept across?

>

>

>

> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav

> <eran@hueniverse.com> wrote:=


> > Do we need to clarify 4.3.1 "repeats a parameter" descr=
iption for

> "invalid_request" error code does not preclude parameters fr=
om repeating?

> I'm not sure.

> >

> > EHL

> >

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

> >> From: oauth-bounces@ietf.o=
rg [mailto:oauth-bounces@ietf=
.org] On

> >> Behalf Of Brian Campbell

> >> Sent: Monday, August 09, 2010 12:34 PM

> >> To: oauth

> >> Subject: [OAUTH-WG] more than one assertion?

> >>

> >> The question of allowing for multiple assertions in the SAML =
profile

> >> came up recently.  See http://www.ietf.org/mail-

> >> archive/web/oauth/current/msg04068.html and several subsequen=
t

> >> messages in the thread.

> >>

> >> I pushed back on the idea at first due to added complexity. &=
nbsp;There

> >> are a number of things that need to be addressed that aren't =
present

> >> in the single assertion case.   One of the sticker ones,=
 to me, was

> >> how to encode the assertions into the request.   A SAML =
<Response>

> >> element is a nice container for multiple assertions but using=
 it in

> >> this context seemed awkward at best.  A new schema could=
 be defined

> >> or a special deliminator character could be used but that see=
ms excessive

> and kludgy respectively.

> >>

> >> What about pushing it up into the HTTP layer and allowing for=


> >> multiple occurrences of the assertion=3DXXX parameter in the =
POST body?

> >> I don't see anything in core OAuth that would necessarily pre=
clude doing

> this.

> >>  It seems cleaner and more lightweight than some of the =
other options.

> >>  And perhaps it could be a more general (not just SAML) =
method of

> >> sending multiple assertions in a single assertion grant type =
request?

> >>

> >> It'd look something like this:

> >>

> >>   POST /token.oauth2 HTTP/1.1

> >>   Host: authz.example.net

> >>   Content-Type: application/x-www-form-urlencoded

> >>

> >>    grant_type=3Dassertion&assertion_type=3Dhttp=
%3A%2F%2Foauth.net%2Fa

> sse

> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=
=3D[...1st

> >> assertion...]&assertion=3D

> >>    [...2nd assertion...]&assertion=3D[...3nd as=
sertion...]

> >> _______________________________________________

> >> OAuth mailing list

> >> OAuth@ietf.org

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

> >

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth






--_000_A08279DC79B11C48AD587060CD93977132746E2ATK5EX14MBXC103r_--

From torsten@lodderstedt.net  Fri Aug 20 11:28:47 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976E23A67FE for ; Fri, 20 Aug 2010 11:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level: 
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QVrA+3k-AHE for ; Fri, 20 Aug 2010 11:28:42 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by core3.amsl.com (Postfix) with ESMTP id 4040D3A695D for ; Fri, 20 Aug 2010 11:28:41 -0700 (PDT)
Received: from [79.253.20.188] (helo=[192.168.71.22]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OmWL2-0000Jz-Gt; Fri, 20 Aug 2010 20:29:12 +0200
Message-ID: <4C6EC97F.1020601@lodderstedt.net>
Date: Fri, 20 Aug 2010 20:29:19 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Anthony Nadalin 
References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET>	 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090607090200050202030909"
X-Df-Sender: torsten@lodderstedt-online.de
Cc: oauth 
Subject: Re: [OAUTH-WG] more than one assertion?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Aug 2010 18:28:47 -0000

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

  What data shall the issued token contain? Different identifiers and 
also information about the different issuing authorities? Is the new 
token's data inherited from the source assertions or are the assertions 
just verified and the token data (incl. identity) are from other sources?

What do you think about the following alternatives?
- issue one access token per assertion and send all tokens to the target 
service
- directly send the assertions to the target service (underlying 
question: what is the benefit of converting assertions into tokens?)

regards,
Torsten.

Am 20.08.2010 20:19, schrieb Anthony Nadalin:
>
> So the UK Government Gateway project is a concrete use case. The use 
> case for the UK government is that the government has many assertion 
> providers; this is due to both legal and historical reasons. The first 
> assertion provider is UK Department of Works and Pension (DWP), the 
> second one is Department of Motor Vehicles and the third is the 
> Department of Revenue (and so on ...). A citizen may need and 
> assertion from each one of these government departments attesting to 
> various things. A person wants a parking permit, so DWP and Department 
> of Motor Vehicles are involved; DWP is the authoritative source of 
> address and DMV is the authoritative source of vehicle information. So 
> in order to obtain a parking permit, I have to live on the street that 
> I obtain the parking permit for and I also need to own the vehicle for 
> which I'm obtaining the parking permit. So these 2 assertions under 
> different subject identifiers would have to be submitted to obtain the 
> parking permit. So there has to be a way to carry the 2 assertions to 
> obtain the token to get the parking permit.
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On 
> Behalf Of *Chuck Mortimore
> *Sent:* Thursday, August 12, 2010 10:24 AM
> *To:* Eran Hammer-Lahav; Brian Campbell
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] more than one assertion?
>
> Personally, I'd first like to see more concrete use-cases of how 
> multiple assertions are going to be used in practice.   Tony alluded 
> to some abstract use-cases, but fuller descriptions would probably 
> help everyone out.
>
> -cmort
>
>
> On 8/10/10 9:15 AM, "Eran Hammer-Lahav"  wrote:
>
> WFM.
>
> > -----Original Message-----
> > From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> > Sent: Tuesday, August 10, 2010 9:03 AM
> > To: Eran Hammer-Lahav
> > Cc: oauth
> > Subject: Re: [OAUTH-WG] more than one assertion?
> >
> > To be honest, I somehow overlooked that particular text - my mistake and
> > apologies. Reading it again, it probably does preclude parameters from
> > repeating, however, I can see some room for varied interpretations as 
> to if
> > that's a strong normative requirement or a looser suggestion about an 
> error
> > code that could be used in that circumstance.
> >
> > Perhaps it could be made more clear by adding some wording about it 
> to the
> > end of the first part of sections 3&4 where it says: "Parameters sent 
> without
> > a value MUST be treated as if they were omitted from the request.  The
> > authorization server SHOULD ignore unrecognized request parameters."?
> >
> > That said, does it make sense to relax the ban on repeating parameters in
> > some situations, like for the assertion parameter, to facilitate
> > easy encoding of multiple assertions?   Anthony (Tony?) Nadalin
> > suggested that multiple assertions might be a common use case and I think
> > allowing for that via repeating assertion parameters is a cleaner and 
> more
> > reusable way to do it.
> >
> > The text at the bottom of section for could say something like:
> >
> > "Parameters sent without a value MUST be treated as if they were omitted
> > from the request.  The authorization server SHOULD ignore unrecognized
> > request parameters.  Parameters MUST NOT repeat unless otherwise noted
> > in the parameter definition."
> >
> > Then in 4.1.3. the assertion parameter could be something like this:
> >
> >   "assertion
> >          REQUIRED.  The assertion(s).  This parameter MAY be repeated 
> in the
> > request,  if more than one
> >           assertion is needed for the access grant"
> >
> >
> > Obviously Eran could improve on the actual text but hopefully that 
> gets the
> > concept across?
> >
> >
> >
> > On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
> >  wrote:
> > > Do we need to clarify 4.3.1 "repeats a parameter" description for
> > "invalid_request" error code does not preclude parameters from repeating?
> > I'm not sure.
> > >
> > > EHL
> > >
> > >> -----Original Message-----
> > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> > >> Behalf Of Brian Campbell
> > >> Sent: Monday, August 09, 2010 12:34 PM
> > >> To: oauth
> > >> Subject: [OAUTH-WG] more than one assertion?
> > >>
> > >> The question of allowing for multiple assertions in the SAML profile
> > >> came up recently.  See http://www.ietf.org/mail-
> > >> archive/web/oauth/current/msg04068.html and several subsequent
> > >> messages in the thread.
> > >>
> > >> I pushed back on the idea at first due to added complexity.  There
> > >> are a number of things that need to be addressed that aren't present
> > >> in the single assertion case.   One of the sticker ones, to me, was
> > >> how to encode the assertions into the request.   A SAML 
> > >> element is a nice container for multiple assertions but using it in
> > >> this context seemed awkward at best.  A new schema could be defined
> > >> or a special deliminator character could be used but that seems 
> excessive
> > and kludgy respectively.
> > >>
> > >> What about pushing it up into the HTTP layer and allowing for
> > >> multiple occurrences of the assertion=XXX parameter in the POST body?
> > >> I don't see anything in core OAuth that would necessarily preclude 
> doing
> > this.
> > >>  It seems cleaner and more lightweight than some of the other options.
> > >>  And perhaps it could be a more general (not just SAML) method of
> > >> sending multiple assertions in a single assertion grant type request?
> > >>
> > >> It'd look something like this:
> > >>
> > >>   POST /token.oauth2 HTTP/1.1
> > >>   Host: authz.example.net
> > >>   Content-Type: application/x-www-form-urlencoded
> > >>
> > >>    grant_type=assertion&assertion_type=http%3A%2F%2Foauth.net%2Fa
> > sse
> > >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=[...1st
> > >> assertion...]&assertion=
> > >>    [...2nd assertion...]&assertion=[...3nd assertion...]
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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



  
    
    
  
  
    What data shall the issued token contain? Different identifiers and
    also information about the different issuing authorities? Is the new
    token's data inherited from the source assertions or are the
    assertions just verified and the token data (incl. identity) are
    from other sources?  

    

    What do you think about the following alternatives?

    - issue one access token per assertion and send all tokens to the
    target service 

    - directly send the assertions to the target service (underlying
    question: what is the benefit of converting assertions into tokens?)

    

    regards,

    Torsten.

    

    Am 20.08.2010 20:19, schrieb Anthony Nadalin:
    

      
      
      Re: [OAUTH-WG] more than one assertion?
      
      

        
So the UK Government Gateway project is a
            concrete use case. The use case for the UK government is
            that the government has many assertion providers; this is
            due to both legal and historical reasons. The first
            assertion provider is UK Department of Works and Pension
            (DWP), the second one is Department of Motor Vehicles and
            the third is the Department of Revenue (and so on …). A
            citizen may need and assertion from each one of these
            government departments attesting to various things. A person
            wants a parking permit, so DWP and Department of Motor
            Vehicles are involved; DWP is the authoritative source of
            address and DMV is the authoritative source of vehicle
            information. So in order to obtain a parking permit, I have
            to live on the street that I obtain the parking permit for
            and I also need to own the vehicle for which I’m obtaining
            the parking permit. So these 2 assertions under different
            subject identifiers would have to be submitted to obtain the
            parking permit. So there has to be a way to carry the 2
            assertions to obtain the token to get the parking permit.

        
 

        
 

        

          

            
From:
                oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
                On Behalf Of Chuck Mortimore

                Sent: Thursday, August 12, 2010 10:24 AM

                To: Eran Hammer-Lahav; Brian Campbell

                Cc: oauth

                Subject: Re: [OAUTH-WG] more than one assertion?

          

        

        
 

        
Personally, I’d first like
            to see more concrete use-cases of how multiple assertions
            are going to be used in practice.   Tony alluded to some
            abstract use-cases, but fuller descriptions would probably
            help everyone out.

            

            -cmort

            

            

            On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <eran@hueniverse.com>
            wrote:

        
WFM.

            

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

            > From: Brian Campbell [mailto:bcampbell@pingidentity.com]

            > Sent: Tuesday, August 10, 2010 9:03 AM

            > To: Eran Hammer-Lahav

            > Cc: oauth

            > Subject: Re: [OAUTH-WG] more than one assertion?

            >

            > To be honest, I somehow overlooked that particular text
            - my mistake and

            > apologies. Reading it again, it probably does preclude
            parameters from

            > repeating, however, I can see some room for varied
            interpretations as to if

            > that's a strong normative requirement or a looser
            suggestion about an error

            > code that could be used in that circumstance.

            >

            > Perhaps it could be made more clear by adding some
            wording about it to the

            > end of the first part of sections 3&4 where it
            says: "Parameters sent without

            > a value MUST be treated as if they were omitted from
            the request.  The

            > authorization server SHOULD ignore unrecognized request
            parameters."?

            >

            > That said, does it make sense to relax the ban on
            repeating parameters in

            > some situations, like for the assertion parameter, to
            facilitate

            > easy encoding of multiple assertions?   Anthony (Tony?)
            Nadalin

            > suggested that multiple assertions might be a common
            use case and I think

            > allowing for that via repeating assertion parameters is
            a cleaner and more

            > reusable way to do it.

            >

            > The text at the bottom of section for could say
            something like:

            >

            > "Parameters sent without a value MUST be treated as if
            they were omitted

            > from the request.  The authorization server SHOULD
            ignore unrecognized

            > request parameters.  Parameters MUST NOT repeat unless
            otherwise noted

            > in the parameter definition."

            >

            > Then in 4.1.3. the assertion parameter could be
            something like this:

            >

            >   "assertion

            >          REQUIRED.  The assertion(s).  This parameter
            MAY be repeated in the

            > request,  if more than one

            >           assertion is needed for the access grant"

            >

            >

            > Obviously Eran could improve on the actual text but
            hopefully that gets the

            > concept across?

            >

            >

            >

            > On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav

            > <eran@hueniverse.com>
            wrote:

            > > Do we need to clarify 4.3.1 "repeats a parameter"
            description for

            > "invalid_request" error code does not preclude
            parameters from repeating?

            > I'm not sure.

            > >

            > > EHL

            > >

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

            > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
            On

            > >> Behalf Of Brian Campbell

            > >> Sent: Monday, August 09, 2010 12:34 PM

            > >> To: oauth

            > >> Subject: [OAUTH-WG] more than one assertion?

            > >>

            > >> The question of allowing for multiple
            assertions in the SAML profile

            > >> came up recently.  See http://www.ietf.org/mail-

            > >> archive/web/oauth/current/msg04068.html and
            several subsequent

            > >> messages in the thread.

            > >>

            > >> I pushed back on the idea at first due to
            added complexity.  There

            > >> are a number of things that need to be
            addressed that aren't present

            > >> in the single assertion case.   One of the
            sticker ones, to me, was

            > >> how to encode the assertions into the request.
              A SAML <Response>

            > >> element is a nice container for multiple
            assertions but using it in

            > >> this context seemed awkward at best.  A new
            schema could be defined

            > >> or a special deliminator character could be
            used but that seems excessive

            > and kludgy respectively.

            > >>

            > >> What about pushing it up into the HTTP layer
            and allowing for

            > >> multiple occurrences of the assertion=XXX
            parameter in the POST body?

            > >> I don't see anything in core OAuth that would
            necessarily preclude doing

            > this.

            > >>  It seems cleaner and more lightweight than
            some of the other options.

            > >>  And perhaps it could be a more general (not
            just SAML) method of

            > >> sending multiple assertions in a single
            assertion grant type request?

            > >>

            > >> It'd look something like this:

            > >>

            > >>   POST /token.oauth2 HTTP/1.1

            > >>   Host: authz.example.net

            > >>   Content-Type:
            application/x-www-form-urlencoded

            > >>

            > >>  
             grant_type=assertion&assertion_type=http%3A%2F%2Foauth.net%2Fa

            > sse

            > >>  
             rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=[...1st

            > >> assertion...]&assertion=

            > >>    [...2nd assertion...]&assertion=[...3nd
            assertion...]

            > >>
            _______________________________________________

            > >> OAuth mailing list

            > >> OAuth@ietf.org

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

            > >

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.org

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

      

      

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


    

    

  


--------------090607090200050202030909--

From zachary.zeltsan@alcatel-lucent.com  Fri Aug 20 14:11:36 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517723A68F2 for ; Fri, 20 Aug 2010 14:11:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.231
X-Spam-Level: 
X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD0JZrXMR0dL for ; Fri, 20 Aug 2010 14:11:29 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 60F243A6846 for ; Fri, 20 Aug 2010 14:11:28 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o7KLBwWV027674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Aug 2010 16:11:58 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o7KLBuEb028913 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 20 Aug 2010 16:11:57 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Fri, 20 Aug 2010 16:11:21 -0500
From: "Zeltsan, Zachary (Zachary)" 
To: "'Anthony Nadalin'" , Chuck Mortimore , Eran Hammer-Lahav , Brian Campbell 
Date: Fri, 20 Aug 2010 16:11:21 -0500
Thread-Topic: [OAUTH-WG] more than one assertion?
Thread-Index: AQHLN/nn+pWzYl6T5UKTKi41Ej4aj5LakquAgAC9twCAAANjgIADN/wAgAwa+aCAADssMA==
Message-ID: <5710F82C0E73B04FA559560098BF95B124FA54AB20@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B124FA54AB20USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Cc: oauth 
Subject: Re: [OAUTH-WG] more than one assertion?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Aug 2010 21:11:36 -0000

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

This is a convincing use in support of the multiple assertions.
My understanding is that in the use case the two assertions provide the dif=
ferent statements of the different issuers regarding the same subject (the =
person seeking a parking permit). Is there a use case that requires multipl=
e assertions regarding different subjects?

Zachary

________________________________
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A=
nthony Nadalin
Sent: Friday, August 20, 2010 2:19 PM
To: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

So the UK Government Gateway project is a concrete use case. The use case f=
or the UK government is that the government has many assertion providers; t=
his is due to both legal and historical reasons. The first assertion provid=
er is UK Department of Works and Pension (DWP), the second one is Departmen=
t of Motor Vehicles and the third is the Department of Revenue (and so on .=
..). A citizen may need and assertion from each one of these government dep=
artments attesting to various things. A person wants a parking permit, so D=
WP and Department of Motor Vehicles are involved; DWP is the authoritative =
source of address and DMV is the authoritative source of vehicle informatio=
n. So in order to obtain a parking permit, I have to live on the street tha=
t I obtain the parking permit for and I also need to own the vehicle for wh=
ich I'm obtaining the parking permit. So these 2 assertions under different=
 subject identifiers would have to be submitted to obtain the parking permi=
t. So there has to be a way to carry the 2 assertions to obtain the token t=
o get the parking permit.


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C=
huck Mortimore
Sent: Thursday, August 12, 2010 10:24 AM
To: Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

Personally, I'd first like to see more concrete use-cases of how multiple a=
ssertions are going to be used in practice.   Tony alluded to some abstract=
 use-cases, but fuller descriptions would probably help everyone out.

-cmort


On 8/10/10 9:15 AM, "Eran Hammer-Lahav"  wrote:
WFM.

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Tuesday, August 10, 2010 9:03 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] more than one assertion?
>
> To be honest, I somehow overlooked that particular text - my mistake and
> apologies. Reading it again, it probably does preclude parameters from
> repeating, however, I can see some room for varied interpretations as to =
if
> that's a strong normative requirement or a looser suggestion about an err=
or
> code that could be used in that circumstance.
>
> Perhaps it could be made more clear by adding some wording about it to th=
e
> end of the first part of sections 3&4 where it says: "Parameters sent wit=
hout
> a value MUST be treated as if they were omitted from the request.  The
> authorization server SHOULD ignore unrecognized request parameters."?
>
> That said, does it make sense to relax the ban on repeating parameters in
> some situations, like for the assertion parameter, to facilitate
> easy encoding of multiple assertions?   Anthony (Tony?) Nadalin
> suggested that multiple assertions might be a common use case and I think
> allowing for that via repeating assertion parameters is a cleaner and mor=
e
> reusable way to do it.
>
> The text at the bottom of section for could say something like:
>
> "Parameters sent without a value MUST be treated as if they were omitted
> from the request.  The authorization server SHOULD ignore unrecognized
> request parameters.  Parameters MUST NOT repeat unless otherwise noted
> in the parameter definition."
>
> Then in 4.1.3. the assertion parameter could be something like this:
>
>   "assertion
>          REQUIRED.  The assertion(s).  This parameter MAY be repeated in =
the
> request,  if more than one
>           assertion is needed for the access grant"
>
>
> Obviously Eran could improve on the actual text but hopefully that gets t=
he
> concept across?
>
>
>
> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
>  wrote:
> > Do we need to clarify 4.3.1 "repeats a parameter" description for
> "invalid_request" error code does not preclude parameters from repeating?
> I'm not sure.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Brian Campbell
> >> Sent: Monday, August 09, 2010 12:34 PM
> >> To: oauth
> >> Subject: [OAUTH-WG] more than one assertion?
> >>
> >> The question of allowing for multiple assertions in the SAML profile
> >> came up recently.  See http://www.ietf.org/mail-
> >> archive/web/oauth/current/msg04068.html and several subsequent
> >> messages in the thread.
> >>
> >> I pushed back on the idea at first due to added complexity.  There
> >> are a number of things that need to be addressed that aren't present
> >> in the single assertion case.   One of the sticker ones, to me, was
> >> how to encode the assertions into the request.   A SAML 
> >> element is a nice container for multiple assertions but using it in
> >> this context seemed awkward at best.  A new schema could be defined
> >> or a special deliminator character could be used but that seems excess=
ive
> and kludgy respectively.
> >>
> >> What about pushing it up into the HTTP layer and allowing for
> >> multiple occurrences of the assertion=3DXXX parameter in the POST body=
?
> >> I don't see anything in core OAuth that would necessarily preclude doi=
ng
> this.
> >>  It seems cleaner and more lightweight than some of the other options.
> >>  And perhaps it could be a more general (not just SAML) method of
> >> sending multiple assertions in a single assertion grant type request?
> >>
> >> It'd look something like this:
> >>
> >>   POST /token.oauth2 HTTP/1.1
> >>   Host: authz.example.net
> >>   Content-Type: application/x-www-form-urlencoded
> >>
> >>    grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%2Fa
> sse
> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st
> >> assertion...]&assertion=3D
> >>    [...2nd assertion...]&assertion=3D[...3nd assertion...]
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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







Re: [OAUTH-WG] more than one assertion?













This is a convincing use in support of=
 the
multiple assertions. 



My understanding is that in the use ca=
se the
two assertions provide the different statements of the different issuers
regarding the same subject (the person seeking a parking permit). Is there =
a
use case that requires multiple assertions regarding different subjects?



 



Zachary



 















From:
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Anthony Nadalin

Sent: Friday, August 20, 201=
0 2:19
PM

To: Chuck Mortimore; Eran
Hammer-Lahav; Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] more=
 than
one assertion?






 



So the UK Gove=
rnment
Gateway project is a concrete use case. The use case for the UK gove=
rnment
is that the government has many assertion providers; this is due to both le=
gal
and historical reasons. The first assertion provider is UK Department of Wo=
rks
and Pension (DWP), the second one is Department of Motor Vehicles and the t=
hird
is the Department of Revenue (and so on …). A citizen may need and
assertion from each one of these government departments attesting to variou=
s
things. A person wants a parking permit, so DWP and Department of Motor
Vehicles are involved; DWP is the authoritative source of address and DMV i=
s
the authoritative source of vehicle information. So in order to obtain a
parking permit, I have to live on the street that I obtain the parking perm=
it
for and I also need to own the vehicle for which I’m obtaining the
parking permit. So these 2 assertions under different subject identifiers w=
ould
have to be submitted to obtain the parking permit. So there has to be a way=
 to
carry the 2 assertions to obtain the token to get the parking permit.<=
/o:p>



 



 









From:
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore

Sent: Thursday, August 12, 2=
010
10:24 AM

To: Eran Hammer-Lahav; Brian
Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] more=
 than
one assertion?









 



Personally,
I’d first like to see more concrete use-cases of how multiple asserti=
ons
are going to be used in practice.   Tony alluded to some abstract
use-cases, but fuller descriptions would probably help everyone out.



-cmort





On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:



WFM.



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

> From: Brian Campbell [ma=
ilto:bcampbell@pingidentity.com]

> Sent: Tuesday, August 10, 2010 9:03 AM

> To: Eran Hammer-Lahav

> Cc: oauth

> Subject: Re: [OAUTH-WG] more than one assertion?

>

> To be honest, I somehow overlooked that particular text - my mistake a=
nd

> apologies. Reading it again, it probably does preclude parameters from=


> repeating, however, I can see some room for varied interpretations as =
to
if

> that's a strong normative requirement or a looser suggestion about an
error

> code that could be used in that circumstance.

>

> Perhaps it could be made more clear by adding some wording about it to=
 the

> end of the first part of sections 3&4 where it says: "Paramet=
ers
sent without

> a value MUST be treated as if they were omitted from the request. &nbs=
p;The

> authorization server SHOULD ignore unrecognized request parameters.&qu=
ot;?

>

> That said, does it make sense to relax the ban on repeating parameters=
 in

> some situations, like for the assertion parameter, to facilitate

> easy encoding of multiple assertions?   Anthony (Tony?) Nada=
lin

> suggested that multiple assertions might be a common use case and I th=
ink

> allowing for that via repeating assertion parameters is a cleaner and =
more

> reusable way to do it.

>

> The text at the bottom of section for could say something like:

>

> "Parameters sent without a value MUST be treated as if they were
omitted

> from the request.  The authorization server SHOULD ignore
unrecognized

> request parameters.  Parameters MUST NOT repeat unless otherwise
noted

> in the parameter definition."

>

> Then in 4.1.3. the assertion parameter could be something like this:
>

>   "assertion

>          REQUIRED.  =
The
assertion(s).  This parameter MAY be repeated in the

> request,  if more than one

>           assertion =
is
needed for the access grant"

>

>

> Obviously Eran could improve on the actual text but hopefully that get=
s
the

> concept across?

>

>

>

> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav

> <eran@hueniverse.com> wrote:=


> > Do we need to clarify 4.3.1 "repeats a parameter"
description for

> "invalid_request" error code does not preclude parameters fr=
om
repeating?

> I'm not sure.

> >

> > EHL

> >

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

> >> From: oauth-bounces@ietf.o=
rg
[mailto:oauth-bounces@ietf.org] On

> >> Behalf Of Brian Campbell

> >> Sent: Monday, August 09, 2010 12:34 PM

> >> To: oauth

> >> Subject: [OAUTH-WG] more than one assertion?

> >>

> >> The question of allowing for multiple assertions in the SAML
profile

> >> came up recently.  See http://www.ietf.org/mail-

> >> archive/web/oauth/current/msg04068.html and several subsequen=
t

> >> messages in the thread.

> >>

> >> I pushed back on the idea at first due to added complexity. &=
nbsp;There

> >> are a number of things that need to be addressed that aren't
present

> >> in the single assertion case.   One of the sticker ones,=
 to
me, was

> >> how to encode the assertions into the request.   A SAML
<Response>

> >> element is a nice container for multiple assertions but using=
 it
in

> >> this context seemed awkward at best.  A new schema could=
 be
defined

> >> or a special deliminator character could be used but that see=
ms
excessive

> and kludgy respectively.

> >>

> >> What about pushing it up into the HTTP layer and allowing for=


> >> multiple occurrences of the assertion=3DXXX parameter in the =
POST
body?

> >> I don't see anything in core OAuth that would necessarily pre=
clude
doing

> this.

> >>  It seems cleaner and more lightweight than some of the
other options.

> >>  And perhaps it could be a more general (not just SAML)
method of

> >> sending multiple assertions in a single assertion grant type
request?

> >>

> >> It'd look something like this:

> >>

> >>   POST /token.oauth2 HTTP/1.1

> >>   Host: authz.example.net

> >>   Content-Type: application/x-www-form-urlencoded

> >>

> >>    grant_type=3Dassertion&assertion_type=3Dhttp=
%3A%2F%2Foauth.net%2Fa

> sse

> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=
=3D[...1st

> >> assertion...]&assertion=3D

> >>    [...2nd assertion...]&assertion=3D[...3nd
assertion...]

> >> _______________________________________________

> >> OAuth mailing list

> >> OAuth@ietf.org

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

> >

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth









--_000_5710F82C0E73B04FA559560098BF95B124FA54AB20USNAVSXCHMBSA_--

From eran@hueniverse.com  Sat Aug 21 22:20:55 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF743A68FC for ; Sat, 21 Aug 2010 22:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.114
X-Spam-Level: 
X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNrm-v0fP6hD for ; Sat, 21 Aug 2010 22:20:44 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A92A23A6781 for ; Sat, 21 Aug 2010 22:20:43 -0700 (PDT)
Received: (qmail 17377 invoked from network); 22 Aug 2010 05:21:16 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Aug 2010 05:21:16 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 21 Aug 2010 22:21:16 -0700
From: Eran Hammer-Lahav 
To: Anthony Nadalin , Chuck Mortimore , Brian Campbell 
Date: Sat, 21 Aug 2010 22:21:35 -0700
Thread-Topic: [OAUTH-WG] more than one assertion?
Thread-Index: AQHLN/nn+pWzYl6T5UKTKi41Ej4aj5LakquAgAC9twCAAANjgIADN/wAgAwa+aCAAlpKMA==
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F2BAA3C@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3F2BAA3CP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: oauth 
Subject: Re: [OAUTH-WG] more than one assertion?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Aug 2010 05:20:56 -0000

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

This is a very interesting use case.

However, it is far from being as well-defined as the single SAML assertion =
flow proposed (and implemented!). Surely, satisfying these requirements goe=
s far beyond being able to include more than one assertion.
At this point I only support additional language that allows assertion exte=
nsions to define the meaning of duplicated parameters (in general, not the =
assertion parameter specifically). When the server sees an access grant typ=
e of assertion and a given assertion type URI, it will know how to deal wit=
h duplication (such as multiple assertions provided as repeated parameters)=
 via the specification defining this assertion type.

Regardless, repeating parameters is simply a bad idea that will certainly l=
ead to problems with existing framework incapable of handling such a confli=
ct.

EHL

From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: Friday, August 20, 2010 11:19 AM
To: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] more than one assertion?

So the UK Government Gateway project is a concrete use case. The use case f=
or the UK government is that the government has many assertion providers; t=
his is due to both legal and historical reasons. The first assertion provid=
er is UK Department of Works and Pension (DWP), the second one is Departmen=
t of Motor Vehicles and the third is the Department of Revenue (and so on .=
..). A citizen may need and assertion from each one of these government dep=
artments attesting to various things. A person wants a parking permit, so D=
WP and Department of Motor Vehicles are involved; DWP is the authoritative =
source of address and DMV is the authoritative source of vehicle informatio=
n. So in order to obtain a parking permit, I have to live on the street tha=
t I obtain the parking permit for and I also need to own the vehicle for wh=
ich I'm obtaining the parking permit. So these 2 assertions under different=
 subject identifiers would have to be submitted to obtain the parking permi=
t. So there has to be a way to carry the 2 assertions to obtain the token t=
o get the parking permit.


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C=
huck Mortimore
Sent: Thursday, August 12, 2010 10:24 AM
To: Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

Personally, I'd first like to see more concrete use-cases of how multiple a=
ssertions are going to be used in practice.   Tony alluded to some abstract=
 use-cases, but fuller descriptions would probably help everyone out.

-cmort


On 8/10/10 9:15 AM, "Eran Hammer-Lahav"  wrote:
WFM.

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Tuesday, August 10, 2010 9:03 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] more than one assertion?
>
> To be honest, I somehow overlooked that particular text - my mistake and
> apologies. Reading it again, it probably does preclude parameters from
> repeating, however, I can see some room for varied interpretations as to =
if
> that's a strong normative requirement or a looser suggestion about an err=
or
> code that could be used in that circumstance.
>
> Perhaps it could be made more clear by adding some wording about it to th=
e
> end of the first part of sections 3&4 where it says: "Parameters sent wit=
hout
> a value MUST be treated as if they were omitted from the request.  The
> authorization server SHOULD ignore unrecognized request parameters."?
>
> That said, does it make sense to relax the ban on repeating parameters in
> some situations, like for the assertion parameter, to facilitate
> easy encoding of multiple assertions?   Anthony (Tony?) Nadalin
> suggested that multiple assertions might be a common use case and I think
> allowing for that via repeating assertion parameters is a cleaner and mor=
e
> reusable way to do it.
>
> The text at the bottom of section for could say something like:
>
> "Parameters sent without a value MUST be treated as if they were omitted
> from the request.  The authorization server SHOULD ignore unrecognized
> request parameters.  Parameters MUST NOT repeat unless otherwise noted
> in the parameter definition."
>
> Then in 4.1.3. the assertion parameter could be something like this:
>
>   "assertion
>          REQUIRED.  The assertion(s).  This parameter MAY be repeated in =
the
> request,  if more than one
>           assertion is needed for the access grant"
>
>
> Obviously Eran could improve on the actual text but hopefully that gets t=
he
> concept across?
>
>
>
> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
>  wrote:
> > Do we need to clarify 4.3.1 "repeats a parameter" description for
> "invalid_request" error code does not preclude parameters from repeating?
> I'm not sure.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Brian Campbell
> >> Sent: Monday, August 09, 2010 12:34 PM
> >> To: oauth
> >> Subject: [OAUTH-WG] more than one assertion?
> >>
> >> The question of allowing for multiple assertions in the SAML profile
> >> came up recently.  See http://www.ietf.org/mail-
> >> archive/web/oauth/current/msg04068.html and several subsequent
> >> messages in the thread.
> >>
> >> I pushed back on the idea at first due to added complexity.  There
> >> are a number of things that need to be addressed that aren't present
> >> in the single assertion case.   One of the sticker ones, to me, was
> >> how to encode the assertions into the request.   A SAML 
> >> element is a nice container for multiple assertions but using it in
> >> this context seemed awkward at best.  A new schema could be defined
> >> or a special deliminator character could be used but that seems excess=
ive
> and kludgy respectively.
> >>
> >> What about pushing it up into the HTTP layer and allowing for
> >> multiple occurrences of the assertion=3DXXX parameter in the POST body=
?
> >> I don't see anything in core OAuth that would necessarily preclude doi=
ng
> this.
> >>  It seems cleaner and more lightweight than some of the other options.
> >>  And perhaps it could be a more general (not just SAML) method of
> >> sending multiple assertions in a single assertion grant type request?
> >>
> >> It'd look something like this:
> >>
> >>   POST /token.oauth2 HTTP/1.1
> >>   Host: authz.example.net
> >>   Content-Type: application/x-www-form-urlencoded
> >>
> >>    grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%2Fa
> sse
> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st
> >> assertion...]&assertion=3D
> >>    [...2nd assertion...]&assertion=3D[...3nd assertion...]
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] more than one assertio=
n?
This is a=
 very interesting use case.
 
However, it is fa=
r from being as well-defined as the single SAML assertion flow proposed (an=
d implemented!). Surely, satisfying these requirements goes far beyond bein=
g able to include more than one assertion.
 
At this=
 point I only support additional language that allows assertion extensions =
to define the meaning of duplicated parameters (in general, not the asserti=
on parameter specifically). When the server sees an access grant type of as=
sertion and a given assertion type URI, it will know how to deal with dupli=
cation (such as multiple assertions provided as repeated parameters) via th=
e specification defining this assertion type.
 
Regardless, repeating parameters is simply a bad idea that will certainly =
lead to problems with existing framework incapable of handling such a confl=
ict.
 
EHL
 
From: Anthony Nadalin [mailto:tonynad@microsoft.c=
om] 
Sent: Friday, August 20, 2010 11:19 AM
To: Chuck M=
ortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subje=
ct: RE: [OAUTH-WG] more than one assertion?
=

 
=

So the UK Government=
 Gateway project is a concrete use case. The use case for the UK government=
 is that the government has many assertion providers; this is due to both l=
egal and historical reasons. The first assertion provider is UK Department =
of Works and Pension (DWP), the second one is Department of Motor Vehicles =
and the third is the Department of Revenue (and so on …). A citizen m=
ay need and assertion from each one of these government departments attesti=
ng to various things. A person wants a parking permit, so DWP and Departmen=
t of Motor Vehicles are involved; DWP is the authoritative source of addres=
s and DMV is the authoritative source of vehicle information. So in order t=
o obtain a parking permit, I have to live on the street that I obtain the p=
arking permit for and I also need to own the vehicle for which I’m ob=
taining the parking permit. So these 2 assertions under different subject i=
dentifiers would have to be submitted to obtain the parking permit. So ther=
e has to be a way to carry the 2 assertions to obtain the token to get the =
parking permit.
 
 
From: oauth-bounces@ietf.org [mailto:=
oauth-bounces@ietf.org] On Behalf Of Chuck Mortimore
Sent:=
 Thursday, August 12, 2010 10:24 AM
To: Eran Hammer-Lahav; Brian =
Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than on=
e assertion?
 
<=
span style=3D'font-size:11.0pt;font-family:"Lucida Grande"'>Personally, I&#=
8217;d first like to see more concrete use-cases of how multiple assertions=
 are going to be used in practice.   Tony alluded to some abstrac=
t use-cases, but fuller descriptions would probably help everyone out.
<=
br>-cmort


On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <=
eran@hueniverse.com> wrote:
WFM.

> -----Original Message----=
-
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Tuesday, August 10,=
 2010 9:03 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subje=
ct: Re: [OAUTH-WG] more than one assertion?
>
> To be honest, I=
 somehow overlooked that particular text - my mistake and
> apologies=
. Reading it again, it probably does preclude parameters from
> repea=
ting, however, I can see some room for varied interpretations as to if
&=
gt; that's a strong normative requirement or a looser suggestion about an e=
rror
> code that could be used in that circumstance.
>
> =
Perhaps it could be made more clear by adding some wording about it to the<=
br>> end of the first part of sections 3&4 where it says: "Para=
meters sent without
> a value MUST be treated as if they were omitted=
 from the request.  The
> authorization server SHOULD ignore unr=
ecognized request parameters."?
>
> That said, does it mak=
e sense to relax the ban on repeating parameters in
> some situations=
, like for the assertion parameter, to facilitate
> easy encoding of =
multiple assertions?   Anthony (Tony?) Nadalin
> suggested =
that multiple assertions might be a common use case and I think
> all=
owing for that via repeating assertion parameters is a cleaner and more
=
> reusable way to do it.
>
> The text at the bottom of secti=
on for could say something like:
>
> "Parameters sent with=
out a value MUST be treated as if they were omitted
> from the reques=
t.  The authorization server SHOULD ignore unrecognized
> reques=
t parameters.  Parameters MUST NOT repeat unless otherwise noted
&g=
t; in the parameter definition."
>
> Then in 4.1.3. the as=
sertion parameter could be something like this:
>
>   =
;"assertion
>         &n=
bsp;REQUIRED.  The assertion(s).  This parameter MAY be repeated =
in the
> request,  if more than one
>    &n=
bsp;      assertion is needed for the access =
grant"
>
>
> Obviously Eran could improve on the act=
ual text but hopefully that gets the
> concept across?
>
>=
;
>
> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
>=
; <eran@hueniverse.com> wrote:> > Do we need to clarify 4.3.1 "repeats a parameter" desc=
ription for
> "invalid_request" error code does not preclud=
e parameters from repeating?
> I'm not sure.
> >
> >=
; EHL
> >
> >> -----Original Message-----
> >=
> From: oauth-bounces@ietf.org [<=
a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]=
 On
> >> Behalf Of Brian Campbell
> >> Sent: Monday=
, August 09, 2010 12:34 PM
> >> To: oauth
> >> Subj=
ect: [OAUTH-WG] more than one assertion?
> >>
> >> =
The question of allowing for multiple assertions in the SAML profile
>=
; >> came up recently.  See http://www.ietf.org/mail-
> >> archive/web/oauth/current/=
msg04068.html and several subsequent
> >> messages in the threa=
d.
> >>
> >> I pushed back on the idea at first due=
 to added complexity.  There
> >> are a number of things t=
hat need to be addressed that aren't present
> >> in the single=
 assertion case.   One of the sticker ones, to me, was
> >>=
; how to encode the assertions into the request.   A SAML <Response=
>
> >> element is a nice container for multiple assertions b=
ut using it in
> >> this context seemed awkward at best.  =
A new schema could be defined
> >> or a special deliminator cha=
racter could be used but that seems excessive
> and kludgy respective=
ly.
> >>
> >> What about pushing it up into the HTT=
P layer and allowing for
> >> multiple occurrences of the asser=
tion=3DXXX parameter in the POST body?
> >> I don't see anythin=
g in core OAuth that would necessarily preclude doing
> this.
>=
 >>  It seems cleaner and more lightweight than some of the othe=
r options.
> >>  And perhaps it could be a more general (n=
ot just SAML) method of
> >> sending multiple assertions in a s=
ingle assertion grant type request?
> >>
> >> It'd =
look something like this:
> >>
> >>   POST /to=
ken.oauth2 HTTP/1.1
> >>   Host: authz.example.net
>=
 >>   Content-Type: application/x-www-form-urlencoded
> &g=
t;>
> >>    grant_type=3Dassertion&assertion_t=
ype=3Dhttp%3A%2F%2Foauth.net%2Fa
> sse
> >>    =
rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st
> >> a=
ssertion...]&assertion=3D
> >>    [...2nd asserti=
on...]&assertion=3D[...3nd assertion...]
> >> _____________=
__________________________________
> >> OAuth mailing list
&=
gt; >> OAuth@ietf.org
> >>=
 https://www.ietf.o=
rg/mailman/listinfo/oauth
> >
_____________________________=
__________________
OAuth mailing list
OAut=
h@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/oauth
<=
/body>=

--_000_90C41DD21FB7C64BB94121FBBC2E72343B3F2BAA3CP3PW5EX1MB01E_--

From sayrer@gmail.com  Mon Aug 23 16:27:42 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707D33A6B48 for ; Mon, 23 Aug 2010 16:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.599
X-Spam-Level: 
X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+LHutuCKlJJ for ; Mon, 23 Aug 2010 16:27:41 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0E2123A68CC for ; Mon, 23 Aug 2010 16:27:35 -0700 (PDT)
Received: by wwe15 with SMTP id 15so683335wwe.13 for ; Mon, 23 Aug 2010 16:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nfZKH+SV2UGhZ+I7QNkb8Kz+mPhJjNdglljdtDeK0hw=; b=NIjYaV18aEe8gdm5poO0FmOtQuGnjlvJfau4zaKgSXORUGPzloVQISGW2RmLl0xlvH TXMSUk8datFFw+YellIC08WykQ7f3I3bcTbjR2MOp9OAp8lGbIRmfDXPnrZ+knBg1tRe W3F4nLoguTlKBTrO6b5drA0Okck08UEUiolSo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OkuT3fbwrCnsa6eqoViMisTYG7BIrxH86Qtj0OiTb+/2u9HfZ402Dks8UImNfAzzwx XgpCcP/ssbqaZrMFs+SymhEoNoaFaauRlcUSxec9kdmw3cQ51PXiXxVXaJOjVv7Xw0NA oxQqit1QGa9vjIfYcgmB9m7JbkKV01WcCzQ2c=
MIME-Version: 1.0
Received: by 10.216.17.194 with SMTP id j44mr5181592wej.68.1282606088889; Mon, 23 Aug 2010 16:28:08 -0700 (PDT)
Received: by 10.216.28.143 with HTTP; Mon, 23 Aug 2010 16:28:08 -0700 (PDT)
In-Reply-To: 
References: <1643FCF1-841F-41FF-B8A8-43269320CFA8@facebook.com>    <4C69B719.3060303@lodderstedt.net>  <4C6A25F7.8060301@lodderstedt.net>  <241FE353-C52A-4505-8620-DEE9CF9F940E@lodderstedt.net>     
Date: Mon, 23 Aug 2010 19:28:08 -0400
Message-ID: 
From: Robert Sayre 
To: OAuth WG 
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [OAUTH-WG] Returning HTTP 200 on Error for JSONP
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Aug 2010 23:27:42 -0000

On Tue, Aug 17, 2010 at 10:33 PM, John Panzer  wrote:
> Is there any legit reason other than jsonp specifically?

The JSONP response doesn't add any value, so it isn't a legitimate
reason anyway.
-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

From sakimura@gmail.com  Tue Aug 24 06:49:23 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6B133A69F9 for ; Tue, 24 Aug 2010 06:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.273
X-Spam-Level: 
X-Spam-Status: No, score=-1.273 tagged_above=-999 required=5 tests=[AWL=-1.275, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vYkocG-vtPr for ; Tue, 24 Aug 2010 06:49:08 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 935493A6A5A for ; Tue, 24 Aug 2010 06:49:08 -0700 (PDT)
Received: by iwn3 with SMTP id 3so7425593iwn.31 for ; Tue, 24 Aug 2010 06:49:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=nv76LfNNBPDTizgsGvY+0b3OA0xBCJsKtUsG61l4qTU=; b=rQ/lDigdQ+NBPwoIOOEfv2ivhxpiDrJA3ZGnVTFU1ErhwyeipQkttvvoPCmLKLKKmE vI2Oj5vhg+fylC766zK4D4zrv3Fw+rQ7s9vpdv4sJt1DMh3UrIYREfIf6SAXMSXqByLp mr97O5heIzPtQT2Hnt3nz0c54bL5yxzd5zhNs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ut0ITfcAih0Qj+5VoVdfE1MfR4sZQ6pq1zwh/KbrgoG1/Orca20dDeRNbyxIZAoNtJ 5TVhdlvPYBq1xQ7kNpMEM4dsV2c6s06tnhlNs/aqGsKOxirYh6hlk/0/Vz2PO+siqmdE a4I0wNw9iVmsUschGWkSfvUkjuA2eAVohACZI=
MIME-Version: 1.0
Received: by 10.231.77.155 with SMTP id g27mr7795265ibk.195.1282657781102; Tue, 24 Aug 2010 06:49:41 -0700 (PDT)
Received: by 10.231.154.7 with HTTP; Tue, 24 Aug 2010 06:49:40 -0700 (PDT)
Date: Tue, 24 Aug 2010 22:49:40 +0900
Message-ID: 
From: Nat Sakimura 
To: oauth 
Content-Type: multipart/mixed; boundary=000e0cd254146939a3048e92094b
Subject: [OAUTH-WG] OAuth Signature Draft Pre 00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Aug 2010 13:49:23 -0000

--000e0cd254146939a3048e92094b
Content-Type: multipart/alternative; boundary=000e0cd2541469399e048e920949

--000e0cd2541469399e048e920949
Content-Type: text/plain; charset=ISO-8859-1

Hi.

It has been a few weeks since then I volunteered to do this work.
I have written up to this pre 00 draft then have been doing some reality
checks on some script languages etc.

No. This pre-00 draft is far from being feature complete.
I still need to copy and paste the Magic Signatures text etc.
Also, I should add how this spec is being used in some of the major flows.

However, since I will not be able to work on it this week, I thought it
would be worthwhile to share this early draft so that you have some clarity
into the progress.

Apparently, Yaron has been working on it as well. We will compare the notes
and try to merge, I hope.

So, here it is!

#For those of you who have seen the private draft, it has not been changed
since July 31.

Best,

=nat

--000e0cd2541469399e048e920949
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi.=A0


It has been a few weeks since then I volunteered to do =
this work.=A0
I have written up to this pre 00 draft then have be=
en doing some reality checks on some script languages etc.=A0


No. This pre-00 draft is far from being feature complete.=A0
I still need to copy and paste the Magic Signatures text etc.=A0
Also, I should add how this spec is being used in some of the major =
flows.=A0



However, since I will not be able to work on it this we=
ek, I thought it would be worthwhile to share this early draft so that you =
have some clarity into the progress.=A0

Apparently=
, Yaron has been working on it as well. We will compare the notes and try t=
o merge, I hope.=A0



So, here it is!=A0

#For those =
of you who have seen the private draft, it has not been changed since July =
31.=A0

Best,=A0

=3Dnat





--000e0cd2541469399e048e920949--
--000e0cd254146939a3048e92094b
Content-Type: text/html; charset=US-ASCII; name="draft-sakimura-oauth-signatures-00.html"
Content-Disposition: attachment; 
	filename="draft-sakimura-oauth-signatures-00.html"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gd8rct2c1

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+DQo8aHRtbCBsYW5n
PSJlbiI+PGhlYWQ+PHRpdGxlPk9BdXRoIFNpZ25hdHVyZXMgMS4wIGRyYWZ0IDAwPC90aXRsZT4N
CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFy
c2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9ImRlc2NyaXB0aW9uIiBjb250ZW50PSJPQXV0aCBTaWdu
YXR1cmVzIDEuMCBkcmFmdCAwMCI+DQo8bWV0YSBuYW1lPSJrZXl3b3JkcyIgY29udGVudD0iU2ln
bmF0dXJlLCBEcmFmdCI+DQo8bWV0YSBuYW1lPSJnZW5lcmF0b3IiIGNvbnRlbnQ9InhtbDJyZmMg
djEuMzUgKGh0dHA6Ly94bWwucmVzb3VyY2Uub3JnLykiPg0KPHN0eWxlIHR5cGU9J3RleHQvY3Nz
Jz48IS0tDQogICAgICAgIGJvZHkgew0KICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiB2ZXJk
YW5hLCBjaGFyY29hbCwgaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZjsNCiAgICAgICAgICAg
ICAgICBmb250LXNpemU6IHNtYWxsOyBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0ZG
RjsNCiAgICAgICAgICAgICAgICBtYXJnaW46IDJlbTsNCiAgICAgICAgfQ0KICAgICAgICBoMSwg
aDIsIGgzLCBoNCwgaDUsIGg2IHsNCiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogaGVsdmV0
aWNhLCBtb25hY28sICJNUyBTYW5zIFNlcmlmIiwgYXJpYWwsIHNhbnMtc2VyaWY7DQogICAgICAg
ICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgICAg
fQ0KICAgICAgICBoMSB7IGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVu
dDsgdGV4dC1hbGlnbjogcmlnaHQ7IH0NCiAgICAgICAgaDMgeyBjb2xvcjogIzMzMzsgYmFja2dy
b3VuZC1jb2xvcjogdHJhbnNwYXJlbnQ7IH0NCg0KICAgICAgICB0ZC5SRkNidWcgew0KICAgICAg
ICAgICAgICAgIGZvbnQtc2l6ZTogeC1zbWFsbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOw0KICAg
ICAgICAgICAgICAgIHdpZHRoOiAzMHB4OyBoZWlnaHQ6IDMwcHg7IHBhZGRpbmctdG9wOiAycHg7
DQogICAgICAgICAgICAgICAgdGV4dC1hbGlnbjoganVzdGlmeTsgdmVydGljYWwtYWxpZ246IG1p
ZGRsZTsNCiAgICAgICAgICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjMDAwOw0KICAgICAgICB9
DQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLlJGQyB7DQogICAgICAgICAgICAgICAgZm9udC1mYW1p
bHk6IG1vbmFjbywgY2hhcmNvYWwsIGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2Es
IHZlcmRhbmEsIHNhbnMtc2VyaWY7DQogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7
IGNvbG9yOiAjNjY2Ow0KICAgICAgICB9DQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLmhvdFRleHQg
ew0KICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiBjaGFyY29hbCwgbW9uYWNvLCBnZW5ldmEs
ICJNUyBTYW5zIFNlcmlmIiwgaGVsdmV0aWNhLCB2ZXJkYW5hLCBzYW5zLXNlcmlmOw0KICAgICAg
ICAgICAgICAgIGZvbnQtd2VpZ2h0OiBub3JtYWw7IHRleHQtYWxpZ246IGNlbnRlcjsgY29sb3I6
ICNGRkY7DQogICAgICAgIH0NCg0KICAgICAgICB0YWJsZS5UT0NidWcgeyB3aWR0aDogMzBweDsg
aGVpZ2h0OiAxNXB4OyB9DQogICAgICAgIHRkLlRPQ2J1ZyB7DQogICAgICAgICAgICAgICAgdGV4
dC1hbGlnbjogY2VudGVyOyB3aWR0aDogMzBweDsgaGVpZ2h0OiAxNXB4Ow0KICAgICAgICAgICAg
ICAgIGNvbG9yOiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjOTAwOw0KICAgICAgICB9DQogICAg
ICAgIHRkLlRPQ2J1ZyBhIHsNCiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogbW9uYWNvLCBj
aGFyY29hbCwgZ2VuZXZhLCAiTVMgU2FucyBTZXJpZiIsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsN
CiAgICAgICAgICAgICAgICBmb250LXdlaWdodDogYm9sZDsgZm9udC1zaXplOiB4LXNtYWxsOyB0
ZXh0LWRlY29yYXRpb246IG5vbmU7DQogICAgICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tn
cm91bmQtY29sb3I6IHRyYW5zcGFyZW50Ow0KICAgICAgICB9DQoNCiAgICAgICAgdGQuaGVhZGVy
IHsNCiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1z
ZXJpZjsgZm9udC1zaXplOiB4LXNtYWxsOw0KICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFsaWdu
OiB0b3A7IHdpZHRoOiAzMyU7DQogICAgICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tncm91
bmQtY29sb3I6ICM2NjY7DQogICAgICAgIH0NCiAgICAgICAgdGQuYXV0aG9yIHsgZm9udC13ZWln
aHQ6IGJvbGQ7IGZvbnQtc2l6ZTogeC1zbWFsbDsgbWFyZ2luLWxlZnQ6IDRlbTsgfQ0KICAgICAg
ICB0ZC5hdXRob3ItdGV4dCB7IGZvbnQtc2l6ZTogeC1zbWFsbDsgfQ0KDQogICAgICAgIC8qIGlu
Zm8gY29kZSBmcm9tIFNhbnRhS2xhdXNzIGF0IGh0dHA6Ly93d3cubWFkYWJvdXRzdHlsZS5jb20v
dG9vbHRpcDIuaHRtbCAqLw0KICAgICAgICBhLmluZm8gew0KICAgICAgICAgICAgICAgIC8qIFRo
aXMgaXMgdGhlIGtleS4gKi8NCiAgICAgICAgICAgICAgICBwb3NpdGlvbjogcmVsYXRpdmU7DQog
ICAgICAgICAgICAgICAgei1pbmRleDogMjQ7DQogICAgICAgICAgICAgICAgdGV4dC1kZWNvcmF0
aW9uOiBub25lOw0KICAgICAgICB9DQogICAgICAgIGEuaW5mbzpob3ZlciB7DQogICAgICAgICAg
ICAgICAgei1pbmRleDogMjU7DQogICAgICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tncm91
bmQtY29sb3I6ICM5MDA7DQogICAgICAgIH0NCiAgICAgICAgYS5pbmZvIHNwYW4geyBkaXNwbGF5
OiBub25lOyB9DQogICAgICAgIGEuaW5mbzpob3ZlciBzcGFuLmluZm8gew0KICAgICAgICAgICAg
ICAgIC8qIFRoZSBzcGFuIHdpbGwgZGlzcGxheSBqdXN0IG9uIDpob3ZlciBzdGF0ZS4gKi8NCiAg
ICAgICAgICAgICAgICBkaXNwbGF5OiBibG9jazsNCiAgICAgICAgICAgICAgICBwb3NpdGlvbjog
YWJzb2x1dGU7DQogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbGVyOw0KICAgICAgICAg
ICAgICAgIHRvcDogMmVtOyBsZWZ0OiAtNWVtOyB3aWR0aDogMTVlbTsNCiAgICAgICAgICAgICAg
ICBwYWRkaW5nOiAycHg7IGJvcmRlcjogMXB4IHNvbGlkICMzMzM7DQogICAgICAgICAgICAgICAg
Y29sb3I6ICM5MDA7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7DQogICAgICAgICAgICAgICAgdGV4
dC1hbGlnbjogbGVmdDsNCiAgICAgICAgfQ0KDQogICAgICAgIGEgeyBmb250LXdlaWdodDogYm9s
ZDsgfQ0KICAgICAgICBhOmxpbmsgICAgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjog
dHJhbnNwYXJlbnQ7IH0NCiAgICAgICAgYTp2aXNpdGVkIHsgY29sb3I6ICM2MzM7IGJhY2tncm91
bmQtY29sb3I6IHRyYW5zcGFyZW50OyB9DQogICAgICAgIGE6YWN0aXZlICB7IGNvbG9yOiAjNjMz
OyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQ0KDQogICAgICAgIHAgeyBtYXJnaW4t
bGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQ0KICAgICAgICBwLmNvcHlyaWdodCB7IGZv
bnQtc2l6ZTogeC1zbWFsbDsgfQ0KICAgICAgICBwLnRvYyB7IGZvbnQtc2l6ZTogc21hbGw7IGZv
bnQtd2VpZ2h0OiBib2xkOyBtYXJnaW4tbGVmdDogM2VtOyB9DQogICAgICAgIHRhYmxlLnRvYyB7
IG1hcmdpbjogMCAwIDAgM2VtOyBwYWRkaW5nOiAwOyBib3JkZXI6IDA7IHZlcnRpY2FsLWFsaWdu
OiB0ZXh0LXRvcDsgfQ0KICAgICAgICB0ZC50b2MgeyBmb250LXNpemU6IHNtYWxsOyBmb250LXdl
aWdodDogYm9sZDsgdmVydGljYWwtYWxpZ246IHRleHQtdG9wOyB9DQoNCiAgICAgICAgb2wudGV4
dCB7IG1hcmdpbi1sZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyB9DQogICAgICAgIHVsLnRl
eHQgeyBtYXJnaW4tbGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQ0KICAgICAgICBsaSAg
ICAgIHsgbWFyZ2luLWxlZnQ6IDNlbTsgfQ0KDQogICAgICAgIC8qIFJGQy0yNjI5IDxzcGFueD5z
IGFuZCA8YXJ0d29yaz5zLiAqLw0KICAgICAgICBlbSAgICAgeyBmb250LXN0eWxlOiBpdGFsaWM7
IH0NCiAgICAgICAgc3Ryb25nIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IH0NCiAgICAgICAgZGZuICAg
IHsgZm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgfQ0KICAgICAgICBjaXRl
ICAgeyBmb250LXdlaWdodDogbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7IH0NCiAgICAgICAg
dHQgICAgIHsgY29sb3I6ICMwMzY7IH0NCiAgICAgICAgdHQsIHByZSwgcHJlIGRmbiwgcHJlIGVt
LCBwcmUgY2l0ZSwgcHJlIHNwYW4gew0KICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiAiQ291
cmllciBOZXciLCBDb3VyaWVyLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogc21hbGw7DQogICAgICAg
IH0NCiAgICAgICAgcHJlIHsNCiAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBsZWZ0OyBwYWRk
aW5nOiA0cHg7DQogICAgICAgICAgICAgICAgY29sb3I6ICMwMDA7IGJhY2tncm91bmQtY29sb3I6
ICNDQ0M7DQogICAgICAgIH0NCiAgICAgICAgcHJlIGRmbiAgeyBjb2xvcjogIzkwMDsgfQ0KICAg
ICAgICBwcmUgZW0gICB7IGNvbG9yOiAjNjZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZDOyBmb250
LXdlaWdodDogbm9ybWFsOyB9DQogICAgICAgIHByZSAua2V5IHsgY29sb3I6ICMzM0M7IGZvbnQt
d2VpZ2h0OiBib2xkOyB9DQogICAgICAgIHByZSAuaWQgIHsgY29sb3I6ICM5MDA7IH0NCiAgICAg
ICAgcHJlIC5zdHIgeyBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0NGRjsgfQ0KICAg
ICAgICBwcmUgLnZhbCB7IGNvbG9yOiAjMDY2OyB9DQogICAgICAgIHByZSAucmVwIHsgY29sb3I6
ICM5MDk7IH0NCiAgICAgICAgcHJlIC5vdGggeyBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xv
cjogI0ZDRjsgfQ0KICAgICAgICBwcmUgLmVyciB7IGJhY2tncm91bmQtY29sb3I6ICNGQ0M7IH0N
Cg0KICAgICAgICAvKiBSRkMtMjYyOSA8dGV4dHRhYmxlPnMuICovDQogICAgICAgIHRhYmxlLmFs
bCwgdGFibGUuZnVsbCwgdGFibGUuaGVhZGVycywgdGFibGUubm9uZSB7DQogICAgICAgICAgICAg
ICAgZm9udC1zaXplOiBzbWFsbDsgdGV4dC1hbGlnbjogY2VudGVyOyBib3JkZXItd2lkdGg6IDJw
eDsNCiAgICAgICAgICAgICAgICB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBib3JkZXItY29sbGFwc2U6
IGNvbGxhcHNlOw0KICAgICAgICB9DQogICAgICAgIHRhYmxlLmFsbCwgdGFibGUuZnVsbCB7IGJv
cmRlci1zdHlsZTogc29saWQ7IGJvcmRlci1jb2xvcjogYmxhY2s7IH0NCiAgICAgICAgdGFibGUu
aGVhZGVycywgdGFibGUubm9uZSB7IGJvcmRlci1zdHlsZTogbm9uZTsgfQ0KICAgICAgICB0aCB7
DQogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGJvcmRlci1jb2xvcjogYmxhY2s7
DQogICAgICAgICAgICAgICAgYm9yZGVyLXdpZHRoOiAycHggMnB4IDNweCAycHg7DQogICAgICAg
IH0NCiAgICAgICAgdGFibGUuYWxsIHRoLCB0YWJsZS5mdWxsIHRoIHsgYm9yZGVyLXN0eWxlOiBz
b2xpZDsgfQ0KICAgICAgICB0YWJsZS5oZWFkZXJzIHRoIHsgYm9yZGVyLXN0eWxlOiBub25lIG5v
bmUgc29saWQgbm9uZTsgfQ0KICAgICAgICB0YWJsZS5ub25lIHRoIHsgYm9yZGVyLXN0eWxlOiBu
b25lOyB9DQogICAgICAgIHRhYmxlLmFsbCB0ZCB7DQogICAgICAgICAgICAgICAgYm9yZGVyLXN0
eWxlOiBzb2xpZDsgYm9yZGVyLWNvbG9yOiAjMzMzOw0KICAgICAgICAgICAgICAgIGJvcmRlci13
aWR0aDogMXB4IDJweDsNCiAgICAgICAgfQ0KICAgICAgICB0YWJsZS5mdWxsIHRkLCB0YWJsZS5o
ZWFkZXJzIHRkLCB0YWJsZS5ub25lIHRkIHsgYm9yZGVyLXN0eWxlOiBub25lOyB9DQoNCiAgICAg
ICAgaHIgeyBoZWlnaHQ6IDFweDsgfQ0KICAgICAgICBoci5pbnNlcnQgew0KICAgICAgICAgICAg
ICAgIHdpZHRoOiA4MCU7IGJvcmRlci1zdHlsZTogbm9uZTsgYm9yZGVyLXdpZHRoOiAwOw0KICAg
ICAgICAgICAgICAgIGNvbG9yOiAjQ0NDOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NDOw0KICAgICAg
ICB9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0
IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJy
aWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJz
cDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0i
NjYlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZD48
dGFibGUgc3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxscGFkZGlu
Zz0iMiIgY2VsbHNwYWNpbmc9IjEiPg0KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5PcGVuIEF1dGhl
bnRpY2F0aW9uIFdvcmtpbmcgR3JvdXA8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5ELiBCYWxmYW56
PC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5JbnRlcm5ldC1EcmFmdDwvdGQ+PHRk
IGNsYXNzPSJoZWFkZXIiPkdvb2dsZTwvdGQ+PC90cj4NCjx0cj48dGQgY2xhc3M9ImhlYWRlciI+
SW50ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsPC90ZD48dGQgY2xhc3M9ImhlYWRlciI+Si4g
QnJhZGxleTwvdGQ+PC90cj4NCjx0cj48dGQgY2xhc3M9ImhlYWRlciI+RXhwaXJlczogRmVicnVh
cnkgMSwgMjAxMTwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPldpbmdhYTwvdGQ+PC90cj4NCjx0cj48
dGQgY2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+Ti4gU2FraW11
cmEgIChFZGl0b3IpPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj4mbmJzcDs8L3Rk
Pjx0ZCBjbGFzcz0iaGVhZGVyIj5Ob211cmEgUmVzZWFyY2ggSW5zdGl0dXRlPC90ZD48L3RyPg0K
PHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj4mbmJzcDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5MLiBT
aGVwaGFyZDwvdGQ+PC90cj4NCjx0cj48dGQgY2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQg
Y2xhc3M9ImhlYWRlciI+UC4gVGFyamFuPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iaGVhZGVy
Ij4mbmJzcDs8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5GYWNlYm9vazwvdGQ+PC90cj4NCjx0cj48
dGQgY2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48dGQgY2xhc3M9ImhlYWRlciI+SnVseSAzMSwg
MjAxMDwvdGQ+PC90cj4NCjwvdGFibGU+PC90ZD48L3RyPjwvdGFibGU+DQo8aDE+PGJyIC8+T0F1
dGggU2lnbmF0dXJlcyAxLjAgZHJhZnQgMDA8YnIgLz5kcmFmdC1zYWtpbXVyYS1vYXV0aC1zaWdu
YXR1cmVzLTAwPC9oMT4NCg0KPGgzPkFic3RyYWN0PC9oMz4NCg0KPHA+VGhpcyBzcGVjaWZpY2F0
aW9uIGRlZmluZXMgc2lnbmluZyBtZWNoYW5pc20gdG8gYmUgdXNlZCBpbiBPQXV0aCAyLjAuIFRo
ZSBPQXV0aCByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIHRvZ2V0aGVyIHdpdGggc2lnbmF0dXJlIHJl
bGF0ZWQgcGFyYW1ldGVycyBhcmUgZW5jb2RlZCBpbnRvIEpTT04gZW52ZWxvcGUgYW5kIHRoZW4g
c2lnbmluZyBhbGdvcml0aG0gaXMgYXBwbGllZCB0byBvYnRhaW4gQmFzZTY0dXJsIGVuY29kZWQg
c2lnbmF0dXJlIHVzaW5nIHNpZ25hdG9yeSdzIGtleS4gVGhlIHJlc3VsdGluZyBzaWduYXR1cmUg
aXMgY29uY2F0ZW5hdGVkIHdpdGggdGhlIEJhc2U2NHVybCBlbmNvZGVkIEpTT04gZW52ZWxvcGUg
dG8gd2hpY2ggdGhlIHNpZ25hdHVyZSBpcyBhcHBsaWVkIGJ5IGEgcGVyaW9kICIuIiBzbyB0aGF0
IGl0IGNvdWxkIGJlIGluY2x1ZGVkIGluIFVSTHMuDQo8L3A+DQo8aDM+UmVxdWlyZW1lbnRzIExh
bmd1YWdlPC9oMz4NCg0KPHA+VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFV
SVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVD
T01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8g
YmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZD
MjExOSc+UkZDIDIxMTk8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QnJhZG5lciwg
Uy4sICZsZHF1bztLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVt
ZW50IExldmVscywmcmRxdW87IE1hcmNoJm5ic3A7MTk5Ny48L3NwYW4+PHNwYW4+KTwvc3Bhbj48
L2E+IFtSRkMyMTE5XS4NCjwvcD4NCjxoMz5TdGF0dXMgb2YgdGhpcyBNZW1vPC9oMz4NCjxwPg0K
VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgIGluIGZ1bGwNCmNvbmZvcm1hbmNlIHdp
dGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQJm5ic3A7NzggYW5kIEJDUCZuYnNwOzc5LjwvcD4NCjxw
Pg0KSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQg
RW5naW5lZXJpbmcNClRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBt
YXkgYWxzbyBkaXN0cmlidXRlDQp3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu
ICBUaGUgbGlzdCBvZiBjdXJyZW50DQpJbnRlcm5ldC1EcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3A+DQo8cD4NCkludGVybmV0LURyYWZ0
cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0K
YW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3Vt
ZW50cyBhdCBhbnkgdGltZS4NCkl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURy
YWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZQ0KdGhlbSBvdGhlciB0aGFuIGFz
ICZsZHF1bzt3b3JrIGluIHByb2dyZXNzLiZyZHF1bzs8L3A+DQo8cD4NClRoaXMgSW50ZXJuZXQt
RHJhZnQgd2lsbCBleHBpcmUgb24gRmVicnVhcnkgMSwgMjAxMS48L3A+DQoNCjxoMz5Db3B5cmln
aHQgTm90aWNlPC9oMz4NCjxwPg0KQ29weXJpZ2h0IChjKSAyMDEwIElFVEYgVHJ1c3QgYW5kIHRo
ZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlDQpkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0
cyByZXNlcnZlZC48L3A+DQo8cD4NClRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzgg
YW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNClByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBE
b2N1bWVudHMNCihodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVj
dCBvbiB0aGUgZGF0ZSBvZg0KcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSBy
ZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQpjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciBy
aWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCnRvIHRoaXMgZG9jdW1lbnQuIENv
ZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCmluY2x1ZGUg
U2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBv
Zg0KdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdh
cnJhbnR5IGFzDQpkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuPC9wPg0K
PGEgbmFtZT0idG9jIj48L2E+PGJyIC8+PGhyIC8+DQo8aDM+VGFibGUgb2YgQ29udGVudHM8L2gz
Pg0KPHAgY2xhc3M9InRvYyI+DQo8YSBocmVmPSIjYW5jaG9yMSI+MS48L2E+Jm5ic3A7DQpEZWZp
bml0aW9uczxiciAvPg0KPGEgaHJlZj0iI2FuY2hvcjIiPjIuPC9hPiZuYnNwOw0KRW52ZWxvcGUg
U3RydWN0dXJlczxiciAvPg0KPGEgaHJlZj0iI2FuY2hvcjMiPjMuPC9hPiZuYnNwOw0KQ3JlYXRp
bmcgU2lnbmF0dXJlPGJyIC8+DQo8YSBocmVmPSIjdmVyaWZpY2F0aW9uIj40LjwvYT4mbmJzcDsN
ClNpZ25hdHVyZSBWZXJpZmljYXRpb248YnIgLz4NCjxhIGhyZWY9IiNkaXNjb3ZlcnkiPjUuPC9h
PiZuYnNwOw0KS2V5IERpc2NvdmVyeSBhbmQgdGhlIFRydXN0PGJyIC8+DQombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDs8YSBocmVmPSIjc2tleSI+NS4xLjwvYT4mbmJzcDsNClNoYXJlZCBrZXkgaW4g
SE1BQy1TSEEyNTY8YnIgLz4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiN4NTA5
Ij41LjIuPC9hPiZuYnNwOw0KWC41MDkgQ2VydGlmaWNhdGVzPGJyIC8+DQo8YSBocmVmPSIjSUFO
QSI+Ni48L2E+Jm5ic3A7DQpJQU5BIENvbnNpZGVyYXRpb25zPGJyIC8+DQo8YSBocmVmPSIjU2Vj
dXJpdHkiPjcuPC9hPiZuYnNwOw0KU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8YnIgLz4NCjxhIGhy
ZWY9IiNBY2tub3dsZWRnZW1lbnRzIj44LjwvYT4mbmJzcDsNCkFja25vd2xlZGdlbWVudHM8YnIg
Lz4NCjxhIGhyZWY9IiNyZmMucmVmZXJlbmNlczEiPjkuPC9hPiZuYnNwOw0KUmVmZXJlbmNlczxi
ciAvPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI3JmYy5yZWZlcmVuY2VzMSI+
OS4xLjwvYT4mbmJzcDsNCk5vcm1hdGl2ZSBSZWZlcmVuY2VzPGJyIC8+DQombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDs8YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMyIj45LjIuPC9hPiZuYnNwOw0KSW5m
b3JtYXRpdmUgUmVmZXJlbmNlczxiciAvPg0KPGEgaHJlZj0iI2FuY2hvcjYiPkFwcGVuZGl4Jm5i
c3A7QS48L2E+Jm5ic3A7DQpBbiBBcHBlbmRpeDxiciAvPg0KPGEgaHJlZj0iI3JmYy5hdXRob3Jz
Ij4mIzE2Nzs8L2E+Jm5ic3A7DQpBdXRob3JzJyBBZGRyZXNzZXM8YnIgLz4NCjwvcD4NCjxiciBj
bGVhcj0iYWxsIiAvPg0KDQo8YSBuYW1lPSJhbmNob3IxIj48L2E+PGJyIC8+PGhyIC8+DQo8dGFi
bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz
PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj
dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMu
c2VjdGlvbi4xIj48L2E+PGgzPjEuJm5ic3A7DQpEZWZpbml0aW9uczwvaDM+DQoNCjxwPg0KPC9w
Pg0KPHA+PC9wPg0KPGJsb2NrcXVvdGUgY2xhc3M9InRleHQiPjxkbD4NCjxkdD5TZXJ2ZXIgRGVz
Y3JpcHRvcnM8L2R0Pg0KPGRkPkEgc2VydmVyIGRlc2NyaXB0b3IgaXMgYSBodHRwcyBvciBodHRw
IFVSTC4gVGhpcyBVUkwgcmVzb2x2ZXMgdG8gYSBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyB0aGUg
c2VydmVyIChzdWNoIGFzIGtleXMgdXNlZCB0byBzaWduIHJlcXVlc3RzIG9yIHRva2VucywgbG9j
YXRpb24gb2YgY2VydGFpbiBlbmRwb2ludHMsIGV0Yy4pLg0KPC9kZD4NCjxkdD5TaWduYXR1cmU8
L2R0Pg0KPGRkPkEgZGlnaXRhbCBzaWduYXR1cmUgdGhhdCBwcm92YWJseSBiaW5kcyBhIG1lc3Nh
Z2UgdG8gYSBzaWduZXIncyBrZXlwYWlyIG9yIEhhc2gtYmFzZWQgTWVzc2FnZSBBdXRoZW50aWNh
dGlvbiBDb2RlIHRoYXQgY2FuIGJlIHVzZWQgdG8gdmVyaWZ5IGJvdGggdGhlIGRhdGEgaW50ZWdy
aXR5IGFuZCB0aGUgYXV0aGVudGljaXR5IG9mIGEgbWVzc2FnZS4NCjwvZGQ+DQo8ZHQ+U2lnbmVy
PC9kdD4NCjxkZD5JbiB0aGlzIHNwZWNpZmljYXRpb24sIGFuIGFyYml0cmFyeSBpZGVudGlmaWVy
IGFzc29jaWF0ZWQgd2l0aCBhIGtleSB1c2VkIGluIGEgc2lnbmF0dXJlLg0KPC9kZD4NCjxkdD5C
YXNlNjR1cmwgRW5jb2Rpbmc8L2R0Pg0KPGRkPlRoZSBVUkwgYW5kIEZpbGVuYW1lIHNhZmUgdmFy
aWFudCBvZiB0aGUgYmFzZTY0IGVuY29kaW5nIGFzIGRlc2NyaWJlZCBpbiA8YSBjbGFzcz0naW5m
bycgaHJlZj0nI1JGQzQ2NDgnPlJGQzQ2NDg8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m
byc+Sm9zZWZzc29uLCBTLiwgJmxkcXVvO1RoZSBCYXNlMTYsIEJhc2UzMiwgYW5kIEJhc2U2NCBE
YXRhIEVuY29kaW5ncywmcmRxdW87IE9jdG9iZXImbmJzcDsyMDA2Ljwvc3Bhbj48c3Bhbj4pPC9z
cGFuPjwvYT4gW1JGQzQ2NDhdLCBzZWN0aW9uIDUuDQo8L2RkPg0KPGR0PkhNQUMtU0hBMjU2PC9k
dD4NCjxkZD5IYXNoLWJhc2VkIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZSB1c2luZyBTSEEt
MjU2IGFzIHRoZSBoYXNoIGZ1bmN0aW9uLg0KPC9kZD4NCjxkdD5SU0EtU0hBMjU2PC9kdD4NCjxk
ZD5SU0FTU0EtUEtDUzEtdjFfNSBzaWduYXR1cmUgYWxnb3JpdGhtIGZyb20gPGEgY2xhc3M9J2lu
Zm8nIGhyZWY9JyNSRkMzNDQ3Jz5SRkMzNDQ3PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2lu
Zm8nPkpvbnNzb24sIEouIGFuZCBCLiBLYWxpc2tpLCAmbGRxdW87UHVibGljLUtleSBDcnlwdG9n
cmFwaHkgU3RhbmRhcmRzIChQS0NTKSAjMTogUlNBIENyeXB0b2dyYXBoeSBTcGVjaWZpY2F0aW9u
cyBWZXJzaW9uIDIuMSwmcmRxdW87IEZlYnJ1YXJ5Jm5ic3A7MjAwMy48L3NwYW4+PHNwYW4+KTwv
c3Bhbj48L2E+IFtSRkMzNDQ3XSBzZWN0aW9uIDguMiwgYWxzbyBrbm93biBhcyBQS0NTIzEsIHVz
aW5nIFNIQS0yNTYgYXMgdGhlIGhhc2ggZnVuY3Rpb24gZm9yIEVNU0EtUEtDUzEtdjFfNS4NCjwv
ZGQ+DQo8L2RsPjwvYmxvY2txdW90ZT4NCg0KPGEgbmFtZT0iYW5jaG9yMiI+PC9hPjxiciAvPjxo
ciAvPg0KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n
PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+
PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0KPGEg
bmFtZT0icmZjLnNlY3Rpb24uMiI+PC9hPjxoMz4yLiZuYnNwOw0KRW52ZWxvcGUgU3RydWN0dXJl
czwvaDM+DQoNCjxwPk9BdXRoIFNpZ25hdHVyZSBFbnZlbG9wZSBpcyBhIEpTT04gb2JqZWN0IHRo
YXQgY29udGFpbnMgZm9sbG93aW5nIGZpZWxkcy4gTm90ZSB0aGF0IG1vc3Qgb2YgdGhlbSBhcmUg
T1BUSU9OQUwuDQo8L3A+DQo8cD48L3A+DQo8dWwgY2xhc3M9InRleHQiPg0KPGxpPmFsZ29yaXRo
bSAtIEEgU3RyaW5nIHRoYXQgaWRlbnRpZmllcyB0aGUgYWxnb3JpdGhtIHVzZWQuIFRoaXMgc3Bl
Y2lmaWNhdGlvbiBkZWZpbmVzIHRoZSBmb2xsb3dpbmc6ICJITUFDLVNIQTI1NiIsICJSU0EtU0hB
MjU2Ii4NCjwvbGk+DQo8bGk+c2lnbmVyIC0gT1BUSU9OQUwuIEEgc3RyaW5nIHRoYXQgYWxsb3dz
IHRoZSB2ZXJpZmllciB0byBkZXRlcm1pbmUgdGhlIHNlcnZlciBkZXNjcmlwdG9yIG9mIHRoZSBT
aWduZXIuIFRoaXMgY291bGQgYmUgdGhlIHNlcnZlciBkZXNjcmlwdG9yIGl0c2VsZiwgb3Igc29t
ZSBmb3JtIG9mIGlkZW50aWZpZXIsIHdoaWNoIHRoZSB2ZXJpZmllciBjYW4gbWFwIHRvIGEgc2Vy
dmVyIGRlc2NyaXB0b3IuDQo8L2xpPg0KPGxpPmtleWlkIC0gT1BUSU9OQUwuIEEgU3RyaW5nIHRo
YXQgaWRlbnRpZmllcyB0aGUga2V5IHRoYXQgd2FzIHVzZWQgdG8gc2lnbi4NCjwvbGk+DQo8bGk+
bm90X2JlZm9yZSAtIE9QVElPTkFMLiBBbiBpbnRlZ2VyIHRoYXQgcmVwcmVzZW50cyB3aGVuIGRv
ZXMgdGhpcyBzaWduYXR1cmUgYmVjb21lcyB2YWxpZCAoc2Vjb25kcyBzaW5jZSBtaWRuaWdodCAx
LzEvMTk3MCB6dWx1KS4NCjwvbGk+DQo8bGk+bm90X2FmdGVyIC0gT1BUSU9OQUwuIEFuIGludGVn
ZXIgdGhhdCByZXByZXNlbnRzIHdoZW4gZG9lcyB0aGlzIHNpZ25hdHVyZSBleHBpcmVzIChzZWNv
bmRzIHNpbmNlIG1pZG5pZ2h0IDEvMS8xOTcwIHp1bHUpLg0KPC9saT4NCjxsaT5hdWRpZW5jZSAt
IE9QVElPTkFMLiBUaGUgYXVkaWVuY2UgZm9yIHRoaXMgdG9rZW4uIFRoZSBwcmVjaXNlIHNlbWFu
dGljcyBvZiB0aGlzIGZpZWxkLCBhbmQgaG93IGl0IGlzIHZhbGlkYXRlZCwgZGVwZW5kcyBvbiB0
aGUgYXBwbGljYXRpb24uDQo8L2xpPg0KPGxpPm1ldGhvZCAtIE9QVElPTkFMLiBBIFN0cmluZyB0
aGF0IHJlcHJlc2VudHMgdGhlIEhUVFAgbWV0aG9kIHVzZWQgdG8gZXhlY3V0ZSB0aGUgSFRUUCBy
ZXF1ZXN0Lg0KPC9saT4NCjxsaT5ub25jZSAtIE9QVElPTkFMLiBBIHN0cmluZyB0aGF0IGlzIHVz
ZWQgdG8gcHJldmVudCByZXBsYXkgYXR0YWNrcy4gUmVjZWl2ZXJzIG9mIE9BdXRoMiBTaWduZWQg
VG9rZW4gbWF5IHZlcmlmeSB0aGF0IG5vbmNlcyBoYXZlIG5vdCBiZWVuIHByZXZpb3VzbHkgdXNl
ZCB3aXRoaW4gYSByZWFzb25hYmxlIGludGVydmFsLg0KPC9saT4NCjxsaT5ib2R5aGFzaCAtIE9Q
VElPTkFMLiBBIGJhc2U2NHVybCBlbmNvZGVkIHN0cmluZyBvZiBoYXNoIG9mIHRoZSByZXF1ZXN0
IGJvZHkuIFdoaWNoIGhhc2ggYWxnb3JpdGhtIGlzIHVzZWQgZGVwZW5kcyBvbiB0aGUgc2lnbmF0
dXJlIGFsZ29yaXRobSBzcGVjaWZpZWQgaW4gdGhlIHBheWxvYWQuDQo8L2xpPg0KPGxpPm9hdXRo
X3Rva2VuIC0gT1BUSU9OQUwuIEEgc3RyaW5nIHRoYXQgcmVwcmVzZW50cyBPQXV0aCBUb2tlbi4N
CjwvbGk+DQo8bGk+Y2VydHNfdXJpIC0gT1BUSU9OQUwuIEFuIFVSSSB0aGF0IHBvaW50cyB0byB0
aGUgWC41MDkgcHVibGljIGtleSBjZXJ0aWZpY2F0ZXMgdGhhdCBjYW4gYmUgdXNlZCB0byB2ZXJp
ZnkgdGhlIHNpZ25hdHVyZS4NCjwvbGk+DQo8bGk+dHlwZSAtIE9QVElPTkFMLiBUaGUgU3RyaW5n
ICJvYXV0aC1zaWciIHRoYXQgc2lnbmlmeSB0aGF0IHRoZSB0eXBlIG9mIHRoaXMgSlNPTiBvYmpl
Y3QuDQo8L2xpPg0KPC91bD4NCg0KPHA+VGhlIEVudmVsb3BlIE1BWSBjb250YWluIGFueSBvdGhl
ciBmaWVsZHMgb2YgYXJiaXRyYXJ5IHR5cGVzLCBpbiB3aGljaCBjYXNlIHRoZSBrZXlzIE1VU1Qg
Tk9UIGNvbGxpZWQgd2l0aCB0aGUgZmllbGRzIGRlZmluZWQgYWJvdmUuDQo8L3A+DQo8cD5Gb2xs
b3dpbmcgaXMgYSBub24tbm9ybWF0aXZlIGV4YW1wbGUgb2Ygc3VjaCBlbnZlbG9wZSBmb3IgSE1B
Qy1TSEEyNTYNCjwvcD48ZGl2IHN0eWxlPSdkaXNwbGF5OiB0YWJsZTsgd2lkdGg6IDA7IG1hcmdp
bi1sZWZ0OiAzZW07IG1hcmdpbi1yaWdodDogYXV0byc+PHByZT57DQogICAgImFsZ29yaXRobSI6
IkhNQUMtU0hBMjU2IiwNCiAgICAib2F1dGhfdG9rZW4iOiJhc2Rmamtsc2RmandvSWpmayIsDQog
ICAgIm5vdF9hZnRlciI6MTIzNDU2NzgsDQogICAgInVzZXJfaWQiOjEyMjMsDQogICAgInByb2Zp
bGVfaWQiOjEyMjMNCn0NCg0KPC9wcmU+PC9kaXY+DQo8cD4NCjwvcD4NCjxwPkZvbGxvd2luZyBp
cyBhIG5vbi1ub3JtYXRpdmUgZXhhbXBsZSBvZiBzdWNoIGVudmVsb3BlIGZvciBSU0EtU0hBMjU2
DQo8L3A+PGRpdiBzdHlsZT0nZGlzcGxheTogdGFibGU7IHdpZHRoOiAwOyBtYXJnaW4tbGVmdDog
M2VtOyBtYXJnaW4tcmlnaHQ6IGF1dG8nPjxwcmU+ew0KICAgICJhbGdvcml0aG0iOiJSU0EtU0hB
MjU2IiwNCiAgICAic2lnbmVyIjoiZXhhbXBsZS5jb20iLA0KICAgICJhdWRpZW5jZSI6Imh0dHBz
Oi8vZXhhbXBsZS1jbGllbnQuY29tL3JlZGlyZWN0X3VyaSIsDQogICAgImNlcnRzX3VyaSI6Imh0
dHA6Ly9leGFtcGxlLmNvbS9teWNlcnRzLnBlbSIsDQogICAgIm9hdXRoX3Rva2VuIjoiYXNkZmpr
bHNkZmp3b0lqZmsiLA0KICAgICJub3RfYWZ0ZXIiOjEyMzQ1Njc4LA0KICAgICJ1c2VyX2lkIjoi
MTIyMyIsDQogICAgInByb2ZpbGVfaWQiOiIxMjIzIg0KfQ0KDQo8L3ByZT48L2Rpdj4NCjxwPg0K
PC9wPg0KPHA+DQo8L3A+DQo8YSBuYW1lPSJhbmNob3IzIj48L2E+PGJyIC8+PGhyIC8+DQo8dGFi
bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz
PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj
dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMu
c2VjdGlvbi4zIj48L2E+PGgzPjMuJm5ic3A7DQpDcmVhdGluZyBTaWduYXR1cmU8L2gzPg0KDQo8
cD5UaGUgYmFzaWMgc3RlcHMgb2YgY3JlYXRpbmcgdGhlIHN0cmluZyB3aXRoIHRoZSBzaWduYXR1
cmUgaXMgYXMgZm9sbG93czoNCjwvcD4NCjxwPjwvcD4NCjxvbCBjbGFzcz0idGV4dCI+DQo8bGk+
QmFzZTY0dXJsIGVuY29kZSB0aGUgZW52ZWxvcGUgdG8gb2J0YWluIHRoZSAicGF5bG9hZCIuDQo8
L2xpPg0KPGxpPkFwcGx5IHNpZ25hdHVyZSBvdmVyIHRoZSAicGF5bG9hZCIgYnkgdGhlIHNwZWNp
ZmllZCBhbGdvcml0aG0gdG8gb2J0YWluIHRoZSBzaWduYXR1cmUuDQo8L2xpPg0KPGxpPkJhc2U2
NHVybCBlbmNvZGUgdGhlIHNpZ25hdHVyZSB0byBvYnRhaW4gdGhlICJzaWduYXR1cmUgc3RyaW5n
Ii4NCjwvbGk+DQo8bGk+Q29uY2F0ZW5hdGUgdGhlICJzaWduYXR1cmUgc3RyaW5nIiBhbmQgdGhl
ICJwYXlsb2FkIiB3aXRoIGEgcGVyaW9kICIuIihBU0NJSSAweDJFKS4gVGhpcyBzdHJpbmcgaXMg
Y2FsbGVkICJKU09OIFRva2VuIi4NCjwvbGk+DQo8L29sPg0KPHA+PHA+TGluZSBicmVha3MgYXJl
IGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkuIA0KPC9wPjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRh
YmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJl
PnZsWGd1NjRCUUdGU1FyWTBaY0pCWkFTTXZZdlRIdTlHUTBZTTlyalBTc28NCi4NCmV5SmhiR2R2
Y21sMGFHMGlPaUpJVFVGRExWTklRVEkxTmlJc0lqQWlPaUp3WVhsc2IyRmtJbjANCjwvcHJlPjwv
ZGl2Pg0KPHA+DQo8L3A+DQoNCjxhIG5hbWU9InZlcmlmaWNhdGlvbiI+PC9hPjxiciAvPjxociAv
Pg0KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIy
IiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEg
aHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0KPGEgbmFt
ZT0icmZjLnNlY3Rpb24uNCI+PC9hPjxoMz40LiZuYnNwOw0KU2lnbmF0dXJlIFZlcmlmaWNhdGlv
bjwvaDM+DQoNCjxwPlRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlLCB0aGUgdmVyaWZpZXIgTVVTVCBo
YXZlIGFuIGFjY2VzcyB0byBhIHRydXN0ZWQgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBrZXkuIFRy
dXN0ZWQga2V5IE1BWSBCRSBlc3RhYmxpc2hlZCBpbiB0aGUgZm9sbG93aW5nIHdheXM6DQo8L3A+
DQo8cD48L3A+DQo8b2wgY2xhc3M9InRleHQiPg0KPGxpPklmIHRoZSBrZXkgaXMgdGhlIHNoYXJl
ZCBrZXkgaW4gSE1BQy1TSEEyNTYsIHRoZSBrZXkgTVVTVCBCRSB0aGUgY2xpZW50X3NlY3JldCBk
ZWZpbmVkIGluIHRoZSBPQXV0aCAyLjAgc3BlY2lmaWNhdGlvbi4NCjwvbGk+DQo8bGk+SWYgdGhl
IGtleSBpcyBSU0Ega2V5IGRlZmluZWQgaW4gWC41MDkgc2VsZi1zaWduZWQgY2VydGlmaWNhdGUs
IHRoZSBrZXkgTVVTVCBiZSBvYnRhaW5lZCB0aHJvdWdoIHRoZSBEaXNjb3ZlcnkgbWVjaGFuaXNt
IGRlZmluZWQgaW4gU2VjdGlvbiA1Lg0KPC9saT4NCjwvb2w+DQoNCjxwPlRoZSB2ZXJpZmljYXRp
b24gaW52b2x2ZXMgdGhlIGZvbGxvd2luZyBzdGVwczogPC9wPg0KPG9sIGNsYXNzPSJ0ZXh0Ij4N
CjxsaT5TcGxpdCB0aGUgSlNPTiBUb2tlbiBieSBhIHBlcmlvZCAiLiIoQVNDSUkgMHgyRSkgdG8g
b2J0YWluIHRoZSBzaWduYXR1cmUgYW5kIHRoZSBwYXlsb2FkLg0KPC9saT4NCjxsaT5CYXNlNjR1
cmwgZGVjb2RlIGJvdGggdGhlICJzaWduYXR1cmUgc3RyaW5nIiBhbmQgdGhlICJwYXlsb2FkIiB0
byBvYnRhaW4gdGhlIHNpZ25hdHVyZSBhbmQgdGhlIGVudmVsb3BlIHJlc3BlY3RpdmVseS4NCjwv
bGk+DQo8bGk+SWYgdGhlIGFsZ29yaXRobSBpcyAiSE1BQy1TSEEyNTYiLCBjYWxjdWxhdGUgdGhl
IHNpZ25hdHVyZSBmcm9tIHRoZSBwYXlsb2FkIHVzaW5nIHRoZSBjbGllbnRfc2VjcmV0LiBJZiB0
aGUgYWxnb3JpdGhtIGlzICJSU0EtU0hBMjU2IiwgdGhlbiB1c2UgUlNBU1NBLVBLQ1MxLXYxXzUg
dmVyaWZpY2F0aW9uIGFsZ29yaXRobSBmcm9tIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDMzQ0
Nyc+UkZDMzQ0NzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Kb25zc29uLCBKLiBh
bmQgQi4gS2FsaXNraSwgJmxkcXVvO1B1YmxpYy1LZXkgQ3J5cHRvZ3JhcGh5IFN0YW5kYXJkcyAo
UEtDUykgIzE6IFJTQSBDcnlwdG9ncmFwaHkgU3BlY2lmaWNhdGlvbnMgVmVyc2lvbiAyLjEsJnJk
cXVvOyBGZWJydWFyeSZuYnNwOzIwMDMuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDMzQ0
N10gc2VjdGlvbiA4LjIuMS4gdG8gdmVyaWZ5IHRoZSBTaWduYXR1cmUuDQo8L2xpPg0KPGxpPklm
IHRoZSBub3RfYmVmb3JlIGZpZWxkIGlzIHNwZWNpZmllZCwgdmVyaWZ5IHRoYXQgdGhlIGN1cnJl
bnQgdGltZSBpcyBub3QgYmVmb3JlIHRoZSBub3RfYmVmb3JlIHRpbWVzdGFtcCBpbiB0aGUgcGF5
bG9hZCwgYW5kIHRoYXQgdGhlIGN1cnJlbnQgdGltZSBpcyBub3QgYWZ0ZXIgdGhlIGV4cGlyYXRp
b24gdGltZSBvZiB0aGUgdG9rZW4gKGRlZmluZWQgYXMgbm90X2JlZm9yZSArIHRva2VuX2xpZmV0
aW1lKS4gVGhlIHZlcmlmaWVyIFNIT1VMRCBiZSBsZW5pZW50IGFuZCBhbnRpY2lwYXRlIHNvbWUg
Y2xvY2sgc2tldyBvbiB0aGUgaXNzdWVyJ3Mgc2lkZS4NCjwvbGk+DQo8bGk+SWYgdGhlIGF1ZGll
bmNlIGZpZWxkIGlzIHNwZWNpZmllZCwgdmVyaWZ5IHRoZSBhdWRpZW5jZSBmaWVsZCBpbiBhbiBh
cHBsaWNhdGlvbi1kZXBlbmRlbnQgbWFubmVyLg0KPC9saT4NCjxsaT5JZiB0aGUgbWV0aG9kIGZp
ZWxkIGlzIHNwZWNpZmllZCwgdmVyaWZ5IHRoYXQgdGhlIG1ldGhvZCBpbiB0aGUgdG9rZW4gcGF5
bG9hZCBlcXVhbHMgdGhlIG1ldGhvZCB1c2VkIHRvIGFjY2VzcyB0aGUgSFRUUCByZXNvdXJjZQ0K
PC9saT4NCjxsaT5JZiB0aGUgYXVkaWVuY2UgZmllbGQgaXMgc3BlY2lmaWVkLCB2ZXJpZnkgdGhh
dCB0aGUgYXVkaWVuY2UgaW4gdGhlIHRva2VuIHBheWxvYWQgbWF0Y2hlcyB0aGUgVVJJIHVzZWQg
dG8gYWNjZXNzIHRoZSBIVFRQIHJlc291cmNlLg0KPC9saT4NCjxsaT5JZiB0aGUgbm9uY2UgaXMg
c3BlY2lmaWVkLCB2ZXJpZnkgdGhhdCB0aGUgdG9rZW4gbm9uY2UgaGFzIG5vdCBiZWVuIHVzZWQg
d2l0aGluIHRoZSBsaWZldGltZSBvZiB0aGUgdG9rZW4uDQo8L2xpPg0KPGxpPmlmIHRoZSBib2R5
X2hhc2ggaXMgc3BlY2lmaWVkLCB2ZXJpZnkgdGhhdCB0aGUgcmVjZWl2ZWQgcmVxdWVzdCBib2R5
IGhhc2hlcyB0byB0aGUgc3BlY2lmaWVkIHZhbHVlLg0KPC9saT4NCjwvb2w+DQoNCjxwPg0KPC9w
Pg0KPGEgbmFtZT0iZGlzY292ZXJ5Ij48L2E+PGJyIC8+PGhyIC8+DQo8dGFibGUgc3VtbWFyeT0i
bGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFs
aWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtU
T0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMuc2VjdGlvbi41Ij48
L2E+PGgzPjUuJm5ic3A7DQpLZXkgRGlzY292ZXJ5IGFuZCB0aGUgVHJ1c3Q8L2gzPg0KDQo8cD5U
byB2ZXJpZnkgdGhlIHNpZ25hdHVyZSwgdGhlIHRydXN0ZWQga2V5IE1VU1QgYmUgZm91bmQgYnkg
dGhlIHZlcmlmaWVyIGZpcnN0LiBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyB0aHJlZSBzdWNo
IG1ldGhvZHMuDQo8L3A+DQo8YSBuYW1lPSJza2V5Ij48L2E+PGJyIC8+PGhyIC8+DQo8dGFibGUg
c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU
T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j
Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMuc2Vj
dGlvbi41LjEiPjwvYT48aDM+NS4xLiZuYnNwOw0KU2hhcmVkIGtleSBpbiBITUFDLVNIQTI1Njwv
aDM+DQoNCjxwPldoZW4gSE1BQy1TSEEyNTYgaXMgc3BlY2lmaWVkIGFzIHRoZSBhbGdvcml0aG0s
IHRoZSBjbGllbnRfc2VjcmV0IGRlZmluZWQgaW4gT0F1dGggMi4wIGlzIHVzZWQgYXMgdGhlIHNo
YXJlZCBrZXkuDQo8L3A+DQo8YSBuYW1lPSJ4NTA5Ij48L2E+PGJyIC8+PGhyIC8+DQo8dGFibGUg
c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU
T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j
Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMuc2Vj
dGlvbi41LjIiPjwvYT48aDM+NS4yLiZuYnNwOw0KWC41MDkgQ2VydGlmaWNhdGVzPC9oMz4NCg0K
PHA+WC41MDkgQ2VydGlmaWNhdGVzIGFyZSBmb3VuZCBmcm9tIHRoZSB1cmkgaW4gJ2NlcnRzX3Vy
aScgZmllbGQuIFRoZSB1cmkgTVVTVCByZXR1cm4gYSBYLjUwOSBmaWxlIGluIFBFTSBmb3JtYXQg
d2l0aCAiYXBwbGljYXRpb24veC1wZW0tZmlsZSIgYXMgdGhlIG1pbWUtdHlwZS4gSXQgTUFZIGNv
bnRhaW4gdGhlIGNlcnRpZmljYXRlIGNoYWluLiBUaGUgQ04gb2YgdGhlIG9idGFpbmVkIGNlcnRp
ZmljYXRlIE1VU1QgbWF0Y2ggdGhlIHVyaSBmb3VuZCBpbiB0aGUgJ3NpZ25lcicgZmllbGQuIE90
aGVyIGF0dHJpYnV0ZXMgaW4gdGhlIFguNTA5IGNlcnRpZmljYXRlcyBTSE9VTEQgYmUgY2hlY2tl
ZCB0byB2ZXJpZnkgdGhlIHZhbGlkaXR5IG9mIHRoZSBjZXJ0aWZpY2F0ZXMuDQo8L3A+DQo8YSBu
YW1lPSJJQU5BIj48L2E+PGJyIC8+PGhyIC8+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxs
cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+
PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+
PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMuc2VjdGlvbi42Ij48L2E+PGgzPjYuJm5i
c3A7DQpJQU5BIENvbnNpZGVyYXRpb25zPC9oMz4NCg0KPHA+VGhpcyBkb2N1bWVudCBtYWtlcyBu
byByZXF1ZXN0IG9mIElBTkEuDQo8L3A+DQo8cD5Ob3RlIHRvIFJGQyBFZGl0b3I6IHRoaXMgc2Vj
dGlvbiBtYXkgYmUgcmVtb3ZlZCBvbiBwdWJsaWNhdGlvbiBhcyBhbiBSRkMuDQo8L3A+DQo8YSBu
YW1lPSJTZWN1cml0eSI+PC9hPjxiciAvPjxociAvPg0KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIg
Y2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmln
aHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7
PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0KPGEgbmFtZT0icmZjLnNlY3Rpb24uNyI+PC9hPjxoMz43
LiZuYnNwOw0KU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L2gzPg0KDQo8cD5bVE9ET10NCjwvcD4N
CjxhIG5hbWU9IkFja25vd2xlZGdlbWVudHMiPjwvYT48YnIgLz48aHIgLz4NCjx0YWJsZSBzdW1t
YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1
ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu
YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4NCjxhIG5hbWU9InJmYy5zZWN0aW9u
LjgiPjwvYT48aDM+OC4mbmJzcDsNCkFja25vd2xlZGdlbWVudHM8L2gzPg0KDQo8cD5bVE9ET10N
CjwvcD4NCjxhIG5hbWU9InJmYy5yZWZlcmVuY2VzIj48L2E+PGJyIC8+PGhyIC8+DQo8dGFibGUg
c3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJU
T0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9j
Ij4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMuc2Vj
dGlvbi45Ij48L2E+PGgzPjkuJm5ic3A7DQpSZWZlcmVuY2VzPC9oMz4NCg0KPGEgbmFtZT0icmZj
LnJlZmVyZW5jZXMxIj48L2E+PGJyIC8+PGhyIC8+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj
ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo
dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8
L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8aDM+OS4xLiZuYnNwO05vcm1hdGl2ZSBSZWZlcmVuY2Vz
PC9oMz4NCjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiPg0KPHRyPjx0ZCBjbGFzcz0iYXV0
aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkMyMTE5Ij5bUkZDMjExOV08L2E+PC90
ZD4NCjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpzb2JAaGFydmFyZC5l
ZHUiPkJyYWRuZXIsIFMuPC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y
Zy9odG1sL3JmYzIxMTkiPktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVx
dWlyZW1lbnQgTGV2ZWxzPC9hPiwmcmRxdW87IEJDUCZuYnNwOzE0LCBSRkMmbmJzcDsyMTE5LCBN
YXJjaCZuYnNwOzE5OTcgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3Jm
YzIxMTkudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJs
aWMvcmZjL2h0bWwvcmZjMjExOS5odG1sIj5IVE1MPC9hPiwgPGEgaHJlZj0iaHR0cDovL3htbC5y
ZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMjExOS54bWwiPlhNTDwvYT4pLjwvdGQ+PC90
cj4NCjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iUkZD
MzQ0NyI+W1JGQzM0NDddPC9hPjwvdGQ+DQo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Kb25zc29u
LCBKLiBhbmQgQi4gS2FsaXNraSwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y
Zy9odG1sL3JmYzM0NDciPlB1YmxpYy1LZXkgQ3J5cHRvZ3JhcGh5IFN0YW5kYXJkcyAoUEtDUykg
IzE6IFJTQSBDcnlwdG9ncmFwaHkgU3BlY2lmaWNhdGlvbnMgVmVyc2lvbiAyLjE8L2E+LCZyZHF1
bzsgUkZDJm5ic3A7MzQ0NywgRmVicnVhcnkmbmJzcDsyMDAzICg8YSBocmVmPSJodHRwOi8vd3d3
LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzNDQ3LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPg0KPHRy
Pjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkM0NjQ4Ij5b
UkZDNDY0OF08L2E+PC90ZD4NCjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkpvc2Vmc3NvbiwgUy4s
ICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjQ4Ij5UaGUg
QmFzZTE2LCBCYXNlMzIsIGFuZCBCYXNlNjQgRGF0YSBFbmNvZGluZ3M8L2E+LCZyZHF1bzsgUkZD
Jm5ic3A7NDY0OCwgT2N0b2JlciZuYnNwOzIwMDYgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVk
aXRvci5vcmcvcmZjL3JmYzQ2NDgudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+DQo8L3RhYmxlPg0K
DQo8YSBuYW1lPSJyZmMucmVmZXJlbmNlczIiPjwvYT48YnIgLz48aHIgLz4NCjx0YWJsZSBzdW1t
YXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1
ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZu
YnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4NCjxoMz45LjIuJm5ic3A7SW5mb3Jt
YXRpdmUgUmVmZXJlbmNlczwvaDM+DQo8dGFibGUgd2lkdGg9Ijk5JSIgYm9yZGVyPSIwIj4NCjx0
cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iSW5mUmVmIj5b
SW5mUmVmXTwvYT48L3RkPg0KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+JmxkcXVvOywmcmRxdW87
IDIwMDQuPC90ZD48L3RyPg0KPC90YWJsZT4NCg0KPGEgbmFtZT0iYW5jaG9yNiI+PC9hPjxiciAv
PjxociAvPg0KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFj
aW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1
ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0K
PGEgbmFtZT0icmZjLnNlY3Rpb24uQSI+PC9hPjxoMz5BcHBlbmRpeCBBLiZuYnNwOw0KQW4gQXBw
ZW5kaXg8L2gzPg0KDQo8cD4NCjwvcD4NCjxhIG5hbWU9InJmYy5hdXRob3JzIj48L2E+PGJyIC8+
PGhyIC8+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNp
bmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVn
Ij48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8
aDM+QXV0aG9ycycgQWRkcmVzc2VzPC9oMz4NCjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAi
IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+DQo8dHI+PHRkIGNsYXNzPSJhdXRob3It
dGV4dCI+Jm5ic3A7PC90ZD4NCjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkRpcmsgQmFsZmFuejwv
dGQ+PC90cj4NCjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPg0KPHRkIGNs
YXNzPSJhdXRob3ItdGV4dCI+R29vZ2xlPC90ZD48L3RyPg0KPHRyIGNlbGxwYWRkaW5nPSIzIj48
dGQ+Jm5ic3A7PC90ZD48dGQ+Jm5ic3A7PC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iYXV0aG9y
LXRleHQiPiZuYnNwOzwvdGQ+DQo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Kb2huIEJyYWRsZXk8
L3RkPjwvdHI+DQo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4NCjx0ZCBj
bGFzcz0iYXV0aG9yLXRleHQiPldpbmdhYTwvdGQ+PC90cj4NCjx0ciBjZWxscGFkZGluZz0iMyI+
PHRkPiZuYnNwOzwvdGQ+PHRkPiZuYnNwOzwvdGQ+PC90cj4NCjx0cj48dGQgY2xhc3M9ImF1dGhv
ci10ZXh0Ij4mbmJzcDs8L3RkPg0KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+TmF0IFNha2ltdXJh
IChFZGl0b3IpPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwv
dGQ+DQo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5Ob211cmEgUmVzZWFyY2ggSW5zdGl0dXRlPC90
ZD48L3RyPg0KPHRyIGNlbGxwYWRkaW5nPSIzIj48dGQ+Jm5ic3A7PC90ZD48dGQ+Jm5ic3A7PC90
ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+DQo8dGQgY2xh
c3M9ImF1dGhvci10ZXh0Ij5MdWtlIFNoZXBoYXJkPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0i
YXV0aG9yLXRleHQiPiZuYnNwOzwvdGQ+DQo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5GYWNlYm9v
azwvdGQ+PC90cj4NCjx0ciBjZWxscGFkZGluZz0iMyI+PHRkPiZuYnNwOzwvdGQ+PHRkPiZuYnNw
OzwvdGQ+PC90cj4NCjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij4mbmJzcDs8L3RkPg0KPHRk
IGNsYXNzPSJhdXRob3ItdGV4dCI+UGF1bCBUYXJqYW48L3RkPjwvdHI+DQo8dHI+PHRkIGNsYXNz
PSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90ZD4NCjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkZhY2Vi
b29rPC90ZD48L3RyPg0KPC90YWJsZT4NCjwvYm9keT48L2h0bWw+DQoNCg==
--000e0cd254146939a3048e92094b
Content-Type: text/xml; charset=US-ASCII; name="draft-sakimura-oauth-signatures-00.xml"
Content-Disposition: attachment; 
	filename="draft-sakimura-oauth-signatures-00.xml"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gd8rcpgi0

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4KPCFET0NUWVBFIHJmYyBT
WVNURU0gInJmYzI2MjkuZHRkIj4KPD9yZmMgdG9jPSJ5ZXMiPz4KPD9yZmMgdG9jb21wYWN0PSJ5
ZXMiPz4KPD9yZmMgdG9jZGVwdGg9IjMiPz4KPD9yZmMgdG9jaW5kZW50PSJ5ZXMiPz4KPD9yZmMg
c3ltcmVmcz0ieWVzIj8+Cjw/cmZjIHNvcnRyZWZzPSJ5ZXMiPz4KPD9yZmMgY29tbWVudHM9Inll
cyI/Pgo8P3JmYyBpbmxpbmU9InllcyI/Pgo8P3JmYyBjb21wYWN0PSJ5ZXMiPz4KPD9yZmMgc3Vi
Y29tcGFjdD0ibm8iPz4KPHJmYyBjYXRlZ29yeT0iaW5mbyIgZG9jTmFtZT0iZHJhZnQtc2FraW11
cmEtb2F1dGgtc2lnbmF0dXJlcy0wMCIKICAgICBpcHI9InRydXN0MjAwOTAyIj4KICA8ZnJvbnQ+
CiAgICA8dGl0bGUgYWJicmV2PSJvc2lnIj5PQXV0aCBTaWduYXR1cmVzIDEuMCBkcmFmdCAwMDwv
dGl0bGU+CgogICAgPGF1dGhvciBmdWxsbmFtZT0iRGlyayBCYWxmYW56IiBpbml0aWFscz0iRC4g
IiBzdXJuYW1lPSJCYWxmYW56Ij4KICAgICAgPG9yZ2FuaXphdGlvbj5Hb29nbGU8L29yZ2FuaXph
dGlvbj4KICAgIDwvYXV0aG9yPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9IkpvaG4gQnJhZGxleSIg
aW5pdGlhbHM9IkouIiBzdXJuYW1lPSJCcmFkbGV5Ij4KICAgICAgPG9yZ2FuaXphdGlvbj5XaW5n
YWE8L29yZ2FuaXphdGlvbj4KICAgIDwvYXV0aG9yPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9Ik5h
dCBTYWtpbXVyYSAoRWRpdG9yKSIgaW5pdGlhbHM9Ik4uICIKICAgICAgICAgICAgc3VybmFtZT0i
U2FraW11cmEgIChFZGl0b3IpIj4KICAgICAgPG9yZ2FuaXphdGlvbj5Ob211cmEgUmVzZWFyY2gg
SW5zdGl0dXRlPC9vcmdhbml6YXRpb24+CiAgICA8L2F1dGhvcj4KCiAgICA8YXV0aG9yIGZ1bGxu
YW1lPSJMdWtlIFNoZXBoYXJkIiBpbml0aWFscz0iTC4iIHN1cm5hbWU9IlNoZXBoYXJkIj4KICAg
ICAgPG9yZ2FuaXphdGlvbj5GYWNlYm9vazwvb3JnYW5pemF0aW9uPgogICAgPC9hdXRob3I+Cgog
ICAgPGF1dGhvciBmdWxsbmFtZT0iUGF1bCBUYXJqYW4iIGluaXRpYWxzPSJQLiIgc3VybmFtZT0i
VGFyamFuIj4KICAgICAgPG9yZ2FuaXphdGlvbj5GYWNlYm9vazwvb3JnYW5pemF0aW9uPgogICAg
PC9hdXRob3I+CgogICAgPGRhdGUgZGF5PSIzMSIgbW9udGg9Ikp1bHkiIHllYXI9IjIwMTAiIC8+
CgogICAgPHdvcmtncm91cD5PcGVuIEF1dGhlbnRpY2F0aW9uIFdvcmtpbmcgR3JvdXA8L3dvcmtn
cm91cD4KCiAgICA8a2V5d29yZD5TaWduYXR1cmU8L2tleXdvcmQ+CgogICAgPGtleXdvcmQ+RHJh
ZnQ8L2tleXdvcmQ+CgogICAgPGFic3RyYWN0PgogICAgICA8dD5UaGlzIHNwZWNpZmljYXRpb24g
ZGVmaW5lcyBzaWduaW5nIG1lY2hhbmlzbSB0byBiZSB1c2VkIGluIE9BdXRoIDIuMC4KICAgICAg
VGhlIE9BdXRoIHJlcXVlc3RzIGFuZCByZXNwb25zZXMgdG9nZXRoZXIgd2l0aCBzaWduYXR1cmUg
cmVsYXRlZAogICAgICBwYXJhbWV0ZXJzIGFyZSBlbmNvZGVkIGludG8gSlNPTiBlbnZlbG9wZSBh
bmQgdGhlbiBzaWduaW5nIGFsZ29yaXRobSBpcwogICAgICBhcHBsaWVkIHRvIG9idGFpbiBCYXNl
NjR1cmwgZW5jb2RlZCBzaWduYXR1cmUgdXNpbmcgc2lnbmF0b3J5J3Mga2V5LiBUaGUKICAgICAg
cmVzdWx0aW5nIHNpZ25hdHVyZSBpcyBjb25jYXRlbmF0ZWQgd2l0aCB0aGUgQmFzZTY0dXJsIGVu
Y29kZWQgSlNPTgogICAgICBlbnZlbG9wZSB0byB3aGljaCB0aGUgc2lnbmF0dXJlIGlzIGFwcGxp
ZWQgYnkgYSBwZXJpb2QgIi4iIHNvIHRoYXQgaXQKICAgICAgY291bGQgYmUgaW5jbHVkZWQgaW4g
VVJMcy48L3Q+CiAgICA8L2Fic3RyYWN0PgoKICAgIDxub3RlIHRpdGxlPSJSZXF1aXJlbWVudHMg
TGFuZ3VhZ2UiPgogICAgICA8dD5UaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF
UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsCiAgICAgICJTSE9VTEQiLCAiU0hPVUxEIE5P
VCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzCiAgICAgIGRv
Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gPHhyZWYKICAgICAg
dGFyZ2V0PSJSRkMyMTE5Ij5SRkMgMjExOTwveHJlZj4uPC90PgogICAgPC9ub3RlPgogIDwvZnJv
bnQ+CgogIDxtaWRkbGU+CiAgICA8c2VjdGlvbiB0aXRsZT0iRGVmaW5pdGlvbnMiPgogICAgICA8
dD48L3Q+CgogICAgICA8dD48bGlzdCBzdHlsZT0iaGFuZ2luZyI+CiAgICAgICAgICA8dCBoYW5n
VGV4dD0iU2VydmVyIERlc2NyaXB0b3JzIj5BIHNlcnZlciBkZXNjcmlwdG9yIGlzIGEgaHR0cHMg
b3IKICAgICAgICAgIGh0dHAgVVJMLiBUaGlzIFVSTCByZXNvbHZlcyB0byBhIGRvY3VtZW50IHRo
YXQgZGVzY3JpYmVzIHRoZSBzZXJ2ZXIKICAgICAgICAgIChzdWNoIGFzIGtleXMgdXNlZCB0byBz
aWduIHJlcXVlc3RzIG9yIHRva2VucywgbG9jYXRpb24gb2YgY2VydGFpbgogICAgICAgICAgZW5k
cG9pbnRzLCBldGMuKS48L3Q+CgogICAgICAgICAgPHQgaGFuZ1RleHQ9IlNpZ25hdHVyZSI+QSBk
aWdpdGFsIHNpZ25hdHVyZSB0aGF0IHByb3ZhYmx5IGJpbmRzIGEKICAgICAgICAgIG1lc3NhZ2Ug
dG8gYSBzaWduZXIncyBrZXlwYWlyIG9yIEhhc2gtYmFzZWQgTWVzc2FnZSBBdXRoZW50aWNhdGlv
bgogICAgICAgICAgQ29kZSB0aGF0IGNhbiBiZSB1c2VkIHRvIHZlcmlmeSBib3RoIHRoZSBkYXRh
IGludGVncml0eSBhbmQgdGhlCiAgICAgICAgICBhdXRoZW50aWNpdHkgb2YgYSBtZXNzYWdlLjwv
dD4KCiAgICAgICAgICA8dCBoYW5nVGV4dD0iU2lnbmVyIj5JbiB0aGlzIHNwZWNpZmljYXRpb24s
IGFuIGFyYml0cmFyeSBpZGVudGlmaWVyCiAgICAgICAgICBhc3NvY2lhdGVkIHdpdGggYSBrZXkg
dXNlZCBpbiBhIHNpZ25hdHVyZS48L3Q+CgogICAgICAgICAgPHQgaGFuZ1RleHQ9IkJhc2U2NHVy
bCBFbmNvZGluZyI+VGhlIFVSTCBhbmQgRmlsZW5hbWUgc2FmZSB2YXJpYW50CiAgICAgICAgICBv
ZiB0aGUgYmFzZTY0IGVuY29kaW5nIGFzIGRlc2NyaWJlZCBpbiA8eHJlZgogICAgICAgICAgdGFy
Z2V0PSJSRkM0NjQ4Ij5SRkM0NjQ4PC94cmVmPiwgc2VjdGlvbiA1LjwvdD4KCiAgICAgICAgICA8
dCBoYW5nVGV4dD0iSE1BQy1TSEEyNTYiPkhhc2gtYmFzZWQgTWVzc2FnZSBBdXRoZW50aWNhdGlv
biBDb2RlCiAgICAgICAgICB1c2luZyBTSEEtMjU2IGFzIHRoZSBoYXNoIGZ1bmN0aW9uLjwvdD4K
CiAgICAgICAgICA8dCBoYW5nVGV4dD0iUlNBLVNIQTI1NiI+UlNBU1NBLVBLQ1MxLXYxXzUgc2ln
bmF0dXJlIGFsZ29yaXRobSBmcm9tCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9IlJGQzM0NDciPlJG
QzM0NDc8L3hyZWY+IHNlY3Rpb24gOC4yLCBhbHNvIGtub3duIGFzCiAgICAgICAgICBQS0NTIzEs
IHVzaW5nIFNIQS0yNTYgYXMgdGhlIGhhc2ggZnVuY3Rpb24gZm9yIEVNU0EtUEtDUzEtdjFfNS48
L3Q+CiAgICAgICAgPC9saXN0PjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRs
ZT0iRW52ZWxvcGUgU3RydWN0dXJlcyI+CiAgICAgIDx0Pk9BdXRoIFNpZ25hdHVyZSBFbnZlbG9w
ZSBpcyBhIEpTT04gb2JqZWN0IHRoYXQgY29udGFpbnMgZm9sbG93aW5nCiAgICAgIGZpZWxkcy4g
Tm90ZSB0aGF0IG1vc3Qgb2YgdGhlbSBhcmUgT1BUSU9OQUwuPC90PgoKICAgICAgPHQ+PGxpc3Qg
c3R5bGU9InN5bWJvbHMiPgogICAgICAgICAgPHQ+YWxnb3JpdGhtIC0gQSBTdHJpbmcgdGhhdCBp
ZGVudGlmaWVzIHRoZSBhbGdvcml0aG0gdXNlZC4gVGhpcwogICAgICAgICAgc3BlY2lmaWNhdGlv
biBkZWZpbmVzIHRoZSBmb2xsb3dpbmc6ICJITUFDLVNIQTI1NiIsCiAgICAgICAgICAiUlNBLVNI
QTI1NiIuPC90PgoKICAgICAgICAgIDx0PnNpZ25lciAtIE9QVElPTkFMLiBBIHN0cmluZyB0aGF0
IGFsbG93cyB0aGUgdmVyaWZpZXIgdG8gZGV0ZXJtaW5lCiAgICAgICAgICB0aGUgc2VydmVyIGRl
c2NyaXB0b3Igb2YgdGhlIFNpZ25lci4gVGhpcyBjb3VsZCBiZSB0aGUgc2VydmVyCiAgICAgICAg
ICBkZXNjcmlwdG9yIGl0c2VsZiwgb3Igc29tZSBmb3JtIG9mIGlkZW50aWZpZXIsIHdoaWNoIHRo
ZSB2ZXJpZmllcgogICAgICAgICAgY2FuIG1hcCB0byBhIHNlcnZlciBkZXNjcmlwdG9yLjwvdD4K
CiAgICAgICAgICA8dD5rZXlpZCAtIE9QVElPTkFMLiBBIFN0cmluZyB0aGF0IGlkZW50aWZpZXMg
dGhlIGtleSB0aGF0IHdhcyB1c2VkCiAgICAgICAgICB0byBzaWduLjwvdD4KCiAgICAgICAgICA8
dD5ub3RfYmVmb3JlIC0gT1BUSU9OQUwuIEFuIGludGVnZXIgdGhhdCByZXByZXNlbnRzIHdoZW4g
ZG9lcyB0aGlzCiAgICAgICAgICBzaWduYXR1cmUgYmVjb21lcyB2YWxpZCAoc2Vjb25kcyBzaW5j
ZSBtaWRuaWdodCAxLzEvMTk3MCB6dWx1KS48L3Q+CgogICAgICAgICAgPHQ+bm90X2FmdGVyIC0g
T1BUSU9OQUwuIEFuIGludGVnZXIgdGhhdCByZXByZXNlbnRzIHdoZW4gZG9lcyB0aGlzCiAgICAg
ICAgICBzaWduYXR1cmUgZXhwaXJlcyAoc2Vjb25kcyBzaW5jZSBtaWRuaWdodCAxLzEvMTk3MCB6
dWx1KS48L3Q+CgogICAgICAgICAgPHQ+YXVkaWVuY2UgLSBPUFRJT05BTC4gVGhlIGF1ZGllbmNl
IGZvciB0aGlzIHRva2VuLiBUaGUgcHJlY2lzZQogICAgICAgICAgc2VtYW50aWNzIG9mIHRoaXMg
ZmllbGQsIGFuZCBob3cgaXQgaXMgdmFsaWRhdGVkLCBkZXBlbmRzIG9uIHRoZQogICAgICAgICAg
YXBwbGljYXRpb24uPC90PgoKICAgICAgICAgIDx0Pm1ldGhvZCAtIE9QVElPTkFMLiBBIFN0cmlu
ZyB0aGF0IHJlcHJlc2VudHMgdGhlIEhUVFAgbWV0aG9kIHVzZWQKICAgICAgICAgIHRvIGV4ZWN1
dGUgdGhlIEhUVFAgcmVxdWVzdC48L3Q+CgogICAgICAgICAgPHQ+bm9uY2UgLSBPUFRJT05BTC4g
QSBzdHJpbmcgdGhhdCBpcyB1c2VkIHRvIHByZXZlbnQgcmVwbGF5CiAgICAgICAgICBhdHRhY2tz
LiBSZWNlaXZlcnMgb2YgT0F1dGgyIFNpZ25lZCBUb2tlbiBtYXkgdmVyaWZ5IHRoYXQgbm9uY2Vz
CiAgICAgICAgICBoYXZlIG5vdCBiZWVuIHByZXZpb3VzbHkgdXNlZCB3aXRoaW4gYSByZWFzb25h
YmxlIGludGVydmFsLjwvdD4KCiAgICAgICAgICA8dD5ib2R5aGFzaCAtIE9QVElPTkFMLiBBIGJh
c2U2NHVybCBlbmNvZGVkIHN0cmluZyBvZiBoYXNoIG9mIHRoZQogICAgICAgICAgcmVxdWVzdCBi
b2R5LiBXaGljaCBoYXNoIGFsZ29yaXRobSBpcyB1c2VkIGRlcGVuZHMgb24gdGhlIHNpZ25hdHVy
ZQogICAgICAgICAgYWxnb3JpdGhtIHNwZWNpZmllZCBpbiB0aGUgcGF5bG9hZC48L3Q+CgogICAg
ICAgICAgPHQ+b2F1dGhfdG9rZW4gLSBPUFRJT05BTC4gQSBzdHJpbmcgdGhhdCByZXByZXNlbnRz
IE9BdXRoIFRva2VuLjwvdD4KCiAgICAgICAgICA8dD5jZXJ0c191cmkgLSBPUFRJT05BTC4gQW4g
VVJJIHRoYXQgcG9pbnRzIHRvIHRoZSBYLjUwOSBwdWJsaWMga2V5CiAgICAgICAgICBjZXJ0aWZp
Y2F0ZXMgdGhhdCBjYW4gYmUgdXNlZCB0byB2ZXJpZnkgdGhlIHNpZ25hdHVyZS48L3Q+CgogICAg
ICAgICAgPHQ+dHlwZSAtIE9QVElPTkFMLiBUaGUgU3RyaW5nICJvYXV0aC1zaWciIHRoYXQgc2ln
bmlmeSB0aGF0IHRoZQogICAgICAgICAgdHlwZSBvZiB0aGlzIEpTT04gb2JqZWN0LjwvdD4KICAg
ICAgICA8L2xpc3Q+PC90PgoKICAgICAgPHQ+VGhlIEVudmVsb3BlIE1BWSBjb250YWluIGFueSBv
dGhlciBmaWVsZHMgb2YgYXJiaXRyYXJ5IHR5cGVzLCBpbgogICAgICB3aGljaCBjYXNlIHRoZSBr
ZXlzIE1VU1QgTk9UIGNvbGxpZWQgd2l0aCB0aGUgZmllbGRzIGRlZmluZWQgYWJvdmUuPC90PgoK
ICAgICAgPGZpZ3VyZT4KICAgICAgICA8cHJlYW1ibGU+Rm9sbG93aW5nIGlzIGEgbm9uLW5vcm1h
dGl2ZSBleGFtcGxlIG9mIHN1Y2ggZW52ZWxvcGUgZm9yCiAgICAgICAgSE1BQy1TSEEyNTY8L3By
ZWFtYmxlPgoKICAgICAgICA8YXJ0d29yaz48IVtDREFUQVt7CiAgICAiYWxnb3JpdGhtIjoiSE1B
Qy1TSEEyNTYiLAogICAgIm9hdXRoX3Rva2VuIjoiYXNkZmprbHNkZmp3b0lqZmsiLAogICAgIm5v
dF9hZnRlciI6MTIzNDU2NzgsCiAgICAidXNlcl9pZCI6MTIyMywKICAgICJwcm9maWxlX2lkIjox
MjIzCn0KCl1dPjwvYXJ0d29yaz4KCiAgICAgICAgPHBvc3RhbWJsZT48L3Bvc3RhbWJsZT4KICAg
ICAgPC9maWd1cmU+CgogICAgICA8ZmlndXJlPgogICAgICAgIDxwcmVhbWJsZT5Gb2xsb3dpbmcg
aXMgYSBub24tbm9ybWF0aXZlIGV4YW1wbGUgb2Ygc3VjaCBlbnZlbG9wZSBmb3IKICAgICAgICBS
U0EtU0hBMjU2PC9wcmVhbWJsZT4KCiAgICAgICAgPGFydHdvcms+PCFbQ0RBVEFbewogICAgImFs
Z29yaXRobSI6IlJTQS1TSEEyNTYiLAogICAgInNpZ25lciI6ImV4YW1wbGUuY29tIiwKICAgICJh
dWRpZW5jZSI6Imh0dHBzOi8vZXhhbXBsZS1jbGllbnQuY29tL3JlZGlyZWN0X3VyaSIsCiAgICAi
Y2VydHNfdXJpIjoiaHR0cDovL2V4YW1wbGUuY29tL215Y2VydHMucGVtIiwKICAgICJvYXV0aF90
b2tlbiI6ImFzZGZqa2xzZGZqd29JamZrIiwKICAgICJub3RfYWZ0ZXIiOjEyMzQ1Njc4LAogICAg
InVzZXJfaWQiOiIxMjIzIiwKICAgICJwcm9maWxlX2lkIjoiMTIyMyIKfQoKXV0+PC9hcnR3b3Jr
PgoKICAgICAgICA8cG9zdGFtYmxlPjwvcG9zdGFtYmxlPgogICAgICA8L2ZpZ3VyZT4KCiAgICAg
IDx0PjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0iQ3JlYXRpbmcgU2ln
bmF0dXJlIj4KICAgICAgPHQ+VGhlIGJhc2ljIHN0ZXBzIG9mIGNyZWF0aW5nIHRoZSBzdHJpbmcg
d2l0aCB0aGUgc2lnbmF0dXJlIGlzIGFzCiAgICAgIGZvbGxvd3M6PC90PgoKICAgICAgPHQ+PGxp
c3Qgc3R5bGU9Im51bWJlcnMiPgogICAgICAgICAgPHQ+QmFzZTY0dXJsIGVuY29kZSB0aGUgZW52
ZWxvcGUgdG8gb2J0YWluIHRoZSAicGF5bG9hZCIuPC90PgoKICAgICAgICAgIDx0PkFwcGx5IHNp
Z25hdHVyZSBvdmVyIHRoZSAicGF5bG9hZCIgYnkgdGhlIHNwZWNpZmllZCBhbGdvcml0aG0gdG8K
ICAgICAgICAgIG9idGFpbiB0aGUgc2lnbmF0dXJlLjwvdD4KCiAgICAgICAgICA8dD5CYXNlNjR1
cmwgZW5jb2RlIHRoZSBzaWduYXR1cmUgdG8gb2J0YWluIHRoZSAic2lnbmF0dXJlCiAgICAgICAg
ICBzdHJpbmciLjwvdD4KCiAgICAgICAgICA8dD5Db25jYXRlbmF0ZSB0aGUgInNpZ25hdHVyZSBz
dHJpbmciIGFuZCB0aGUgInBheWxvYWQiIHdpdGggYQogICAgICAgICAgcGVyaW9kICIuIihBU0NJ
SSAweDJFKS4gVGhpcyBzdHJpbmcgaXMgY2FsbGVkICJKU09OIFRva2VuIi48L3Q+CiAgICAgICAg
PC9saXN0PjxmaWd1cmU+CiAgICAgICAgICA8cHJlYW1ibGU+TGluZSBicmVha3MgYXJlIGZvciBk
aXNwbGF5IHB1cnBvc2VzIG9ubHkuIDwvcHJlYW1ibGU+CgogICAgICAgICAgPGFydHdvcms+PCFb
Q0RBVEFbdmxYZ3U2NEJRR0ZTUXJZMFpjSkJaQVNNdll2VEh1OUdRMFlNOXJqUFNzbwouCmV5Smhi
R2R2Y21sMGFHMGlPaUpJVFVGRExWTklRVEkxTmlJc0lqQWlPaUp3WVhsc2IyRmtJbjAKXV0+PC9h
cnR3b3JrPgoKICAgICAgICAgIDxwb3N0YW1ibGU+PC9wb3N0YW1ibGU+CiAgICAgICAgPC9maWd1
cmU+PC90PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hvcj0idmVyaWZpY2F0aW9u
IiB0aXRsZT0iU2lnbmF0dXJlIFZlcmlmaWNhdGlvbiI+CiAgICAgIDx0PlRvIHZlcmlmeSB0aGUg
c2lnbmF0dXJlLCB0aGUgdmVyaWZpZXIgTVVTVCBoYXZlIGFuIGFjY2VzcyB0byBhCiAgICAgIHRy
dXN0ZWQgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBrZXkuIFRydXN0ZWQga2V5IE1BWSBCRSBlc3Rh
Ymxpc2hlZCBpbgogICAgICB0aGUgZm9sbG93aW5nIHdheXM6PC90PgoKICAgICAgPHQ+PGxpc3Qg
c3R5bGU9Im51bWJlcnMiPgogICAgICAgICAgPHQ+SWYgdGhlIGtleSBpcyB0aGUgc2hhcmVkIGtl
eSBpbiBITUFDLVNIQTI1NiwgdGhlIGtleSBNVVNUIEJFIHRoZQogICAgICAgICAgY2xpZW50X3Nl
Y3JldCBkZWZpbmVkIGluIHRoZSBPQXV0aCAyLjAgc3BlY2lmaWNhdGlvbi48L3Q+CgogICAgICAg
ICAgPHQ+SWYgdGhlIGtleSBpcyBSU0Ega2V5IGRlZmluZWQgaW4gWC41MDkgc2VsZi1zaWduZWQg
Y2VydGlmaWNhdGUsCiAgICAgICAgICB0aGUga2V5IE1VU1QgYmUgb2J0YWluZWQgdGhyb3VnaCB0
aGUgRGlzY292ZXJ5IG1lY2hhbmlzbSBkZWZpbmVkIGluCiAgICAgICAgICBTZWN0aW9uIDUuPC90
PgogICAgICAgIDwvbGlzdD48L3Q+CgogICAgICA8dD5UaGUgdmVyaWZpY2F0aW9uIGludm9sdmVz
IHRoZSBmb2xsb3dpbmcgc3RlcHM6IDxsaXN0IHN0eWxlPSJudW1iZXJzIj4KICAgICAgICAgIDx0
PlNwbGl0IHRoZSBKU09OIFRva2VuIGJ5IGEgcGVyaW9kICIuIihBU0NJSSAweDJFKSB0byBvYnRh
aW4gdGhlCiAgICAgICAgICBzaWduYXR1cmUgYW5kIHRoZSBwYXlsb2FkLjwvdD4KCiAgICAgICAg
ICA8dD5CYXNlNjR1cmwgZGVjb2RlIGJvdGggdGhlICJzaWduYXR1cmUgc3RyaW5nIiBhbmQgdGhl
ICJwYXlsb2FkIiB0bwogICAgICAgICAgb2J0YWluIHRoZSBzaWduYXR1cmUgYW5kIHRoZSBlbnZl
bG9wZSByZXNwZWN0aXZlbHkuPC90PgoKICAgICAgICAgIDx0PklmIHRoZSBhbGdvcml0aG0gaXMg
IkhNQUMtU0hBMjU2IiwgY2FsY3VsYXRlIHRoZSBzaWduYXR1cmUgZnJvbQogICAgICAgICAgdGhl
IHBheWxvYWQgdXNpbmcgdGhlIGNsaWVudF9zZWNyZXQuIElmIHRoZSBhbGdvcml0aG0gaXMKICAg
ICAgICAgICJSU0EtU0hBMjU2IiwgdGhlbiB1c2UgUlNBU1NBLVBLQ1MxLXYxXzUgdmVyaWZpY2F0
aW9uIGFsZ29yaXRobSBmcm9tCiAgICAgICAgICA8eHJlZiB0YXJnZXQ9IlJGQzM0NDciPlJGQzM0
NDc8L3hyZWY+IHNlY3Rpb24gOC4yLjEuIHRvIHZlcmlmeSB0aGUKICAgICAgICAgIFNpZ25hdHVy
ZS48L3Q+CgogICAgICAgICAgPHQ+SWYgdGhlIG5vdF9iZWZvcmUgZmllbGQgaXMgc3BlY2lmaWVk
LCB2ZXJpZnkgdGhhdCB0aGUgY3VycmVudAogICAgICAgICAgdGltZSBpcyBub3QgYmVmb3JlIHRo
ZSBub3RfYmVmb3JlIHRpbWVzdGFtcCBpbiB0aGUgcGF5bG9hZCwgYW5kIHRoYXQKICAgICAgICAg
IHRoZSBjdXJyZW50IHRpbWUgaXMgbm90IGFmdGVyIHRoZSBleHBpcmF0aW9uIHRpbWUgb2YgdGhl
IHRva2VuCiAgICAgICAgICAoZGVmaW5lZCBhcyBub3RfYmVmb3JlICsgdG9rZW5fbGlmZXRpbWUp
LiBUaGUgdmVyaWZpZXIgU0hPVUxEIGJlCiAgICAgICAgICBsZW5pZW50IGFuZCBhbnRpY2lwYXRl
IHNvbWUgY2xvY2sgc2tldyBvbiB0aGUgaXNzdWVyJ3Mgc2lkZS48L3Q+CgogICAgICAgICAgPHQ+
SWYgdGhlIGF1ZGllbmNlIGZpZWxkIGlzIHNwZWNpZmllZCwgdmVyaWZ5IHRoZSBhdWRpZW5jZSBm
aWVsZCBpbgogICAgICAgICAgYW4gYXBwbGljYXRpb24tZGVwZW5kZW50IG1hbm5lci48L3Q+Cgog
ICAgICAgICAgPHQ+SWYgdGhlIG1ldGhvZCBmaWVsZCBpcyBzcGVjaWZpZWQsIHZlcmlmeSB0aGF0
IHRoZSBtZXRob2QgaW4gdGhlCiAgICAgICAgICB0b2tlbiBwYXlsb2FkIGVxdWFscyB0aGUgbWV0
aG9kIHVzZWQgdG8gYWNjZXNzIHRoZSBIVFRQIHJlc291cmNlPC90PgoKICAgICAgICAgIDx0Pklm
IHRoZSBhdWRpZW5jZSBmaWVsZCBpcyBzcGVjaWZpZWQsIHZlcmlmeSB0aGF0IHRoZSBhdWRpZW5j
ZSBpbgogICAgICAgICAgdGhlIHRva2VuIHBheWxvYWQgbWF0Y2hlcyB0aGUgVVJJIHVzZWQgdG8g
YWNjZXNzIHRoZSBIVFRQCiAgICAgICAgICByZXNvdXJjZS48L3Q+CgogICAgICAgICAgPHQ+SWYg
dGhlIG5vbmNlIGlzIHNwZWNpZmllZCwgdmVyaWZ5IHRoYXQgdGhlIHRva2VuIG5vbmNlIGhhcyBu
b3QKICAgICAgICAgIGJlZW4gdXNlZCB3aXRoaW4gdGhlIGxpZmV0aW1lIG9mIHRoZSB0b2tlbi48
L3Q+CgogICAgICAgICAgPHQ+aWYgdGhlIGJvZHlfaGFzaCBpcyBzcGVjaWZpZWQsIHZlcmlmeSB0
aGF0IHRoZSByZWNlaXZlZCByZXF1ZXN0CiAgICAgICAgICBib2R5IGhhc2hlcyB0byB0aGUgc3Bl
Y2lmaWVkIHZhbHVlLjwvdD4KICAgICAgICA8L2xpc3Q+PC90PgoKICAgICAgPHQ+PC90PgogICAg
PC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hvcj0iZGlzY292ZXJ5IiB0aXRsZT0iS2V5IERp
c2NvdmVyeSBhbmQgdGhlIFRydXN0Ij4KICAgICAgPHQ+VG8gdmVyaWZ5IHRoZSBzaWduYXR1cmUs
IHRoZSB0cnVzdGVkIGtleSBNVVNUIGJlIGZvdW5kIGJ5IHRoZQogICAgICB2ZXJpZmllciBmaXJz
dC4gVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgdGhyZWUgc3VjaCBtZXRob2RzLjwvdD4KCiAg
ICAgIDxzZWN0aW9uIGFuY2hvcj0ic2tleSIgdGl0bGU9IlNoYXJlZCBrZXkgaW4gSE1BQy1TSEEy
NTYiPgogICAgICAgIDx0PldoZW4gSE1BQy1TSEEyNTYgaXMgc3BlY2lmaWVkIGFzIHRoZSBhbGdv
cml0aG0sIHRoZSBjbGllbnRfc2VjcmV0CiAgICAgICAgZGVmaW5lZCBpbiBPQXV0aCAyLjAgaXMg
dXNlZCBhcyB0aGUgc2hhcmVkIGtleS48L3Q+CiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0
aW9uIGFuY2hvcj0ieDUwOSIgdGl0bGU9IlguNTA5IENlcnRpZmljYXRlcyI+CiAgICAgICAgPHQ+
WC41MDkgQ2VydGlmaWNhdGVzIGFyZSBmb3VuZCBmcm9tIHRoZSB1cmkgaW4gJ2NlcnRzX3VyaScg
ZmllbGQuIFRoZQogICAgICAgIHVyaSBNVVNUIHJldHVybiBhIFguNTA5IGZpbGUgaW4gUEVNIGZv
cm1hdCB3aXRoCiAgICAgICAgImFwcGxpY2F0aW9uL3gtcGVtLWZpbGUiIGFzIHRoZSBtaW1lLXR5
cGUuIEl0IE1BWSBjb250YWluIHRoZQogICAgICAgIGNlcnRpZmljYXRlIGNoYWluLiBUaGUgQ04g
b2YgdGhlIG9idGFpbmVkIGNlcnRpZmljYXRlIE1VU1QgbWF0Y2ggdGhlCiAgICAgICAgdXJpIGZv
dW5kIGluIHRoZSAnc2lnbmVyJyBmaWVsZC4gT3RoZXIgYXR0cmlidXRlcyBpbiB0aGUgWC41MDkK
ICAgICAgICBjZXJ0aWZpY2F0ZXMgU0hPVUxEIGJlIGNoZWNrZWQgdG8gdmVyaWZ5IHRoZSB2YWxp
ZGl0eSBvZiB0aGUKICAgICAgICBjZXJ0aWZpY2F0ZXMuPC90PgogICAgICA8L3NlY3Rpb24+CiAg
ICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJJQU5BIiB0aXRsZT0iSUFOQSBDb25z
aWRlcmF0aW9ucyI+CiAgICAgIDx0PlRoaXMgZG9jdW1lbnQgbWFrZXMgbm8gcmVxdWVzdCBvZiBJ
QU5BLjwvdD4KCiAgICAgIDx0Pk5vdGUgdG8gUkZDIEVkaXRvcjogdGhpcyBzZWN0aW9uIG1heSBi
ZSByZW1vdmVkIG9uIHB1YmxpY2F0aW9uIGFzIGFuCiAgICAgIFJGQy48L3Q+CiAgICA8L3NlY3Rp
b24+CgogICAgPHNlY3Rpb24gYW5jaG9yPSJTZWN1cml0eSIgdGl0bGU9IlNlY3VyaXR5IENvbnNp
ZGVyYXRpb25zIj4KICAgICAgPHQ+W1RPRE9dPC90PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0
aW9uIGFuY2hvcj0iQWNrbm93bGVkZ2VtZW50cyIgdGl0bGU9IkFja25vd2xlZGdlbWVudHMiPgog
ICAgICA8dD5bVE9ET108L3Q+CiAgICA8L3NlY3Rpb24+CiAgPC9taWRkbGU+CgogIDxiYWNrPgog
ICAgPHJlZmVyZW5jZXMgdGl0bGU9Ik5vcm1hdGl2ZSBSZWZlcmVuY2VzIj4KICAgICAgPD9yZmMg
aW5jbHVkZT0icmVmZXJlbmNlLlJGQy4yMTE5Ij8+CgogICAgICA8P3JmYyBpbmNsdWRlPSdyZWZl
cmVuY2UuUkZDLjQ2NDgnPz4KCiAgICAgIDw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5SRkMuMzQ0
Nyc/PgogICAgPC9yZWZlcmVuY2VzPgoKICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJJbmZvcm1hdGl2
ZSBSZWZlcmVuY2VzIj4KICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IkluZlJlZiI+CiAgICAgICAg
PGZyb250PgogICAgICAgICAgPHRpdGxlPjwvdGl0bGU+CgogICAgICAgICAgPGF1dGhvcj4KICAg
ICAgICAgICAgPG9yZ2FuaXphdGlvbj48L29yZ2FuaXphdGlvbj4KICAgICAgICAgIDwvYXV0aG9y
PgoKICAgICAgICAgIDxkYXRlIHllYXI9IjIwMDQiIC8+CiAgICAgICAgPC9mcm9udD4KICAgICAg
PC9yZWZlcmVuY2U+CiAgICA8L3JlZmVyZW5jZXM+CgogICAgPHNlY3Rpb24gdGl0bGU9IkFuIEFw
cGVuZGl4Ij4KICAgICAgPHQ+PC90PgogICAgPC9zZWN0aW9uPgogIDwvYmFjaz4KPC9yZmM+Cg==
--000e0cd254146939a3048e92094b--

From mscurtescu@google.com  Tue Aug 24 14:39:18 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5E33A69E6 for ; Tue, 24 Aug 2010 14:39:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.71
X-Spam-Level: 
X-Spam-Status: No, score=-105.71 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtI-nRrTovSK for ; Tue, 24 Aug 2010 14:39:17 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 2BC593A67D4 for ; Tue, 24 Aug 2010 14:39:17 -0700 (PDT)
Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o7OLdnju016518 for ; Tue, 24 Aug 2010 14:39:49 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282685990; bh=DKd2wnBYHsOhVTCKCjlz4pK462s=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=eVbxyOcrVmD1V1r5INi5/Orhlfdhluy8eTkQ/Yr2pdyHpvJSOJ2Q7qnW8wOleCfrV TQnPC6Aqmb8wDAP+O/k4g==
Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by hpaq1.eem.corp.google.com with ESMTP id o7OLdlnf017949 for ; Tue, 24 Aug 2010 14:39:48 -0700
Received: by gyg8 with SMTP id 8so26650gyg.3 for ; Tue, 24 Aug 2010 14:39:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=tpVte8n0U11E+yE7zNOloTXx1/oSV/ozCpEvfdFfxKI=; b=VDBXhF1pVuoLrzWJKkRwblzzJWMRw5QNCBxH2MUthLpzku/zoI2/1Hs7W+aZ2rBOa+ 9qhi5cRc2y45vkCdkzcA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=SaH59BzR0opQGgjtFCY54GiNRon1ODEr2Um28uVQC+LPRpP/2nNhrWot+BDChvGm6W v1ZC9uEompuuZ9NweCjw==
Received: by 10.100.34.19 with SMTP id h19mr8071472anh.2.1282685987230; Tue, 24 Aug 2010 14:39:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.138.5 with HTTP; Tue, 24 Aug 2010 14:39:27 -0700 (PDT)
In-Reply-To: <4C6BDA6B.1020805@gmx.de>
References: <4C69A909.2060006@lodderstedt.net> <4C6BDA6B.1020805@gmx.de>
From: Marius Scurtescu 
Date: Tue, 24 Aug 2010 14:39:27 -0700
Message-ID: 
To: Stefanie Dronia 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] survey: token revocation design options
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Aug 2010 21:39:18 -0000

+2

1c introduces one more token that needs to be managed, both by the
client and by the server.

1a/b/c has one more issue, tokens are more exposed than usual and if
revocation fails this can be problematic.

Both access and refresh tokens should be revocable, right?

Thanks,
Marius



On Wed, Aug 18, 2010 at 6:04 AM, Stefanie Dronia  wrote:
> Hi Torsten,
>
> ++2. No care about token formats or URL length problem.
>
> -1: all options bring some problems along (as you already indicated).
> Additionally, an overloading of HTTP DELETE (as Igor mentioned) is not an
> option from my point of view. Every overloading would be deployment speci=
fic
> (or has to be defined by the OAuth spec???) and I doubt that it is possib=
le
> to overload this method with widely-used frameworks.
>
> -1c: Introduction of token ids: If a token is addressed by its ID, it is =
IMO
> not possible to verify in all cases that the client (who requests
> revocation/modification) is same client that the token was issued for bef=
ore
> if the authorization server is stateless. So someone might catch a token =
and
> then revokes it.
> May there be other security issues?
> Another drawback is that the access token response has to be extended.
>
> What kind of modifications of tokens do you have in mind? (as you comment=
ed
> with 1c)
>
> Regards,
> Stefanie
>
>
> Am 16.08.2010 23:09, schrieb Torsten Lodderstedt:
>>
>> Hi all,
>>
>> I intend to submit a I-D for token revocation. Based on previous
>> discussions on the mailing list and here at Deutsche Telekom, I see a co=
uple
>> of design options. I would like to share those options with the WG and t=
ry
>> to reach consensus on a single option before investing the time to write=
 the
>> I-D.
>>
>> 1) HTTP Delete on tokens endpoint
>>
>> DELETE seems a natural way for revoking (deleting) tokens. Although the
>> HTTP spec is a bit vaque in this concern, current practice prohibits a b=
ody
>> for DELETE requests. So the token must be addressed by the request's URI=
.
>> Lets assume the token is passed as URI query parameter as follows:
>>
>> =A0DELETE /tokens?refresh_token=3D8xLOxBtZp8&&&# HTTP/1.1
>> =A0Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>
>> But is it advisable to pass tokens as URI query parameters? The current
>> character set definition for access tokens (=A75.1.1) is not URL-safe si=
nce it
>> includes URI reserved characters (e.g. '/'). Additionally, there is no
>> definition of a refresh tokens character set. So compliant authorization
>> servers could issue tokens, which cannot be safely passed as URI query
>> parameters.
>>
>> Note: As an additional challenge, self-contained tokens can be very larg=
e.
>> So passing them as URI parameter may exceed URL length limits.
>>
>> I see the following alternatives to cope with the encoding problem:
>>
>> a) Force usage of a URL-safe character set for access and request tokens=
.
>> - rather restrictive, will most likely collide with existing token forma=
ts
>> - does not solve URL length problem
>>
>> b) Force base64-URL-safe encoding for all tokens on transit.
>> - does not solve URL length problem
>> - significant API change
>>
>> c) Authorization servers supporting revocation may additionally issue a
>> URL-safe token id in the access token response. This id is used to refer=
ence
>> the token in DELETE requests.
>>
>> =A0 =A0HTTP/1.1 200 OK
>> =A0 =A0Content-Type: application/json
>> =A0 =A0Cache-Control: no-store
>> =A0 =A0{
>> =A0 =A0 =A0"access_token":"SlAV32hkKG/hhh/&%",
>> =A0 =A0 =A0"access_token_id":"234567890",
>> =A0 =A0 =A0"expires_in":3600,
>> =A0 =A0 =A0"refresh_token":"8xLOxBtZp8&&&#&",
>> =A0 =A0 =A0"refresh_token_id":"asdfghjklhgf"
>> =A0 =A0}
>>
>>
>> =A0DELETE /tokens?refresh_token_id=3Dasdfghjklhgf HTTP/1.1
>> =A0Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>
>> Note: Since tokens become addressable resources on the authz server, one
>> could also query or modify token data using a GET/PUT requests
>>
>> =A0GET /tokens?refresh_token_id=3Dasdfghjklhgf HTTP/1.1
>> =A0Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>
>> =A0 =A0HTTP/1.1 200 OK
>> =A0 =A0Content-Type: application/json
>> =A0 =A0Cache-Control: no-store
>>
>> =A0 =A0{
>> =A0 =A0 =A0"scope":"abc",
>> =A0 =A0 =A0"issued_on":"08/11/2010",
>> =A0 =A0 =A0"last_usage":"08/13/2010" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 }
>>
>>
>> 2) HTTP Post on dedicated revocation endpoint
>>
>> An additional endpoint is used to revoke tokens. The token to be revoked
>> is sent as request body parameter.
>>
>> =A0 =A0POST /revocation HTTP/1.1
>> =A0 =A0Host: server.example.com
>> =A0 =A0Content-Type: application/x-www-form-urlencoded
>> =A0 =A0Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>
>> =A0 =A0refresh_token=3Dn4E9O119d
>>
>> This option requires some support for the client to discover the
>> revocation endpoint.
>>
>> Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest
>> additional design options.
>>
>> regards,
>> Torsten.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From torsten@lodderstedt.net  Tue Aug 24 15:41:27 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3793A69D4 for ; Tue, 24 Aug 2010 15:41:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.153
X-Spam-Level: 
X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_20=-0.74, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S5J21tbopP0 for ; Tue, 24 Aug 2010 15:41:25 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by core3.amsl.com (Postfix) with ESMTP id C5F623A6A73 for ; Tue, 24 Aug 2010 15:41:13 -0700 (PDT)
Received: from [79.253.55.224] (helo=[192.168.71.42]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Oo2BX-00043I-HS for oauth@ietf.org; Wed, 25 Aug 2010 00:41:39 +0200
Message-ID: <4C744AAD.3050309@lodderstedt.net>
Date: Wed, 25 Aug 2010 00:41:49 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: OAuth WG 
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Subject: [OAUTH-WG] comments/questions on draft 10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Aug 2010 22:41:27 -0000

  --- p.6 terminology/authorization server
"         A server capable of issuing tokens after successfully
          authenticating the resource owner and obtaining authorization.
          The authorization server may be the same server as the resource
          server, or a separate entity. "
Based on the discussion in 
http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html, I 
would suggest to add the following: "A single authorization server may 
issue tokens for different resource servers."

--- p.11 What is the meaning of "... the authentication of the client is 
based on the user-agent's same-origin policy." ? As far as I know, this 
policy restricts the hosts the JavaScript client is allowed to interact 
with. How does this "feature" authenticate the client on the 
authorization server?

--- Examples and client authentication: Since BASIC authentication is 
the default mechanisms for client authentication, I would suggest to use 
it in all examples.

--- Scope syntax and usage
The discussion in 
http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html 
revealed most WG members do not want to define the scope's syntax and 
semantics in the spec. Instead these aspects shall be kept deployment 
specific. Accepted. To me, this means the scope is specified as a 
placeholder/pattern only and not as a fullblown parameter. In contrast, 
the draft raises the expectation to specify more than that e.g. by 
defining delimiters and talking about orders on scopes (less/equal). In 
my opinion, we should not pretend to standardize something we don't 
really standardize. Moreover, if we want to give the deployments the 
freedom to define the scope's syntax and semantics, then we should not 
impose any needless restrictions. Here are some examples:

p. 17
scope
          OPTIONAL.  The scope of the access request expressed as a list
          of space-delimited strings.  ..

Why is it neccessary to define a delimiter for a parameter that 
otherwise is completly left unspecified? What is the benefit? I would 
suggest to remove the delimiter definition and let the scope just be an 
opaque string that can be used by the deployment in any way. Lists of 
spec-delimited strings are one options, other deployments would probably 
use JSON documents or an elaborated scope-expression language.

p.22 "If the access grant being used already
          represents an approved scope (e.g. authorization code,
          assertion), the requested scope MUST be equal or lesser than
          the scope previously granted."

This statement is useless without a definition of an order and equality 
among scope values. And there might also be a sets, subsets and 
supersets of scopes.
Proposal:
Either (a) add an clarification that equality, order, e.t.c. of scopes 
is deployment specific or (b) remove the statement.

p. 33    The "scope" attribute is a space-delimited list of scope values
    indicating the required scope of the access token for accessing the
    requested resource."

There is no explanation what a compliant client should do with the scope 
attribute value of a WWW-Authenticate header.
Proposal:
Either a) state that usage of the scope value is deployment specific or 
b) that the client shall pass this attribute to the respective scope 
parameters on end-user authorization and tokens endpoint or c) remove 
the attribute.

--- section 3: "The authorization server MUST support the use of
    the HTTP "GET" method for the end-user authorization endpoint, and
    MAY support the use of the "POST" method as well."

What is the use case behind POST on that endpoint? Is the authorization 
server expected to behave differently with respect to the redirect back 
to the client? For example, shall HTML FORM Redirection be used for the 
way back?

section 4.3. In my opinion, unauthorized_client should be used on 
conjunction with status code 403.

section 5.1.1. access token charset: This definition allows 
authorization server for the issuance of token, which cannot be safely 
passed with URI query parameters (e.g. they are allowd to contain "&"). 
But section 5.1.2 specifies that access tokens can directly be used as 
such parameters. This may cause problems.

Proposal: Either a) modify the access token charset to be URI query 
parameter compliant or b) advice resource server/clients using URI query 
parameters to additionaly URL-safe-base64-encode tokens before sending 
them to the resource server.

regards,
Torsten.

From torsten@lodderstedt.net  Tue Aug 24 15:42:24 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604433A69E6 for ; Tue, 24 Aug 2010 15:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.062
X-Spam-Level: 
X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.187,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eQhpvAX57pO for ; Tue, 24 Aug 2010 15:42:15 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 5AF773A6873 for ; Tue, 24 Aug 2010 15:42:03 -0700 (PDT)
Received: from [79.253.55.224] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Oo2CR-0008SO-4g; Wed, 25 Aug 2010 00:42:35 +0200
Message-ID: <4C744AE4.4070604@lodderstedt.net>
Date: Wed, 25 Aug 2010 00:42:44 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Marius Scurtescu 
References: <4C69A909.2060006@lodderstedt.net> <4C6BDA6B.1020805@gmx.de> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Df-Sender: torsten@lodderstedt-online.de
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] survey: token revocation design options
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Aug 2010 22:42:24 -0000

  Am 24.08.2010 23:39, schrieb Marius Scurtescu:
> +2
>
> 1c introduces one more token that needs to be managed, both by the
> client and by the server.
>
> 1a/b/c has one more issue, tokens are more exposed than usual and if
> revocation fails this can be problematic.
>
> Both access and refresh tokens should be revocable, right?

Yes.

regards,
Torsten.

> Thanks,
> Marius
>
>
>
> On Wed, Aug 18, 2010 at 6:04 AM, Stefanie Dronia  wrote:
>> Hi Torsten,
>>
>> ++2. No care about token formats or URL length problem.
>>
>> -1: all options bring some problems along (as you already indicated).
>> Additionally, an overloading of HTTP DELETE (as Igor mentioned) is not an
>> option from my point of view. Every overloading would be deployment specific
>> (or has to be defined by the OAuth spec???) and I doubt that it is possible
>> to overload this method with widely-used frameworks.
>>
>> -1c: Introduction of token ids: If a token is addressed by its ID, it is IMO
>> not possible to verify in all cases that the client (who requests
>> revocation/modification) is same client that the token was issued for before
>> if the authorization server is stateless. So someone might catch a token and
>> then revokes it.
>> May there be other security issues?
>> Another drawback is that the access token response has to be extended.
>>
>> What kind of modifications of tokens do you have in mind? (as you commented
>> with 1c)
>>
>> Regards,
>> Stefanie
>>
>>
>> Am 16.08.2010 23:09, schrieb Torsten Lodderstedt:
>>> Hi all,
>>>
>>> I intend to submit a I-D for token revocation. Based on previous
>>> discussions on the mailing list and here at Deutsche Telekom, I see a couple
>>> of design options. I would like to share those options with the WG and try
>>> to reach consensus on a single option before investing the time to write the
>>> I-D.
>>>
>>> 1) HTTP Delete on tokens endpoint
>>>
>>> DELETE seems a natural way for revoking (deleting) tokens. Although the
>>> HTTP spec is a bit vaque in this concern, current practice prohibits a body
>>> for DELETE requests. So the token must be addressed by the request's URI.
>>> Lets assume the token is passed as URI query parameter as follows:
>>>
>>>   DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1
>>>   Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>>
>>> But is it advisable to pass tokens as URI query parameters? The current
>>> character set definition for access tokens (§5.1.1) is not URL-safe since it
>>> includes URI reserved characters (e.g. '/'). Additionally, there is no
>>> definition of a refresh tokens character set. So compliant authorization
>>> servers could issue tokens, which cannot be safely passed as URI query
>>> parameters.
>>>
>>> Note: As an additional challenge, self-contained tokens can be very large.
>>> So passing them as URI parameter may exceed URL length limits.
>>>
>>> I see the following alternatives to cope with the encoding problem:
>>>
>>> a) Force usage of a URL-safe character set for access and request tokens.
>>> - rather restrictive, will most likely collide with existing token formats
>>> - does not solve URL length problem
>>>
>>> b) Force base64-URL-safe encoding for all tokens on transit.
>>> - does not solve URL length problem
>>> - significant API change
>>>
>>> c) Authorization servers supporting revocation may additionally issue a
>>> URL-safe token id in the access token response. This id is used to reference
>>> the token in DELETE requests.
>>>
>>>     HTTP/1.1 200 OK
>>>     Content-Type: application/json
>>>     Cache-Control: no-store
>>>     {
>>>       "access_token":"SlAV32hkKG/hhh/&%",
>>>       "access_token_id":"234567890",
>>>       "expires_in":3600,
>>>       "refresh_token":"8xLOxBtZp8&&&#&",
>>>       "refresh_token_id":"asdfghjklhgf"
>>>     }
>>>
>>>
>>>   DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1
>>>   Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>>
>>> Note: Since tokens become addressable resources on the authz server, one
>>> could also query or modify token data using a GET/PUT requests
>>>
>>>   GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1
>>>   Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>>
>>>     HTTP/1.1 200 OK
>>>     Content-Type: application/json
>>>     Cache-Control: no-store
>>>
>>>     {
>>>       "scope":"abc",
>>>       "issued_on":"08/11/2010",
>>>       "last_usage":"08/13/2010"                   }
>>>
>>>
>>> 2) HTTP Post on dedicated revocation endpoint
>>>
>>> An additional endpoint is used to revoke tokens. The token to be revoked
>>> is sent as request body parameter.
>>>
>>>     POST /revocation HTTP/1.1
>>>     Host: server.example.com
>>>     Content-Type: application/x-www-form-urlencoded
>>>     Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>>>
>>>     refresh_token=n4E9O119d
>>>
>>> This option requires some support for the client to discover the
>>> revocation endpoint.
>>>
>>> Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest
>>> additional design options.
>>>
>>> regards,
>>> Torsten.
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>


From recordond@gmail.com  Tue Aug 24 15:59:07 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0A53A6954 for ; Tue, 24 Aug 2010 15:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.453
X-Spam-Level: 
X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dctMi8a2uT4U for ; Tue, 24 Aug 2010 15:59:06 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A0A7D3A6873 for ; Tue, 24 Aug 2010 15:59:05 -0700 (PDT)
Received: by bwz9 with SMTP id 9so179109bwz.31 for ; Tue, 24 Aug 2010 15:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=FuVYGT6UdNg4pccDAcgcMQ9Qwg2e7cVml6IAjesLVPs=; b=I9E6MmjYJel758q/Y8GR9eq25ScrC4U19SW2wrHoMeZSAIb8cr6O18yooYTjoh0YKe blngjrnH4qyQYuOXTaI/nU063T1tO8avG96zXAGWF6mD9nDGhN0rVONcOKQbdrX1/qzW BYRKnzr9HzjOzo2Lu4UdWjGQcPf93MiMk3ugc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=a+2EKiCRRIQvO7Qya0xo9SRONEMUV/DoGjFqtDJFgbkOu/X8le5ytdylgaiVYg59yY 1Sn0PK4NcoiSyUu59+0Yow65yePvvZHw4KL+B6KaRp4ZFLYk/nKrb648cKpD5Tozvq/7 ssPaPyeH9aiyXhlWX1Xj5mCoavshNjayMk+w4=
MIME-Version: 1.0
Received: by 10.204.120.130 with SMTP id d2mr5388109bkr.9.1282690777972; Tue, 24 Aug 2010 15:59:37 -0700 (PDT)
Received: by 10.204.7.139 with HTTP; Tue, 24 Aug 2010 15:59:37 -0700 (PDT)
In-Reply-To: <4C744AAD.3050309@lodderstedt.net>
References: <4C744AAD.3050309@lodderstedt.net>
Date: Tue, 24 Aug 2010 22:59:37 +0000
Message-ID: 
From: David Recordon 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=001636c5a4012d7f2f048e99b8a2
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] comments/questions on draft 10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Aug 2010 22:59:07 -0000

--001636c5a4012d7f2f048e99b8a2
Content-Type: text/plain; charset=ISO-8859-1

Giving scope basic structure (space delimitated) allows any app developer to
store a list of scopes which they have and compare any desired scopes to
that list. While the meaning of each scope is not standardized, it allows
for this sort of simple operation on scope. 5.2.1 also defines how a
protected resource can tell the client what additional scope(s) are needed
in order to make their request successful. Standardizing the delimiter
allows for this sort of "addition" interaction.

--David



On Tue, Aug 24, 2010 at 10:41 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

>  --- p.6 terminology/authorization server
> "         A server capable of issuing tokens after successfully
>         authenticating the resource owner and obtaining authorization.
>         The authorization server may be the same server as the resource
>         server, or a separate entity. "
> Based on the discussion in
> http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html, I would
> suggest to add the following: "A single authorization server may issue
> tokens for different resource servers."
>
> --- p.11 What is the meaning of "... the authentication of the client is
> based on the user-agent's same-origin policy." ? As far as I know, this
> policy restricts the hosts the JavaScript client is allowed to interact
> with. How does this "feature" authenticate the client on the authorization
> server?
>
> --- Examples and client authentication: Since BASIC authentication is the
> default mechanisms for client authentication, I would suggest to use it in
> all examples.
>
> --- Scope syntax and usage
> The discussion in
> http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html revealed
> most WG members do not want to define the scope's syntax and semantics in
> the spec. Instead these aspects shall be kept deployment specific. Accepted.
> To me, this means the scope is specified as a placeholder/pattern only and
> not as a fullblown parameter. In contrast, the draft raises the expectation
> to specify more than that e.g. by defining delimiters and talking about
> orders on scopes (less/equal). In my opinion, we should not pretend to
> standardize something we don't really standardize. Moreover, if we want to
> give the deployments the freedom to define the scope's syntax and semantics,
> then we should not impose any needless restrictions. Here are some examples:
>
> p. 17
> scope
>         OPTIONAL.  The scope of the access request expressed as a list
>         of space-delimited strings.  ..
>
> Why is it neccessary to define a delimiter for a parameter that otherwise
> is completly left unspecified? What is the benefit? I would suggest to
> remove the delimiter definition and let the scope just be an opaque string
> that can be used by the deployment in any way. Lists of spec-delimited
> strings are one options, other deployments would probably use JSON documents
> or an elaborated scope-expression language.
>
> p.22 "If the access grant being used already
>         represents an approved scope (e.g. authorization code,
>         assertion), the requested scope MUST be equal or lesser than
>         the scope previously granted."
>
> This statement is useless without a definition of an order and equality
> among scope values. And there might also be a sets, subsets and supersets of
> scopes.
> Proposal:
> Either (a) add an clarification that equality, order, e.t.c. of scopes is
> deployment specific or (b) remove the statement.
>
> p. 33    The "scope" attribute is a space-delimited list of scope values
>   indicating the required scope of the access token for accessing the
>   requested resource."
>
> There is no explanation what a compliant client should do with the scope
> attribute value of a WWW-Authenticate header.
> Proposal:
> Either a) state that usage of the scope value is deployment specific or b)
> that the client shall pass this attribute to the respective scope parameters
> on end-user authorization and tokens endpoint or c) remove the attribute.
>
> --- section 3: "The authorization server MUST support the use of
>   the HTTP "GET" method for the end-user authorization endpoint, and
>   MAY support the use of the "POST" method as well."
>
> What is the use case behind POST on that endpoint? Is the authorization
> server expected to behave differently with respect to the redirect back to
> the client? For example, shall HTML FORM Redirection be used for the way
> back?
>
> section 4.3. In my opinion, unauthorized_client should be used on
> conjunction with status code 403.
>
> section 5.1.1. access token charset: This definition allows authorization
> server for the issuance of token, which cannot be safely passed with URI
> query parameters (e.g. they are allowd to contain "&"). But section 5.1.2
> specifies that access tokens can directly be used as such parameters. This
> may cause problems.
>
> Proposal: Either a) modify the access token charset to be URI query
> parameter compliant or b) advice resource server/clients using URI query
> parameters to additionaly URL-safe-base64-encode tokens before sending them
> to the resource server.
>
> regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--001636c5a4012d7f2f048e99b8a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Giving scope basic structure (space=A0delimitated) allows any app developer=
 to store a list of scopes which they have and compare any desired scopes t=
o that list. While the meaning of each scope is not standardized, it allows=
 for this sort of simple operation on scope. 5.2.1 also defines how a prote=
cted resource can tell the client what additional scope(s) are needed in or=
der to make their request successful. Standardizing the delimiter allows fo=
r this sort of "addition" interaction.


--David



On Tue, Aug 24, 2010 at 10:41 PM, Torsten Lodderstedt &=
lt;torsten@lodderstedt.net&g=
t; wrote:


=A0--- p.6 terminology/authorization server=


" =A0 =A0 =A0 =A0 A server capable of issuing tokens after successfull=
y

 =A0 =A0 =A0 =A0 authenticating the resource owner and obtaining authorizat=
ion.

 =A0 =A0 =A0 =A0 The authorization server may be the same server as the res=
ource

 =A0 =A0 =A0 =A0 server, or a separate entity. "

Based on the discussion in http://www.ietf.org/mail-arc=
hive/web/oauth/current/msg03812.html, I would suggest to add the follow=
ing: "A single authorization server may issue tokens for different res=
ource servers."




--- p.11 What is the meaning of "... the authentication of the client =
is based on the user-agent's same-origin policy." ? As far as I kn=
ow, this policy restricts the hosts the JavaScript client is allowed to int=
eract with. How does this "feature" authenticate the client on th=
e authorization server?




--- Examples and client authentication: Since BASIC authentication is the d=
efault mechanisms for client authentication, I would suggest to use it in a=
ll examples.



--- Scope syntax and usage

The discussion in http://www.ietf.org/mail-archive/web/=
oauth/current/msg03812.html revealed most WG members do not want to def=
ine the scope's syntax and semantics in the spec. Instead these aspects=
 shall be kept deployment specific. Accepted. To me, this means the scope i=
s specified as a placeholder/pattern only and not as a fullblown parameter.=
 In contrast, the draft raises the expectation to specify more than that e.=
g. by defining delimiters and talking about orders on scopes (less/equal). =
In my opinion, we should not pretend to standardize something we don't =
really standardize. Moreover, if we want to give the deployments the freedo=
m to define the scope's syntax and semantics, then we should not impose=
 any needless restrictions. Here are some examples:




p. 17

scope

 =A0 =A0 =A0 =A0 OPTIONAL. =A0The scope of the access request expressed as =
a list

 =A0 =A0 =A0 =A0 of space-delimited strings. =A0..



Why is it neccessary to define a delimiter for a parameter that otherwise i=
s completly left unspecified? What is the benefit? I would suggest to remov=
e the delimiter definition and let the scope just be an opaque string that =
can be used by the deployment in any way. Lists of spec-delimited strings a=
re one options, other deployments would probably use JSON documents or an e=
laborated scope-expression language.




p.22 "If the access grant being used already

 =A0 =A0 =A0 =A0 represents an approved scope (e.g. authorization code,

 =A0 =A0 =A0 =A0 assertion), the requested scope MUST be equal or lesser th=
an

 =A0 =A0 =A0 =A0 the scope previously granted."



This statement is useless without a definition of an order and equality amo=
ng scope values. And there might also be a sets, subsets and supersets of s=
copes.

Proposal:

Either (a) add an clarification that equality, order, e.t.c. of scopes is d=
eployment specific or (b) remove the statement.



p. 33 =A0 =A0The "scope" attribute is a space-delimited list of s=
cope values

 =A0 indicating the required scope of the access token for accessing the
 =A0 requested resource."



There is no explanation what a compliant client should do with the scope at=
tribute value of a WWW-Authenticate header.

Proposal:

Either a) state that usage of the scope value is deployment specific or b) =
that the client shall pass this attribute to the respective scope parameter=
s on end-user authorization and tokens endpoint or c) remove the attribute.=





--- section 3: "The authorization server MUST support the use of

 =A0 the HTTP "GET" method for the end-user authorization endpoin=
t, and

 =A0 MAY support the use of the "POST" method as well."



What is the use case behind POST on that endpoint? Is the authorization ser=
ver expected to behave differently with respect to the redirect back to the=
 client? For example, shall HTML FORM Redirection be used for the way back?=





section 4.3. In my opinion, unauthorized_client should be used on conjuncti=
on with status code 403.



section 5.1.1. access token charset: This definition allows authorization s=
erver for the issuance of token, which cannot be safely passed with URI que=
ry parameters (e.g. they are allowd to contain "&"). But sect=
ion 5.1.2 specifies that access tokens can directly be used as such paramet=
ers. This may cause problems.




Proposal: Either a) modify the access token charset to be URI query paramet=
er compliant or b) advice resource server/clients using URI query parameter=
s to additionaly URL-safe-base64-encode tokens before sending them to the r=
esource server.




regards,

Torsten.

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--001636c5a4012d7f2f048e99b8a2--

From c.stuebner@external.telekom.de  Wed Aug 25 09:19:04 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56163A6892 for ; Wed, 25 Aug 2010 09:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.39
X-Spam-Level: 
X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dytRB2UXJNI for ; Wed, 25 Aug 2010 09:19:04 -0700 (PDT)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 6B5A93A681F for ; Wed, 25 Aug 2010 09:19:02 -0700 (PDT)
Received: from g8dbse01.krf01.telekom.de ([164.23.31.9]) by tcmail51.telekom.de with ESMTP; 25 Aug 2010 18:19:30 +0200
Received: from QEO40064.de.t-online.corp (QEO40064.de.t-online.corp [10.224.209.64]) by G8DBSE01.krf01.telekom.de with ESMTP for oauth@ietf.org; Wed, 25 Aug 2010 18:19:30 +0200
Received: from QEO40072.de.t-online.corp ([fe80::1559:caa7:942b:d071]) by QEO40064.de.t-online.corp ([::1]) with mapi; Wed, 25 Aug 2010 18:19:29 +0200
From: "Stuebner, Christian (extern)" 
To: "'oauth@ietf.org'" 
Date: Wed, 25 Aug 2010 18:19:28 +0200
Thread-Topic: Web Server Flow - receiving incoming requests
Thread-Index: ActEcUpk7OAPuEtBQyCaFD4pVKpT1w==
Message-Id: 
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [OAUTH-WG] Web Server Flow - receiving incoming requests
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Aug 2010 16:23:30 -0000

I have a question regarding draft -10, section 1.4.1 - web server flow:

   "The web server profile is suitable for clients capable of interacting
   with the end-user's user-agent (typically a web browser) and capable
   of receiving incoming requests from the authorization server (capable
   of acting as an HTTP server)."

Neither figure 4 nor the sequence description below mention "receiving inco=
ming requests" again.=20
At which point is the client required to receive incoming calls? Authorizat=
ion code retrieval? Access token retrieval? Which interface should be used =
to tell the AS which URI is to be called?

In my opinion the "native application" flow covers mechanisms that could al=
so be applied to the web server flow (e.g. custom URI scheme, providing a r=
edirection URI pointing to a server-hosted resource, etc). I'm looking forw=
ard to draft -11 to see what happens to the client profiles.

Regards,
Christian =

From recordond@gmail.com  Wed Aug 25 09:47:48 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E2C53A6AD6 for ; Wed, 25 Aug 2010 09:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.457
X-Spam-Level: 
X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ49bSlOZYsF for ; Wed, 25 Aug 2010 09:47:47 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 078E63A6892 for ; Wed, 25 Aug 2010 09:47:46 -0700 (PDT)
Received: by yxk8 with SMTP id 8so319095yxk.31 for ; Wed, 25 Aug 2010 09:48:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=y3452JQ1aFoLGQ3feyGL8MV3p3SdNESlAosmaFAUPlQ=; b=flSDi42BcejQftb6n6FVLYD4fHbS09UcLF+o1YxwwS1StWQ1MveGLQPophHFwqNbxb 0/wK7r3vT1Yi8a2UW9Xy9JHAgA4C1sQ1jdUit7cHDscK5akg3WeZtL9JX2KMMNPMJ17L 6qof27QOf65OJ8QMDHJvbYLEzPtLOhEDN8RIg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PGqTG58tUQZ4Y3WEi/Un/UvQHSfa26Hkel4zpEXSlTQ6m8dcbjK630kFy9gPiCRISS iKImvzPkq2LfIUug5ASQ6JKXHwZw8wm9+nBGZYVLcl+vtgKtzBTZr8bNCwCpSj4FuE4A w4eyIhPLkitY3sNVu4eFpV0tN7JTulD7tCLLI=
MIME-Version: 1.0
Received: by 10.101.71.12 with SMTP id y12mr1980759ank.247.1282754895963; Wed, 25 Aug 2010 09:48:15 -0700 (PDT)
Received: by 10.100.225.12 with HTTP; Wed, 25 Aug 2010 09:48:15 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 25 Aug 2010 09:48:15 -0700
Message-ID: 
From: David Recordon 
To: "Stuebner, Christian (extern)" 
Content-Type: multipart/alternative; boundary=0016369fa24fe8eece048ea8a546
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Web Server Flow - receiving incoming requests
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Aug 2010 16:47:48 -0000

--0016369fa24fe8eece048ea8a546
Content-Type: text/plain; charset=ISO-8859-1

I think that the meaning here is that the client can handle the HTTP
redirect back from the authorization server. Not that the authorization
server is making a HTTP request directly to it. Agreed that it could be
clarified. :)


On Wed, Aug 25, 2010 at 9:19 AM, Stuebner, Christian (extern) <
c.stuebner@external.telekom.de> wrote:

> I have a question regarding draft -10, section 1.4.1 - web server flow:
>
>   "The web server profile is suitable for clients capable of interacting
>   with the end-user's user-agent (typically a web browser) and capable
>   of receiving incoming requests from the authorization server (capable
>   of acting as an HTTP server)."
>
> Neither figure 4 nor the sequence description below mention "receiving
> incoming requests" again.
> At which point is the client required to receive incoming calls?
> Authorization code retrieval? Access token retrieval? Which interface should
> be used to tell the AS which URI is to be called?
>
> In my opinion the "native application" flow covers mechanisms that could
> also be applied to the web server flow (e.g. custom URI scheme, providing a
> redirection URI pointing to a server-hosted resource, etc). I'm looking
> forward to draft -11 to see what happens to the client profiles.
>
> Regards,
> Christian
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

--0016369fa24fe8eece048ea8a546
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think that the meaning here is that the client can handle the HTTP redire=
ct back from the authorization server. Not that the authorization server is=
 making a HTTP request directly to it. Agreed that it could be clarified. :=
)



On Wed, Aug 25, 2010 at 9:19 AM, Stuebne=
r, Christian (extern) <c.stuebner@external.telekom.de> wrote:
=


I have a question regarding draft -10, section 1.4.1 - web server flow:



 =A0 "The web server profile is suitable for clients capable of intera=
cting

 =A0 with the end-user's user-agent (typically a web browser) and capab=
le

 =A0 of receiving incoming requests from the authorization server (capable<=
br>
 =A0 of acting as an HTTP server)."



Neither figure 4 nor the sequence description below mention "receiving=
 incoming requests" again.

At which point is the client required to receive incoming calls? Authorizat=
ion code retrieval? Access token retrieval? Which interface should be used =
to tell the AS which URI is to be called?



In my opinion the "native application" flow covers mechanisms tha=
t could also be applied to the web server flow (e.g. custom URI scheme, pro=
viding a redirection URI pointing to a server-hosted resource, etc). I'=
m looking forward to draft -11 to see what happens to the client profiles.<=
br>



Regards,

Christian

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth





--0016369fa24fe8eece048ea8a546--

From zachary.zeltsan@alcatel-lucent.com  Wed Aug 25 10:19:54 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4071E3A69A9 for ; Wed, 25 Aug 2010 10:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level: 
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7gKI-q5M0Ct for ; Wed, 25 Aug 2010 10:19:48 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id C1D6E3A68CD for ; Wed, 25 Aug 2010 10:19:48 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o7PHKGev027426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Aug 2010 12:20:16 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o7PHKFgo014688 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Aug 2010 12:20:15 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 25 Aug 2010 12:20:15 -0500
From: "Zeltsan, Zachary (Zachary)" 
To: "'David Recordon'" , "Stuebner, Christian (extern)" 
Date: Wed, 25 Aug 2010 12:20:14 -0500
Thread-Topic: [OAUTH-WG] Web Server Flow - receiving incoming requests
Thread-Index: ActEdVW+H4sThlk6S9CLN11Cw5x3yAAAFt1A
Message-ID: <5710F82C0E73B04FA559560098BF95B124FA54AB23@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B124FA54AB23USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Web Server Flow - receiving incoming requests
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Aug 2010 17:19:54 -0000

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

The client should be capable of redirecting the user agent to the authoriza=
tion server, so the client has to be an HTTP server.
The authorization server then also redirects the user agent back to the cli=
ent.
I agree that the description needs clarification. Especially the text "...a=
nd capable
  of receiving incoming requests from the authorization server (capable of =
acting as an HTTP server)". I do not see a step at which the client receive=
s a request from the authorization server. The authorization server only re=
sponds to the client's request (with the authorization token). At this poin=
t the client is acting as an HTTP client.

Zachary

________________________________
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D=
avid Recordon
Sent: Wednesday, August 25, 2010 12:48 PM
To: Stuebner, Christian (extern)
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Web Server Flow - receiving incoming requests

I think that the meaning here is that the client can handle the HTTP redire=
ct back from the authorization server. Not that the authorization server is=
 making a HTTP request directly to it. Agreed that it could be clarified. :=
)

On Wed, Aug 25, 2010 at 9:19 AM, Stuebner, Christian (extern) > wrote:
I have a question regarding draft -10, section 1.4.1 - web server flow:

  "The web server profile is suitable for clients capable of interacting
  with the end-user's user-agent (typically a web browser) and capable
  of receiving incoming requests from the authorization server (capable
  of acting as an HTTP server)."

Neither figure 4 nor the sequence description below mention "receiving inco=
ming requests" again.
At which point is the client required to receive incoming calls? Authorizat=
ion code retrieval? Access token retrieval? Which interface should be used =
to tell the AS which URI is to be called?

In my opinion the "native application" flow covers mechanisms that could al=
so be applied to the web server flow (e.g. custom URI scheme, providing a r=
edirection URI pointing to a server-hosted resource, etc). I'm looking forw=
ard to draft -11 to see what happens to the client profiles.

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


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

















The client should be capable of redire=
cting
the user agent to the authorization server, so the client has to be an HTTP
server.



The authorization server then also
redirects the user agent back to the client. 



I agree that the description needs
clarification. Especially the text “...and capable

  of receiving incoming requests from the authorization server (capabl=
e of
acting as an HTTP server)”. =
I do not see a step=
 at
which the client receives a request =
from the
authorization server. The authorization server only responds to the client&=
#8217;s
request (with the authorization token). At this point the client is acting =
as
an HTTP client.



 



Zachary



 















From:
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of David Recordon

Sent: Wednesday, August 25, =
2010
12:48 PM

To: Stuebner, Christian (ext=
ern)

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Web =
Server
Flow - receiving incoming requests






 



I think that the meaning here is that the client can handle the HTT=
P
redirect back from the authorization server. Not that the authorization ser=
ver
is making a HTTP request directly to it. Agreed that it could be clarified.=
 :)






 =







On Wed, Aug 25, 2010 at 9:19 AM, Stuebner, Christian (extern) <<=
a
href=3D"mailto:c.stuebner@external.telekom.de">c.stuebner@external.telekom.=
de>
wrote:



I have a question regarding draft -10, section 1.4.1 - web server f=
low:



  "The web server profile is suitable for clients capable of
interacting

  with the end-user's user-agent (typically a web browser) and capable=


  of receiving incoming requests from the authorization server (capabl=
e

  of acting as an HTTP server)."



Neither figure 4 nor the sequence description below mention "receiving
incoming requests" again.

At which point is the client required to receive incoming calls? Authorizat=
ion
code retrieval? Access token retrieval? Which interface should be used to t=
ell
the AS which URI is to be called?



In my opinion the "native application" flow covers mechanisms tha=
t
could also be applied to the web server flow (e.g. custom URI scheme, provi=
ding
a redirection URI pointing to a server-hosted resource, etc). I'm looking
forward to draft -11 to see what happens to the client profiles.



Regards,

Christian

_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






 












--_000_5710F82C0E73B04FA559560098BF95B124FA54AB23USNAVSXCHMBSA_--

From bcampbell@pingidentity.com  Wed Aug 25 13:14:13 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE91C3A6B64 for ; Wed, 25 Aug 2010 13:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.859
X-Spam-Level: 
X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWYXMf4kYVqg for ; Wed, 25 Aug 2010 13:13:40 -0700 (PDT)
Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id 2766F3A6B4F for ; Wed, 25 Aug 2010 13:12:50 -0700 (PDT)
Received: from source ([74.125.82.173]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTHV5Y//fqRu/VoTiL0Uv13F5QI0kyPAI@postini.com; Wed, 25 Aug 2010 13:13:24 PDT
Received: by mail-wy0-f173.google.com with SMTP id 40so1123165wyb.4 for ; Wed, 25 Aug 2010 13:13:23 -0700 (PDT)
Received: by 10.216.188.1 with SMTP id z1mr7737757wem.57.1282767202207; Wed, 25 Aug 2010 13:13:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.88.4 with HTTP; Wed, 25 Aug 2010 13:12:52 -0700 (PDT)
In-Reply-To: 
References:    
From: Brian Campbell 
Date: Wed, 25 Aug 2010 14:12:52 -0600
Message-ID: 
To: Thomas Hardjono 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: oauth 
Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML people
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Aug 2010 20:14:13 -0000

On Thu, Aug 19, 2010 at 1:41 PM, Thomas Hardjono  wrote:
> Apologies for the late comments (below).

And apologies for my late reply.


> > What about the two bullets on AuthnStatement?
> >
> > =A0 =A0o =A0If the assertion issuer authenticated the subject, the asse=
rtion
> > =A0 =A0 =A0 SHOULD contain a single  representing that
> > =A0 =A0 =A0 authentication event.
> >
> > =A0 =A0o =A0If the assertion was issued with the intention that the cli=
ent
> > act
> > =A0 =A0 =A0 autonomously on behalf of the subject, an  =
SHOULD
> > =A0 =A0 =A0 NOT be included.
>
> My first reaction on seeing the first bullet is that
> the assertion MUST (instead of SHOULD) contain
> a single  representing that authentication event.
> Not sure if this is too strong.

I'm not sure either, to be honest.  I was on the fence between
MUST/SHOULD and MUST NOT/SHOULD NOT in those two bullets respectively.
  Perhaps you are right and the stronger language is warranted.

> Secondly, is it implicit in Oauth-v2-10 that the
> Authorization Server is able to process
> XML signatures (xmldsig). I'm presuming that if
> the Authorization Server can deal with SAML assertions,
> then it can handle digital signatures.

Yeah, not all authz servers will support this, of course, but those
that do will need to be able to do XML signatures.

From bcampbell@pingidentity.com  Wed Aug 25 13:28:42 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71D5F3A68A7 for ; Wed, 25 Aug 2010 13:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.859
X-Spam-Level: 
X-Spam-Status: No, score=-5.859 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWx9bNCqgkKc for ; Wed, 25 Aug 2010 13:28:41 -0700 (PDT)
Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id E8BAA3A6B1A for ; Wed, 25 Aug 2010 13:28:40 -0700 (PDT)
Received: from source ([74.125.82.178]) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTHV9EpgPXGCycmBaTnqW/S+l5pL3dZNT@postini.com; Wed, 25 Aug 2010 13:29:14 PDT
Received: by mail-wy0-f178.google.com with SMTP id 42so1007020wyb.9 for ; Wed, 25 Aug 2010 13:29:06 -0700 (PDT)
Received: by 10.227.132.67 with SMTP id a3mr7598281wbt.198.1282768146316; Wed, 25 Aug 2010 13:29:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.88.4 with HTTP; Wed, 25 Aug 2010 13:28:36 -0700 (PDT)
In-Reply-To: 
References:  
From: Brian Campbell 
Date: Wed, 25 Aug 2010 14:28:36 -0600
Message-ID: 
To: Thomas Hardjono 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: oauth 
Subject: Re: [OAUTH-WG] SAML profile comments/questions from the SAML people
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Aug 2010 20:28:42 -0000

Again, sorry for the slow reply.

On Thu, Aug 19, 2010 at 1:52 PM, Thomas Hardjono  wrote:
>> First, concern was expressed that restricting the assertion to only
>> allow for a single  element was too limiting.
>> The restriction basically limits the ability of a single assertion to
>> be issued for use across multiple use-cases/profiles. =A0 A good example
>> is the use-case that Prateek recently brought up in a different thread
>> on this list[2] where the assertion is delivered to an SP via Web SSO
>> and then that SP uses that same assertion to acquire an access token
>> for data services at a 3rd party site. =A0 =A0As currently written,
>> draft-campbell-oauth-saml-00[3], wouldn't allow for that use-case.
>> I'm starting to think that my attempt at simplification was is indeed
>> too restrictive. =A0Allowing for more than one  wil=
l
>> make the wording in the profile a bit more complicated (as well as
>> implementing validation) but I think, in the longer term, it's probably
>> the right thing to do from a spec perspective. =A0At this point I'm
>> planning on loosening that restriction in the next draft. =A0I'm curious=
,
>> however, if anyone has any strong opinions on it one way or the other?
>
> I was under the impression that the Oauth use-case was
> intentionally made to be simple, where the client talks direct to
> the Authorization Server (not via Web-SSO and the SP,
> as in the classic SAML use-case).

It is simple in that the client talks directly to the authz server and
exchanges an assertion for an access token. However, the means by
which the client gets the assertion, who issues/signs the assertion,
and how the authz server decides to trust the assertion, are all out
of scope.  That allows for more complex use cases or deployments.

In the case Prateek mentions, for example, the client gets the
assertion via web sso from an IdP that is mutually trusted by the 3rd
party.   I don't think it's the most common use case by any means but
the profile, as I have it written now, would disallow it and that's
probably too restrictive.

> =A0Does Oauth-v2 today allow
> the Authorization Server to delegate/relegate the actual
> obtaining of the access token to a 3rd Party?

I'm not sure I follow the question?


> I think there are a large number of SAML-based use cases that
> can be interestingly "layered" atop OAuth. =A0I guess the question
> is how complex should we get in Oauth-v2. =A0Perhaps for now you
> should make the subject of the assertion be the resource owner,
> to be in-line with the basic Oauth design assumptions.

That was my thinking as well but most of the other feedback I've
gotten about it suggesting it's too restrictive.

From mscurtescu@google.com  Wed Aug 25 13:39:50 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F583A68C2 for ; Wed, 25 Aug 2010 13:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.728
X-Spam-Level: 
X-Spam-Status: No, score=-105.728 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tCnFwRksu0E for ; Wed, 25 Aug 2010 13:39:49 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 472F43A6927 for ; Wed, 25 Aug 2010 13:39:49 -0700 (PDT)
Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o7PKeKgI013480 for ; Wed, 25 Aug 2010 13:40:21 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1282768821; bh=9uH1Mp0LOrFVkWOmulAXoZhipbY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=klRWrjLfqRNp6+FGMW7++ltVHot3UYfoBHU7PPExjqQnsPOlnic8gFvpp8USSXnGm 1eN+c9/G0T7xpHM5242Sw==
Received: from gya6 (gya6.prod.google.com [10.243.49.6]) by kpbe20.cbf.corp.google.com with ESMTP id o7PKeHZK008842 for ; Wed, 25 Aug 2010 13:40:17 -0700
Received: by gya6 with SMTP id 6so394192gya.6 for ; Wed, 25 Aug 2010 13:40:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=rh+vGKrjqAJQRr/qPqJTXsTu2ALMvkNs0dJmaxlKX80=; b=gwK13zUu9xU5/tQFllJGZx23Mtc98GS78njmob6/nTBmx04hW9alxiY+P60UtYbZkw ezFfJdTRV8mHYCnQdSew==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=p9EC+ktTvDMPj5aSkZm9tXx2hL834Wilh/1VWQG1cdMToFyPRg0uPx1pe1P/+QWDu8 2EmLqzum/HRCiqt8VFmg==
Received: by 10.100.214.14 with SMTP id m14mr9781422ang.99.1282768817189; Wed, 25 Aug 2010 13:40:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.138.5 with HTTP; Wed, 25 Aug 2010 13:39:57 -0700 (PDT)
In-Reply-To: 
References: 
From: Marius Scurtescu 
Date: Wed, 25 Aug 2010 13:39:57 -0700
Message-ID: 
To: David Recordon 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Aug 2010 20:39:50 -0000

David,

Here is some feedback I received internally from Greg Robbins:

"Having "display" as an extension is useful, though considering the
trend towards tablet devices like the iPad, "touch" and "popup" seem
orthogonal rather than mutually exclusive.

It would also be nice if the client could indicate the dimensions
available for display so the server can make a smarter presentation.
Desktop, netbook, tablet, and mobile screen dimensions vary widely
now."

Marius



On Mon, Jul 12, 2010 at 12:51 PM, David Recordon  wrot=
e:
> I wrote this draft last month based on discussions on the mailing list, t=
he
> OpenID user experience extension (which Facebook, Google, and Yahoo! have
> deployed), and some OAuth 2.0 implementation experience from Facebook. It
> defines language and display preferences which the client can include in
> requests to the end-user authorization endpoint.
> A previous draft included an immediate mode=A0parameter=A0but further dis=
cussion
> has shown that it should be removed until identity information is also
> addressed. Identity is outside the scope of this particular extension.
> I'd like this draft to become a working group document and have done my b=
est
> to make it represent the group's consensus. Unfortunately the internet dr=
aft
> submission process is closed for a few weeks until after the meeting. :-\
> Thanks,
> --David
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

From cmortimore@salesforce.com  Wed Aug 25 13:55:09 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5B83A68E3 for ; Wed, 25 Aug 2010 13:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.162
X-Spam-Level: 
X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.437,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDDvBhwIeWDV for ; Wed, 25 Aug 2010 13:55:08 -0700 (PDT)
Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by core3.amsl.com (Postfix) with SMTP id 533DC3A6837 for ; Wed, 25 Aug 2010 13:55:08 -0700 (PDT)
Received: from source ([204.14.239.238]) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKTHWDTB3qpE38jp0kD1e3x55Xppey6VKU@postini.com; Wed, 25 Aug 2010 13:55:41 PDT
Received: from EXSFM-MB01.internal.salesforce.com ([10.1.127.45]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Wed, 25 Aug 2010 13:55:40 -0700
From: Chuck Mortimore 
To: Marius Scurtescu 
Date: Wed, 25 Aug 2010 13:55:32 -0700
Thread-Topic: [OAUTH-WG] Moving the User Experience Extension draft forward
Thread-Index: ActEl9/3OH7R5tl7TEeEKsQvfxb+HA==
Message-ID: <30026109-6127-4CC8-BC18-42A18CB980D9@salesforce.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Aug 2010 20:55:09 -0000

We are in support, and have implemented display

- cmort

On Aug 25, 2010, at 1:40 PM, "Marius Scurtescu"  wro=
te:

> David,
>=20
> Here is some feedback I received internally from Greg Robbins:
>=20
> "Having "display" as an extension is useful, though considering the
> trend towards tablet devices like the iPad, "touch" and "popup" seem
> orthogonal rather than mutually exclusive.
>=20
> It would also be nice if the client could indicate the dimensions
> available for display so the server can make a smarter presentation.
> Desktop, netbook, tablet, and mobile screen dimensions vary widely
> now."
>=20
> Marius
>=20
>=20
>=20
> On Mon, Jul 12, 2010 at 12:51 PM, David Recordon  wr=
ote:
>> I wrote this draft last month based on discussions on the mailing list, =
the
>> OpenID user experience extension (which Facebook, Google, and Yahoo! hav=
e
>> deployed), and some OAuth 2.0 implementation experience from Facebook. I=
t
>> defines language and display preferences which the client can include in
>> requests to the end-user authorization endpoint.
>> A previous draft included an immediate mode parameter but further discus=
sion
>> has shown that it should be removed until identity information is also
>> addressed. Identity is outside the scope of this particular extension.
>> I'd like this draft to become a working group document and have done my =
best
>> to make it represent the group's consensus. Unfortunately the internet d=
raft
>> submission process is closed for a few weeks until after the meeting. :-=
\
>> Thanks,
>> --David
>> _______________________________________________
>> 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

From bouiaw@gmail.com  Wed Aug 25 16:31:46 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0993A689B for ; Wed, 25 Aug 2010 16:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sak5mZbSWH1 for ; Wed, 25 Aug 2010 16:31:44 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 854D13A688B for ; Wed, 25 Aug 2010 16:31:44 -0700 (PDT)
Received: by qwc9 with SMTP id 9so1123359qwc.31 for ; Wed, 25 Aug 2010 16:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=YZ5/EcQh5RMS78gvELivKVtv8UqQY1p5iBFm/HwC2lg=; b=g6Egc1aVuQ3cPQPT1s93n79bOd9iicjZSqkwGlERVX/MlxckZP3pvBeSHIuRv2wBLY 9Ghn8xB2gREK0LphtiLo3Vo4xO0D2Ci33SRumEZFP4z8oMA0/Gt7GeOdFJiyau91TkX8 WVV8Kl656diGmMIOZ5ZHRcV6A351HweL2JPLs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=eq5+khIEFVUUGJ5M6u0wrZu4WhLihF2bxiEydta8Dg01CM44ATRdr/VIBK1eywWhDR RFKjFw3sp0XbCsNU69Fd4XsNYZ/HfzA7oUOp8c4XhjIskBUH4PFrlkfKgkgOOnN9ggD+ KpVCqCKGqEF1JYinFSSPYVMhvBWn2Jbx+oKqY=
MIME-Version: 1.0
Received: by 10.229.213.135 with SMTP id gw7mr6612580qcb.41.1282779136554; Wed, 25 Aug 2010 16:32:16 -0700 (PDT)
Received: by 10.229.67.156 with HTTP; Wed, 25 Aug 2010 16:32:16 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 26 Aug 2010 01:32:16 +0200
Message-ID: 
From: Bouiaw 
To: oauth@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [OAUTH-WG] Java / Javascript Implementation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Aug 2010 23:31:46 -0000

Hi,

We are making good progress on our open source Java implementation of
OAuth2, as a part of RESThub (http://resthub.org) framework.

Source code and unit tests :
http://bitbucket.org/ilabs/resthub/src/tip/resthub-oauth2/
Documentation : http://bitbucket.org/ilabs/resthub/wiki/Security

We have completed the implementation of a custom profile that follow
OAuth2 draft 10 specification, and we plan to implement User Agent
profile next month (both Java and Javasript sides).

Even if it still work in progress, is it possible to be listed on
http://wiki.oauth.net/OAuth%202 as Java server implementation ?

Regards

On Fri, Jul 2, 2010 at 11:31 AM, Damien Feugas  wrote:
> Hello everyone.
>
> Sebastien and I are working on a java framework for building REST
> distributed application.
> This project is named RESThub, and hosted on bitbucket. Feel free to have a
> look.
>
> For security and authentication purposes, we plan to provide an OpenID
> Connect and OAuth v2 implementation during this summer.
> We'd like to start with the "user-agent client profile".
> We choose on client side JQuery and on server side a combination of Servlet
> filters and Spring security to build our implementation.
>
> We are searching for starter kits on both sides, or people already involved
> in the process of implementing the specification.
> We'll be happy to share code and ideas !!
>
> Damien
>

From darren@cliqset.com  Thu Aug 26 07:51:20 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE533A69D5 for ; Thu, 26 Aug 2010 07:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.619
X-Spam-Level: 
X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.358,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Src-RwW8uXt for ; Thu, 26 Aug 2010 07:51:18 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id F1F493A69B8 for ; Thu, 26 Aug 2010 07:51:17 -0700 (PDT)
Received: by bwz9 with SMTP id 9so1397366bwz.31 for ; Thu, 26 Aug 2010 07:51:49 -0700 (PDT)
Received: by 10.204.72.209 with SMTP id n17mr6583266bkj.52.1282834308941; Thu, 26 Aug 2010 07:51:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.101.148 with HTTP; Thu, 26 Aug 2010 07:51:27 -0700 (PDT)
In-Reply-To: 
References: 
From: Darren Bounds 
Date: Thu, 26 Aug 2010 10:51:27 -0400
Message-ID: 
To: OAuth WG 
Content-Type: text/plain; charset=UTF-8
Subject: Re: [OAUTH-WG] Gowalla ships an API using Draft 8
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Aug 2010 14:51:20 -0000

Shameless plug. The latest release of our Cliqset API implements
support for the Draft 10 User-Agent and Native Application profiles.

http://developer.cliqset.com/api


On Mon, Aug 9, 2010 at 2:41 PM, David Recordon  wrote:
> http://gowalla.com/api/docs/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>



-- 
darren bounds
darren@cliqset.com

From lvh@laurensvh.be  Fri Aug 27 10:38:00 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238AD3A686E for ; Fri, 27 Aug 2010 10:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.207
X-Spam-Level: 
X-Spam-Status: No, score=-1.207 tagged_above=-999 required=5 tests=[AWL=0.769,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+En9Ll-SvB1 for ; Fri, 27 Aug 2010 10:37:59 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 29C423A6843 for ; Fri, 27 Aug 2010 10:37:57 -0700 (PDT)
Received: by qwc9 with SMTP id 9so3236653qwc.31 for ; Fri, 27 Aug 2010 10:38:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.61.86 with SMTP id s22mr739873qch.204.1282930709540; Fri, 27 Aug 2010 10:38:29 -0700 (PDT)
Received: by 10.229.21.200 with HTTP; Fri, 27 Aug 2010 10:38:29 -0700 (PDT)
Date: Fri, 27 Aug 2010 19:38:29 +0200
Message-ID: 
From: Laurens Van Houtven 
To: OAuth WG 
Content-Type: multipart/alternative; boundary=0016e653963236ae27048ed1951f
Subject: [OAUTH-WG] Duplication of client identifier in different credentials formats
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2010 17:38:00 -0000

--0016e653963236ae27048ed1951f
Content-Type: text/plain; charset=UTF-8

Hi


2.1. Client Password Credentials

First example:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=s6BhdRkqt3&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb


Why does this contain the client identifier twice? Once in the body (in
urlencoded form), once in the Authorization header. What's the appropriate
behavior when these don't match?


thanks
lvh

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

Hi


2.1. Client Password Credentials<=
/div>

First example:

POST /token HTTP/1.1


Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Ty=
pe: application/x-www-form-urlencoded
grant_type=3Dauthorization_=
code&client_id=3Ds6BhdRkqt3&code=3Di1WsRn1uB1&
redire=
ct_uri=3Dhttps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb




Why does this contain the client i=
dentifier twice? Once in the body (in urlencoded form), once in the Authori=
zation header. What's the appropriate behavior when these don't mat=
ch?




thanks
lvh


--0016e653963236ae27048ed1951f--

From recordond@gmail.com  Fri Aug 27 13:22:58 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0FD3A67F4 for ; Fri, 27 Aug 2010 13:22:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.532
X-Spam-Level: 
X-Spam-Status: No, score=-1.532 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_20=-0.74, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdat1dvb7gfI for ; Fri, 27 Aug 2010 13:22:56 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 327C03A687B for ; Fri, 27 Aug 2010 13:22:56 -0700 (PDT)
Received: by bwz9 with SMTP id 9so2662342bwz.31 for ; Fri, 27 Aug 2010 13:23:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=i+GdFrLGnvZBrns5J2LjMUVXme4tjLfGxDioYkrRlZs=; b=V+MQwo/tkPSOX5mVO4TU1/pL7pQOHWRqIZp+wLTiiBdxaYlEJ3axoyjh+YOnHU+iBt 9KSZWnQgpI9VnYZgmrl6EsmDECHx9libXn9SBFSBxli4wKmOtTeY3WEM/0+0jIpP+8Cr +UpdvncjFpY5KgmGEmCX157TcKYCfx89HkB5Q=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DVXaXQPFnWVyr3pf8vfZ0UDR7FSwc7n8WZlDuaT+lAXCm6tvw3VbXTFEdSYhnzZbce HLC6amKGgTqlKpSmSVB3hedaS2PZUTbDyJpUv7s7TH7vBNGgLUnQW+IsRkMd898mymrc mkxpNaJNA8jF/hHi10HRuLsJG7fUMVSUpmfrA=
MIME-Version: 1.0
Received: by 10.204.127.71 with SMTP id f7mr823200bks.139.1282940607706; Fri, 27 Aug 2010 13:23:27 -0700 (PDT)
Received: by 10.204.7.139 with HTTP; Fri, 27 Aug 2010 13:23:27 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 27 Aug 2010 20:23:27 +0000
Message-ID: 
From: David Recordon 
To: Marius Scurtescu 
Content-Type: multipart/alternative; boundary=0016e6d7eef730b70e048ed3e3a0
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2010 20:22:58 -0000

--0016e6d7eef730b70e048ed3e3a0
Content-Type: text/plain; charset=ISO-8859-1

Given our implementation experience, an iPad should use "popup" as it's a
full web browser on a reasonably large screen. Android and the iPhone should
use "touch". I'd be happy to add clarifying language in the extension but am
weary about adding the complexity of the client requesting dimensions.

As a side note, this draft is now up at
http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.

--David


On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu wrote:

> David,
>
> Here is some feedback I received internally from Greg Robbins:
>
> "Having "display" as an extension is useful, though considering the
> trend towards tablet devices like the iPad, "touch" and "popup" seem
> orthogonal rather than mutually exclusive.
>
> It would also be nice if the client could indicate the dimensions
> available for display so the server can make a smarter presentation.
> Desktop, netbook, tablet, and mobile screen dimensions vary widely
> now."
>
> Marius
>
>
>
> On Mon, Jul 12, 2010 at 12:51 PM, David Recordon 
> wrote:
> > I wrote this draft last month based on discussions on the mailing list,
> the
> > OpenID user experience extension (which Facebook, Google, and Yahoo! have
> > deployed), and some OAuth 2.0 implementation experience from Facebook. It
> > defines language and display preferences which the client can include in
> > requests to the end-user authorization endpoint.
> > A previous draft included an immediate mode parameter but further
> discussion
> > has shown that it should be removed until identity information is also
> > addressed. Identity is outside the scope of this particular extension.
> > I'd like this draft to become a working group document and have done my
> best
> > to make it represent the group's consensus. Unfortunately the internet
> draft
> > submission process is closed for a few weeks until after the meeting. :-\
> > Thanks,
> > --David
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>

--0016e6d7eef730b70e048ed3e3a0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Given our implementation experience, an iPad should use "popup" a=
s it's a full web browser on a=A0reasonably=A0large screen. Android and=
 the iPhone should use "touch". I'd be happy to add clarifyin=
g language in the extension but am weary about adding the complexity of the=
 client requesting dimensions.


As a side note, this draft is now up at=A0http://tools.ietf.org/ht=
ml/draft-recordon-oauth-v2-ux-00.

--David



On Wed, Aug 25, 2010 at 8:39 PM, Ma=
rius Scurtescu <mscurtescu@google.com> wrote:

David,



Here is some feedback I received internally from Greg Robbins:



"Having "display" as an extension is useful, though consider=
ing the

trend towards tablet devices like the iPad, "touch" and "pop=
up" seem

orthogonal rather than mutually exclusive.



It would also be nice if the client could indicate the dimensions

available for display so the server can make a smarter presentation.

Desktop, netbook, tablet, and mobile screen dimensions vary widely

now."



Marius








On Mon, Jul 12, 2010 at 12:51 PM, David Recordon <recordond@gmail.com> wrote:

> I wrote this draft last month based on discussions on the mailing list=
, the

> OpenID user experience extension (which Facebook, Google, and Yahoo! h=
ave

> deployed), and some OAuth 2.0 implementation experience from Facebook.=
 It

> defines language and display preferences which the client can include =
in

> requests to the end-user authorization endpoint.

> A previous draft included an immediate mode=A0parameter=A0but further =
discussion

> has shown that it should be removed until identity information is also=


> addressed. Identity is outside the scope of this particular extension.=


> I'd like this draft to become a working group document and have do=
ne my best

> to make it represent the group's consensus. Unfortunately the inte=
rnet draft

> submission process is closed for a few weeks until after the meeting. =
:-\

> Thanks,

> --David


> ________________________=
_______________________

> OAuth mailing list

> OAuth@ietf.org

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

>

>





--0016e6d7eef730b70e048ed3e3a0--

From recordond@gmail.com  Fri Aug 27 13:25:59 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6113A68AF for ; Fri, 27 Aug 2010 13:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXG77Dd8Nl9m for ; Fri, 27 Aug 2010 13:25:58 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 13FBB3A67F4 for ; Fri, 27 Aug 2010 13:25:57 -0700 (PDT)
Received: by bwz9 with SMTP id 9so2664392bwz.31 for ; Fri, 27 Aug 2010 13:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=+YLj+kXNtcCFCi66VBnkZWnMYIHBExrTGQbe4rhoTPM=; b=GKLo9zNdEs13soynOq1zWaWe/URQ4fl6RA1C6iUG6h1n87pcnObCdGexVdOdRy2rpK kLwmHNttqutBsW6ltRXjEFHlt6p4eaDQbcvnTJwkxBCa7XzyLY4bk/TOzil7iV1kGH/k ezW0AyzZnW8u8iwzCjjggUi8tJoUg4nL8umgA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=recyMdPgiV2G5+Uw+uUJxUz4NvKHvvsGkVO7uaiMZnnMkMyKtNoHnprEEsD9+p+q3P 1lTXdkJg4YifBd9ir4RIcJnyIsNuYqnuE9lUnUGJciiyc3LuQRhVpq/u8yACdzjc+Urn i0rdVbnm/a0+JgoJjQlUHiGZCAA2hCn28tLM8=
MIME-Version: 1.0
Received: by 10.204.98.141 with SMTP id q13mr864064bkn.128.1282940789594; Fri, 27 Aug 2010 13:26:29 -0700 (PDT)
Received: by 10.204.7.139 with HTTP; Fri, 27 Aug 2010 13:26:29 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 27 Aug 2010 20:26:29 +0000
Message-ID: 
From: David Recordon 
To: OAuth WG 
Content-Type: multipart/alternative; boundary=001485f85a94081b4d048ed3ee4d
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2010 20:25:59 -0000

--001485f85a94081b4d048ed3ee4d
Content-Type: text/plain; charset=ISO-8859-1

This draft is now an Internet Draft and I'm curious if anyone has any
feedback on it?
http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00

I'd also like to request that this draft moves to become a Working Group
item. I'm am happy to act as the editor unless someone else wishes to do so
moving forward.

Thanks,
--David


On Mon, Jul 12, 2010 at 10:39 PM, David Recordon wrote:

> The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access
> tokens has come up on the list a few times. Attached is a draft assertion
> format which allows a client to trade an OAuth 1.0 token/secret pair for an
> OAuth 2.0 access token. The assertion format is a JSON object with values
> for the token and token secret. My goal is that this draft become a working
> group document.
>
> A question for the group is if upgrading multiple tokens at once is
> a necessary use case? The assertion format within the core spec only
> supports issuing a single access token. Facebook has a custom endpoint which
> allows upgrading multiple tokens at once, but I don't actually have data
> about how many developers make use of that functionality.
>
> Thanks,
> --David
>

--001485f85a94081b4d048ed3ee4d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This draft is now an Internet Draft and I'm curious if anyone has any f=
eedback on it?=A0http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-=
00


I'd also like to request that this draft moves to become=
 a Working Group item. I'm am happy to act as the editor unless someone=
 else wishes to do so moving forward.

Thanks,

--David


On Mon, Jul 12, 2=
010 at 10:39 PM, David Recordon <recordond@gmail.com> wrote:

The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access tok=
ens has come up on the list a few times. Attached is a draft assertion form=
at which allows a client to trade an OAuth 1.0 token/secret pair for an OAu=
th 2.0 access token. The assertion format is a JSON object with values for =
the token and token secret. My goal is that this draft become a working gro=
up document.



A question for the group is if upgrading multiple tokens at =
once is a=A0necessary=A0use case? The assertion format within the core spec=
 only supports issuing a single access token. Facebook has a custom endpoin=
t which allows upgrading multiple tokens at once, but I don't actually =
have data about how many developers make use of that functionality.




Thanks,
--David





--001485f85a94081b4d048ed3ee4d--

From recordond@gmail.com  Fri Aug 27 13:26:44 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4983A687B for ; Fri, 27 Aug 2010 13:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level: 
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZsoov5BHLtu for ; Fri, 27 Aug 2010 13:26:43 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 95C363A67F4 for ; Fri, 27 Aug 2010 13:26:42 -0700 (PDT)
Received: by bwz9 with SMTP id 9so2664830bwz.31 for ; Fri, 27 Aug 2010 13:27:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=SHT1S2FmGnHQD9j7xExSheSUuz4rll2KW+aaUsXG+JY=; b=ZdyMC2o+moXr5F0MlL8u7gHWvCx0FmbQJcXMZyi4kMTcBslL/UErDi2rbbVzcMCW5g R7yCDTD8eDsiwfpHJ2UdeqEEkestpPjhaNq5qrxga42Ft7S2j3XUUTNuN+br8kpXDF54 iybFrWXJUYSwyeJcPTc6i7dQ1HM9uCPVJmNrw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XC/wW/rMoiX15jq83JZJ0Ig29l37JZBdtO5o692sIgY9J0EWYAB0wFxEL5osbYxXKl gp/UiAlljYFUO14HdTr6r8n2OR+NmLgg3N8c8oPQFV7AQQy7p8p74UREyAZ8W2AIOmBI SiePXaDbhin6tTUNJz5tHS0rK369ucEAgaYWQ=
MIME-Version: 1.0
Received: by 10.204.76.205 with SMTP id d13mr889794bkk.93.1282940833455; Fri, 27 Aug 2010 13:27:13 -0700 (PDT)
Received: by 10.204.7.139 with HTTP; Fri, 27 Aug 2010 13:27:13 -0700 (PDT)
In-Reply-To: 
References:   
Date: Fri, 27 Aug 2010 20:27:13 +0000
Message-ID: 
From: David Recordon 
To: OAuth WG 
Content-Type: multipart/alternative; boundary=00163649a2f5a55d21048ed3f080
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2010 20:26:44 -0000

--00163649a2f5a55d21048ed3f080
Content-Type: text/plain; charset=ISO-8859-1

And to follow that up, I'd like to request that this draft moves to become a
Working Group item. I'm am happy to continue acting as the editor.


On Fri, Aug 27, 2010 at 8:23 PM, David Recordon  wrote:

> Given our implementation experience, an iPad should use "popup" as it's a
> full web browser on a reasonably large screen. Android and the iPhone should
> use "touch". I'd be happy to add clarifying language in the extension but am
> weary about adding the complexity of the client requesting dimensions.
>
> As a side note, this draft is now up at
> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.
>
> --David
>
>
> On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu wrote:
>
>> David,
>>
>> Here is some feedback I received internally from Greg Robbins:
>>
>> "Having "display" as an extension is useful, though considering the
>> trend towards tablet devices like the iPad, "touch" and "popup" seem
>> orthogonal rather than mutually exclusive.
>>
>> It would also be nice if the client could indicate the dimensions
>> available for display so the server can make a smarter presentation.
>> Desktop, netbook, tablet, and mobile screen dimensions vary widely
>> now."
>>
>> Marius
>>
>>
>>
>> On Mon, Jul 12, 2010 at 12:51 PM, David Recordon 
>> wrote:
>> > I wrote this draft last month based on discussions on the mailing list,
>> the
>> > OpenID user experience extension (which Facebook, Google, and Yahoo!
>> have
>> > deployed), and some OAuth 2.0 implementation experience from Facebook.
>> It
>> > defines language and display preferences which the client can include in
>> > requests to the end-user authorization endpoint.
>> > A previous draft included an immediate mode parameter but further
>> discussion
>> > has shown that it should be removed until identity information is also
>> > addressed. Identity is outside the scope of this particular extension.
>> > I'd like this draft to become a working group document and have done my
>> best
>> > to make it represent the group's consensus. Unfortunately the internet
>> draft
>> > submission process is closed for a few weeks until after the meeting.
>> :-\
>> > Thanks,
>> > --David
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> >
>>
>
>

--00163649a2f5a55d21048ed3f080
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

And to follow that up,=A0I'd like to request th=
at this draft moves to become a Working Group item. I'm am happy to con=
tinue acting as the editor.


On Fri, =
Aug 27, 2010 at 8:23 PM, David Recordon <recordond@gmail.com> wrote:


Given our implementation experience, an iPa=
d should use "popup" as it's a full web browser on a=A0reason=
ably=A0large screen. Android and the iPhone should use "touch". I=
'd be happy to add clarifying language in the extension but am weary ab=
out adding the complexity of the client requesting dimensions.



As a side note, this draft is now up at=A0http:/=
/tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.



--David




On Wed, Aug 25, 2010 at 8:39 PM, Ma=
rius Scurtescu <mscurtescu@google.com> wrote:


David,



Here is some feedback I received internally from Greg Robbins:



"Having "display" as an extension is useful, though consider=
ing the

trend towards tablet devices like the iPad, "touch" and "pop=
up" seem

orthogonal rather than mutually exclusive.



It would also be nice if the client could indicate the dimensions

available for display so the server can make a smarter presentation.

Desktop, netbook, tablet, and mobile screen dimensions vary widely

now."



Marius








On Mon, Jul 12, 2010 at 12:51 PM, David Recordon <recordond@gmail.com> wrote:

> I wrote this draft last month based on discussions on the mailing list=
, the

> OpenID user experience extension (which Facebook, Google, and Yahoo! h=
ave

> deployed), and some OAuth 2.0 implementation experience from Facebook.=
 It

> defines language and display preferences which the client can include =
in

> requests to the end-user authorization endpoint.

> A previous draft included an immediate mode=A0parameter=A0but further =
discussion

> has shown that it should be removed until identity information is also=


> addressed. Identity is outside the scope of this particular extension.=


> I'd like this draft to become a working group document and have do=
ne my best

> to make it represent the group's consensus. Unfortunately the inte=
rnet draft

> submission process is closed for a few weeks until after the meeting. =
:-\

> Thanks,

> --David


> _____________________________________=
__________

> OAuth mailing list

> OAuth@ietf.org=


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

>

>








--00163649a2f5a55d21048ed3f080--

From recordond@gmail.com  Fri Aug 27 13:28:33 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C15A3A68F3 for ; Fri, 27 Aug 2010 13:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLjCe2p3K-yR for ; Fri, 27 Aug 2010 13:28:32 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 80B243A687B for ; Fri, 27 Aug 2010 13:28:31 -0700 (PDT)
Received: by bwz9 with SMTP id 9so2666047bwz.31 for ; Fri, 27 Aug 2010 13:29:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xGfKi6tEakWpiIYcwq2nJLFxojgQnafELxOOx9ZjMyA=; b=GqDw43muLo+nFTEP1KIVRpyo+Tar6mgQ5qETwRpfN48wQBngUnI6mpbUILCJpBZ8cL 7sJw89l0nGRizn9Rl8aYAGvbShZZlrwwFhuPXQjJ33GyWFrsLdnfimnMPzOxuziK1eMP rklePX/dp5DK8FYeo0jMSaTnol2k9Rd4PCIck=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sJwNwHJZnVcKeHG4xbxYeBpKPv4WEwQ/fr7asItBAbCVmKeb55XRjgnHemXzl3M0yz p6rpdaoK+h9FqagsEFQIwwNWoMSP0l/KI6BchO79l4HFL+mD5mTcCvGFmPsL1pxpCOqA 0opCkJE1+iua5TCWIb7j8nGeonFuqbMhK2nO4=
MIME-Version: 1.0
Received: by 10.204.69.18 with SMTP id x18mr892652bki.34.1282940942927; Fri, 27 Aug 2010 13:29:02 -0700 (PDT)
Received: by 10.204.7.139 with HTTP; Fri, 27 Aug 2010 13:29:02 -0700 (PDT)
In-Reply-To: 
References:  <5710F82C0E73B04FA559560098BF95B124F9688DD4@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>   
Date: Fri, 27 Aug 2010 20:29:02 +0000
Message-ID: 
From: David Recordon 
To: OAuth WG 
Content-Type: multipart/alternative; boundary=001636c5b38f2bc84b048ed3f785
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" 
Subject: Re: [OAUTH-WG] Device profile draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2010 20:28:33 -0000

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

While it's been a few weeks, I've made these changes and posted the Device
profile as an Internet Draft:
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00. We're working
on an implementation at Facebook and hope to provide feedback toward the
next draft.

In the meantime I'd like to request that it move to become a Working Group
item. I'm am happy to continue acting as the editor.

--David


On Thu, Jul 15, 2010 at 9:41 PM, David Recordon  wrote=
:

> Even better, thanks!
>
>
> On Thu, Jul 15, 2010 at 2:31 PM, Michael D Adams wro=
te:
>
>> On Thu, Jul 15, 2010 at 2:11 PM, David Recordon 
>> wrote:
>> > On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)
>> >> =93The client makes the following request at an arbitrary but reasona=
ble
>> >> interval which MUST NOT exceed the minimum interval rate provided by
>> >>   the authorization server (if present via the "interval" parameter).=
=94
>> >>
>> >> My understanding is that the intervals between the client=92s subsequ=
ent
>> >> requests must not be less than the value provided by the =93interval=
=94
>> >> parameter (if it is present). If that is correct than the intervals
>> between
>> >> the subsequent requests MUST exceed (or be equal to) the value of the
>> >> =93interval=94 parameter.
>> >
>> > Thanks! Reworded to "The client makes the following request at an
>> arbitrary
>> > but reasonable interval which MUST NOT be less than the minimum interv=
al
>> > rate provided by the authorization server"
>>
>> It still sounds confusing to me.  Part of the problem is that we're
>> talking both about an interval (a length of time) and a frequency
>> (requests per unit of time).
>>
>> How about:
>>
>> The client makes the next request after an arbitrary but reasonable
>> length of time, which MUST be longer than or equal to the minimum
>> length of time provided by the authorization server in the "interval"
>> parameter if present.
>>
>>
>> I changed "following" to "next" because the former makes it sound like
>> the next paragraph will have details about the request.
>>
>> I changed "at an arbitrary" to "after an arbitrary" since we're
>> talking here about lengths of time.
>>
>> I replaced "interval" with "length of time" to make it clear we're
>> talking about the length of time and not the corresponding frequency.
>>
>> Mike
>> --mdawaffe
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>

--001636c5b38f2bc84b048ed3f785
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

While it's been a few weeks, I've made these changes and posted the=
 Device profile as an Internet Draft:=A0http://tools.ietf.org/html/draft-reco=
rdon-oauth-v2-device-00. We're working on an implementation at Face=
book and hope to provide feedback toward the next draft.


In the meantime I'd like to request that it move to beco=
me a Working Group item. I'm am happy to continue acting as the editor.=


--David



On Thu, Jul 15, 2010 at 9:41 PM, David Recordon <recordond@gmail.com> wrote:=


Even better, thanks!


On Thu, Jul 15, 2010 at 2:31 PM, Michael D Adams <mike@aut=
omattic.com> wrote:




On Thu, Jul 15, 2010 at 2:11 PM, David Recordon <recordond@gmail.com> wrote:
> On Thu, Jul 15, 2010 at 1:36 PM, Zeltsan, Zachary (Zachary)


>> =93The client makes the following request at an arbitra=
ry but reasonable

>> interval which MUST NOT exceed the minimum interval rate provided =
by

>> =A0=A0the authorization server (if present via the "interval&=
quot; parameter).=94

>>

>> My understanding is that the intervals between the client=92s subs=
equent

>> requests must not be less than the value provided by the =93interv=
al=94

>> parameter (if it is present). If that is correct than the interval=
s between

>> the subsequent requests MUST exceed (or be equal to) the value of =
the

>> =93interval=94 parameter.

>

> Thanks! Reworded to "The client makes the following request at an=
 arbitrary

> but reasonable interval which=A0MUST NOT be less than the minimum inte=
rval

> rate provided by the authorization server"




It still sounds confusing to me. =A0Part of the problem is that we=
9;re

talking both about an interval (a length of time) and a frequency

(requests per unit of time).



How about:



The client makes the next request after an arbitrary but reasonable

length of time, which MUST be longer than or equal to the minimum

length of time provided by the authorization server in the "interval&q=
uot;

parameter if present.





I changed "following" to "next" because the former make=
s it sound like

the next paragraph will have details about the request.



I changed "at an arbitrary" to "after an arbitrary" sin=
ce we're

talking here about lengths of time.



I replaced "interval" with "length of time" to make it =
clear we're

talking about the length of time and not the corresponding frequency.



Mike

--mdawaffe


_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth








--001636c5b38f2bc84b048ed3f785--

From jricher@mitre.org  Fri Aug 27 13:36:48 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5F03A68AF for ; Fri, 27 Aug 2010 13:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.484
X-Spam-Level: 
X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR57Z+s9uMtL for ; Fri, 27 Aug 2010 13:36:46 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id A78993A687E for ; Fri, 27 Aug 2010 13:36:46 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7RKbH2v029800 for ; Fri, 27 Aug 2010 16:37:17 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7RKbHsb029797;  Fri, 27 Aug 2010 16:37:17 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Fri, 27 Aug 2010 16:37:17 -0400
From: Justin Richer 
To: David Recordon 
In-Reply-To: 
References:   
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 27 Aug 2010 16:37:16 -0400
Message-ID: <1282941436.23839.112.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2010 20:36:48 -0000

Does the group have an opinion on adding the instance information that I
proposed before* to this UX extension vs. having it live in its own
extension? 

 -- Justin

* http://www.ietf.org/mail-archive/web/oauth/current/msg03717.html

On Fri, 2010-08-27 at 16:23 -0400, David Recordon wrote:
> Given our implementation experience, an iPad should use "popup" as
> it's a full web browser on a reasonably large screen. Android and the
> iPhone should use "touch". I'd be happy to add clarifying language in
> the extension but am weary about adding the complexity of the client
> requesting dimensions.
> 
> 
> As a side note, this draft is now up
> at http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.
> 
> 
> --David
> 
> 
> On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu
>  wrote:
>         David,
>         
>         Here is some feedback I received internally from Greg Robbins:
>         
>         "Having "display" as an extension is useful, though
>         considering the
>         trend towards tablet devices like the iPad, "touch" and
>         "popup" seem
>         orthogonal rather than mutually exclusive.
>         
>         It would also be nice if the client could indicate the
>         dimensions
>         available for display so the server can make a smarter
>         presentation.
>         Desktop, netbook, tablet, and mobile screen dimensions vary
>         widely
>         now."
>         
>         Marius
>         
>         
>         
>         
>         On Mon, Jul 12, 2010 at 12:51 PM, David Recordon
>          wrote:
>         > I wrote this draft last month based on discussions on the
>         mailing list, the
>         > OpenID user experience extension (which Facebook, Google,
>         and Yahoo! have
>         > deployed), and some OAuth 2.0 implementation experience from
>         Facebook. It
>         > defines language and display preferences which the client
>         can include in
>         > requests to the end-user authorization endpoint.
>         > A previous draft included an immediate mode parameter but
>         further discussion
>         > has shown that it should be removed until identity
>         information is also
>         > addressed. Identity is outside the scope of this particular
>         extension.
>         > I'd like this draft to become a working group document and
>         have done my best
>         > to make it represent the group's consensus. Unfortunately
>         the internet draft
>         > submission process is closed for a few weeks until after the
>         meeting. :-\
>         > Thanks,
>         > --David
>         
>         
>         > _______________________________________________
>         > OAuth mailing list
>         > OAuth@ietf.org
>         > https://www.ietf.org/mailman/listinfo/oauth
>         >
>         >
>         
> 
> 



From eran@hueniverse.com  Fri Aug 27 15:46:09 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548603A68AF for ; Fri, 27 Aug 2010 15:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level: 
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5erUp3wgONkD for ; Fri, 27 Aug 2010 15:46:08 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1F6BE3A68CE for ; Fri, 27 Aug 2010 15:46:07 -0700 (PDT)
Received: (qmail 26091 invoked from network); 27 Aug 2010 22:46:39 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Aug 2010 22:46:38 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 27 Aug 2010 15:46:39 -0700
From: Eran Hammer-Lahav 
To: David Recordon , OAuth WG 
Date: Fri, 27 Aug 2010 15:46:28 -0700
Thread-Topic: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
Thread-Index: ActGJie2wFiUG8TnRGuHoOkO0AGaMgAE3+Bg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F2BB8E0@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3F2BB8E0P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2010 22:46:09 -0000

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

+1 on making this a WG item.

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D=
avid Recordon
Sent: Friday, August 27, 2010 1:26 PM
To: OAuth WG
Cc: Tschofenig, Hannes (NSN - FI/Espoo)
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension

This draft is now an Internet Draft and I'm curious if anyone has any feedb=
ack on it? http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00

I'd also like to request that this draft moves to become a Working Group it=
em. I'm am happy to act as the editor unless someone else wishes to do so m=
oving forward.

Thanks,
--David

On Mon, Jul 12, 2010 at 10:39 PM, David Recordon > wrote:
The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access tok=
ens has come up on the list a few times. Attached is a draft assertion form=
at which allows a client to trade an OAuth 1.0 token/secret pair for an OAu=
th 2.0 access token. The assertion format is a JSON object with values for =
the token and token secret. My goal is that this draft become a working gro=
up document.

A question for the group is if upgrading multiple tokens at once is a neces=
sary use case? The assertion format within the core spec only supports issu=
ing a single access token. Facebook has a custom endpoint which allows upgr=
ading multiple tokens at once, but I don't actually have data about how man=
y developers make use of that functionality.

Thanks,
--David


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


+1 on mak=
ing this a WG item.
 
EHL
 
From: oauth-bounces@ietf.org [mailto:oauth-bou=
nces@ietf.org] On Behalf Of David Recordon
Sent: Friday, A=
ugust 27, 2010 1:26 PM
To: OAuth WG
Cc: Tschofenig, Han=
nes (NSN - FI/Espoo)
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgr=
ade Extension
 
This draft is now an Internet Draft and I'm curious if anyone has any fee=
dback on it? http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade=
-00
=
 
I'd also like to request that this draft moves to become a Working Gro=
up item. I'm am happy to act as the editor unless someone else wishes to do=
 so moving forward.
 
Thanks,
--David
 
On Mon, Jul 12, 2010 at 10:39 PM, David Recordon <=
recordond@gmail.com> wrote:
The ability to=
 upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access tokens has come u=
p on the list a few times. Attached is a draft assertion format which allow=
s a client to trade an OAuth 1.0 token/secret pair for an OAuth 2.0 access =
token. The assertion format is a JSON object with values for the token and =
token secret. My goal is that this draft become a working group document.
&nbs=
p;
A qu=
estion for the group is if upgrading multiple tokens at once is a nece=
ssary use case? The assertion format within the core spec only support=
s issuing a single access token. Facebook has a custom endpoint which allow=
s upgrading multiple tokens at once, but I don't actually have data about h=
ow many developers make use of that functionality.
 
Thanks,
--David
&nb=
sp;
=

--_000_90C41DD21FB7C64BB94121FBBC2E72343B3F2BB8E0P3PW5EX1MB01E_--

From eran@hueniverse.com  Fri Aug 27 15:46:50 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1203A6934 for ; Fri, 27 Aug 2010 15:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level: 
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.118,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KCOKLEKjMMV for ; Fri, 27 Aug 2010 15:46:49 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 37CBC3A68AF for ; Fri, 27 Aug 2010 15:46:49 -0700 (PDT)
Received: (qmail 26416 invoked from network); 27 Aug 2010 22:47:21 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Aug 2010 22:47:20 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 27 Aug 2010 15:47:20 -0700
From: Eran Hammer-Lahav 
To: David Recordon , OAuth WG 
Date: Fri, 27 Aug 2010 15:47:10 -0700
Thread-Topic: [OAUTH-WG] Moving the User Experience Extension draft forward
Thread-Index: ActGJj+xC3mK18x+R3q4BGKozj908QAE3oxA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F2BB8E3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E72343B3F2BB8E3P3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Aug 2010 22:46:50 -0000

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

+1 on making this a WG item (as well as the device draft).

EHL

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D=
avid Recordon
Sent: Friday, August 27, 2010 1:27 PM
To: OAuth WG
Cc: Tschofenig, Hannes (NSN - FI/Espoo)
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward

And to follow that up, I'd like to request that this draft moves to become =
a Working Group item. I'm am happy to continue acting as the editor.

On Fri, Aug 27, 2010 at 8:23 PM, David Recordon > wrote:
Given our implementation experience, an iPad should use "popup" as it's a f=
ull web browser on a reasonably large screen. Android and the iPhone should=
 use "touch". I'd be happy to add clarifying language in the extension but =
am weary about adding the complexity of the client requesting dimensions.

As a side note, this draft is now up at http://tools.ietf.org/html/draft-re=
cordon-oauth-v2-ux-00.

--David

On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu > wrote:
David,

Here is some feedback I received internally from Greg Robbins:

"Having "display" as an extension is useful, though considering the
trend towards tablet devices like the iPad, "touch" and "popup" seem
orthogonal rather than mutually exclusive.

It would also be nice if the client could indicate the dimensions
available for display so the server can make a smarter presentation.
Desktop, netbook, tablet, and mobile screen dimensions vary widely
now."

Marius



On Mon, Jul 12, 2010 at 12:51 PM, David Recordon > wrote:
> I wrote this draft last month based on discussions on the mailing list, t=
he
> OpenID user experience extension (which Facebook, Google, and Yahoo! have
> deployed), and some OAuth 2.0 implementation experience from Facebook. It
> defines language and display preferences which the client can include in
> requests to the end-user authorization endpoint.
> A previous draft included an immediate mode parameter but further discuss=
ion
> has shown that it should be removed until identity information is also
> addressed. Identity is outside the scope of this particular extension.
> I'd like this draft to become a working group document and have done my b=
est
> to make it represent the group's consensus. Unfortunately the internet dr=
aft
> submission process is closed for a few weeks until after the meeting. :-\
> Thanks,
> --David
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>



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


+1 on mak=
ing this a WG item (as well as the device draft).
 
EHL
 =

From: oauth-boun=
ces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of David Reco=
rdon
Sent: Friday, August 27, 2010 1:27 PM
To: OAuth WG=

Cc: Tschofenig, Hannes (NSN - FI/Espoo)
Subject: Re: [=
OAUTH-WG] Moving the User Experience Extension draft forward
 
And to follow that up,&nbs=
p;I'd like to request that this draft moves to become a Working Group item.=
 I'm am happy to continue acting as the editor.
 
On Fri, Aug 27, 2010 at 8:23 PM, David Recordon &l=
t;recordond@gmail.com> wrote:=

Given our im=
plementation experience, an iPad should use "popup" as it's a ful=
l web browser on a reasonably large screen. Android and the iPhon=
e should use "touch". I'd be happy to add clarifying language in =
the extension but am weary about adding the complexity of the client reques=
ting dimensions.
 
As a side note, this draft is now up at http=
://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.
 
--David
 
On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu =
<mscurtescu@g=
oogle.com> wrote:
David,

Here is some feedback I received internally from =
Greg Robbins:

"Having "display" as an extension is us=
eful, though considering the
trend towards tablet devices like the iPad,=
 "touch" and "popup" seem
orthogonal rather than mut=
ually exclusive.

It would also be nice if the client could indicate =
the dimensions
available for display so the server can make a smarter pr=
esentation.
Desktop, netbook, tablet, and mobile screen dimensions vary =
widely
now."

Marius


On Mon, Jul 12, 2010 at 12:51 PM, David Recordon <recordond@gmail.com> wrote:=

> I wrote this draft last month based on discussions on the mailing =
list, the
> OpenID user experience extension (which Facebook, Google,=
 and Yahoo! have
> deployed), and some OAuth 2.0 implementation exper=
ience from Facebook. It
> defines language and display preferences wh=
ich the client can include in
> requests to the end-user authorizatio=
n endpoint.
> A previous draft included an immediate mode parame=
ter but further discussion
> has shown that it should be removed=
 until identity information is also
> addressed. Identity is outside =
the scope of this particular extension.
> I'd like this draft to beco=
me a working group document and have done my best
> to make it repres=
ent the group's consensus. Unfortunately the internet draft
> submiss=
ion process is closed for a few weeks until after the meeting. :-\
> =
Thanks,
> --David
> _____________________________________=
__________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailm=
an/listinfo/oauth
>
>
 
 
=

--_000_90C41DD21FB7C64BB94121FBBC2E72343B3F2BB8E3P3PW5EX1MB01E_--

From recordond@gmail.com  Fri Aug 27 19:05:38 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99BD93A677C for ; Fri, 27 Aug 2010 19:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.451
X-Spam-Level: 
X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVv41LXE8dKA for ; Fri, 27 Aug 2010 19:05:37 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A74593A65A5 for ; Fri, 27 Aug 2010 19:05:36 -0700 (PDT)
Received: by bwz9 with SMTP id 9so2851259bwz.31 for ; Fri, 27 Aug 2010 19:06:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=R9ySYSyf+6CnEqnZeCjE/nWUBgAQVnYEfnLeS7EsnWM=; b=VOefWOFdahA+JcD+VzAaqDqwMeb9KYeOLq50DG7ZDB+0qbMVwvD3pkfT+F+955lhQW zvfZWuWzLM1Yr18WPb8F5uGgw01+SSDnDZ29//jLPMEpo3Ca0DEeF7qhnWNLd14mJ1fg p00WOLMfWP/p2xqSJBPijnKKXyEoC0oJidlcs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wv/tsknWXLx8xEKTPAC2tYuUedXYzH6ENj7kLJVPYGdVFBfY4Jy2qlp+JT4Vgezlfv +EBJjprk97hfcmXp1LCGPhhCw7+fMvXxFmjdFfgy224q3iFiSMHt1s4IUT26TqxnJRpg ZEyI7bxJR3PYPqg9NYMOWkE3fw5BFVuqh5h2U=
MIME-Version: 1.0
Received: by 10.204.75.132 with SMTP id y4mr1028149bkj.130.1282961167873; Fri, 27 Aug 2010 19:06:07 -0700 (PDT)
Received: by 10.204.7.139 with HTTP; Fri, 27 Aug 2010 19:06:07 -0700 (PDT)
In-Reply-To: <1282941436.23839.112.camel@localhost.localdomain>
References:    <1282941436.23839.112.camel@localhost.localdomain>
Date: Sat, 28 Aug 2010 02:06:07 +0000
Message-ID: 
From: David Recordon 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=0016e6d7787cabf59c048ed8ac91
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2010 02:05:38 -0000

--0016e6d7787cabf59c048ed8ac91
Content-Type: text/plain; charset=ISO-8859-1

Hey Justin, what's a good example of where the instance name parameter would
be used? Desktop apps like TweetDeck just ask me to authorize "TweetDesk"
and don't separate between my laptop and desktop. Another example would be
our Facebook mobile apps but "Facebook for iPhone" has a different client id
than "Facebook for Android".


On Fri, Aug 27, 2010 at 8:37 PM, Justin Richer  wrote:

> Does the group have an opinion on adding the instance information that I
> proposed before* to this UX extension vs. having it live in its own
> extension?
>
>  -- Justin
>
> * http://www.ietf.org/mail-archive/web/oauth/current/msg03717.html
>
> On Fri, 2010-08-27 at 16:23 -0400, David Recordon wrote:
> > Given our implementation experience, an iPad should use "popup" as
> > it's a full web browser on a reasonably large screen. Android and the
> > iPhone should use "touch". I'd be happy to add clarifying language in
> > the extension but am weary about adding the complexity of the client
> > requesting dimensions.
> >
> >
> > As a side note, this draft is now up
> > at http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.
> >
> >
> > --David
> >
> >
> > On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu
> >  wrote:
> >         David,
> >
> >         Here is some feedback I received internally from Greg Robbins:
> >
> >         "Having "display" as an extension is useful, though
> >         considering the
> >         trend towards tablet devices like the iPad, "touch" and
> >         "popup" seem
> >         orthogonal rather than mutually exclusive.
> >
> >         It would also be nice if the client could indicate the
> >         dimensions
> >         available for display so the server can make a smarter
> >         presentation.
> >         Desktop, netbook, tablet, and mobile screen dimensions vary
> >         widely
> >         now."
> >
> >         Marius
> >
> >
> >
> >
> >         On Mon, Jul 12, 2010 at 12:51 PM, David Recordon
> >          wrote:
> >         > I wrote this draft last month based on discussions on the
> >         mailing list, the
> >         > OpenID user experience extension (which Facebook, Google,
> >         and Yahoo! have
> >         > deployed), and some OAuth 2.0 implementation experience from
> >         Facebook. It
> >         > defines language and display preferences which the client
> >         can include in
> >         > requests to the end-user authorization endpoint.
> >         > A previous draft included an immediate mode parameter but
> >         further discussion
> >         > has shown that it should be removed until identity
> >         information is also
> >         > addressed. Identity is outside the scope of this particular
> >         extension.
> >         > I'd like this draft to become a working group document and
> >         have done my best
> >         > to make it represent the group's consensus. Unfortunately
> >         the internet draft
> >         > submission process is closed for a few weeks until after the
> >         meeting. :-\
> >         > Thanks,
> >         > --David
> >
> >
> >         > _______________________________________________
> >         > OAuth mailing list
> >         > OAuth@ietf.org
> >         > https://www.ietf.org/mailman/listinfo/oauth
> >         >
> >         >
> >
> >
> >
>
>
>

--0016e6d7787cabf59c048ed8ac91
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Justin, what's a good example of where the instance name parameter =
would be used? Desktop apps like TweetDeck just ask me to authorize "T=
weetDesk" and don't separate between my laptop and desktop. Anothe=
r example would be our Facebook mobile apps but "Facebook for iPhone&q=
uot; has a different client id than "Facebook for Android".



On Fri, Aug 27, 2010 at 8:37 PM, Justin =
Richer <jricher@m=
itre.org> wrote:

Does the group have an opinion on adding the instance information that I
proposed before* to this UX extension vs. having it live in its own

extension?



=A0-- Justin



* http://www.ietf.org/mail-archive/web/oauth/current/ms=
g03717.html




On Fri, 2010-08-27 at 16:23 -0400, David Recordon wrote:

> Given our implementation experience, an iPad should use "popup&qu=
ot; as

> it's a full web browser on a reasonably large screen. Android and =
the

> iPhone should use "touch". I'd be happy to add clarifyin=
g language in

> the extension but am weary about adding the complexity of the client
> requesting dimensions.

>

>

> As a side note, this draft is now up

> at http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-0=
0.

>

>

> --David

>

>

> On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu

> <mscurtescu@google.com=
> wrote:

> =A0 =A0 =A0 =A0 David,

>

> =A0 =A0 =A0 =A0 Here is some feedback I received internally from Greg =
Robbins:

>

> =A0 =A0 =A0 =A0 "Having "display" as an extension is us=
eful, though

> =A0 =A0 =A0 =A0 considering the

> =A0 =A0 =A0 =A0 trend towards tablet devices like the iPad, "touc=
h" and

> =A0 =A0 =A0 =A0 "popup" seem

> =A0 =A0 =A0 =A0 orthogonal rather than mutually exclusive.

>

> =A0 =A0 =A0 =A0 It would also be nice if the client could indicate the=


> =A0 =A0 =A0 =A0 dimensions

> =A0 =A0 =A0 =A0 available for display so the server can make a smarter=


> =A0 =A0 =A0 =A0 presentation.

> =A0 =A0 =A0 =A0 Desktop, netbook, tablet, and mobile screen dimensions=
 vary

> =A0 =A0 =A0 =A0 widely

> =A0 =A0 =A0 =A0 now."

>

> =A0 =A0 =A0 =A0 Marius

>

>

>

>

> =A0 =A0 =A0 =A0 On Mon, Jul 12, 2010 at 12:51 PM, David Recordon

> =A0 =A0 =A0 =A0 <recordond@g=
mail.com> wrote:

> =A0 =A0 =A0 =A0 > I wrote this draft last month based on discussion=
s on the

> =A0 =A0 =A0 =A0 mailing list, the

> =A0 =A0 =A0 =A0 > OpenID user experience extension (which Facebook,=
 Google,

> =A0 =A0 =A0 =A0 and Yahoo! have

> =A0 =A0 =A0 =A0 > deployed), and some OAuth 2.0 implementation expe=
rience from

> =A0 =A0 =A0 =A0 Facebook. It

> =A0 =A0 =A0 =A0 > defines language and display preferences which th=
e client

> =A0 =A0 =A0 =A0 can include in

> =A0 =A0 =A0 =A0 > requests to the end-user authorization endpoint.<=
br>
> =A0 =A0 =A0 =A0 > A previous draft included an immediate mode param=
eter but

> =A0 =A0 =A0 =A0 further discussion

> =A0 =A0 =A0 =A0 > has shown that it should be removed until identit=
y

> =A0 =A0 =A0 =A0 information is also

> =A0 =A0 =A0 =A0 > addressed. Identity is outside the scope of this =
particular

> =A0 =A0 =A0 =A0 extension.

> =A0 =A0 =A0 =A0 > I'd like this draft to become a working group=
 document and

> =A0 =A0 =A0 =A0 have done my best

> =A0 =A0 =A0 =A0 > to make it represent the group's consensus. U=
nfortunately

> =A0 =A0 =A0 =A0 the internet draft

> =A0 =A0 =A0 =A0 > submission process is closed for a few weeks unti=
l after the

> =A0 =A0 =A0 =A0 meeting. :-\

> =A0 =A0 =A0 =A0 > Thanks,

> =A0 =A0 =A0 =A0 > --David

>

>

> =A0 =A0 =A0 =A0 > _______________________________________________
> =A0 =A0 =A0 =A0 > OAuth mailing list

> =A0 =A0 =A0 =A0 > OAuth@ietf.org<=
/a>

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

> =A0 =A0 =A0 =A0 >

>

>

>









--0016e6d7787cabf59c048ed8ac91--

From torsten@lodderstedt.net  Sat Aug 28 11:07:47 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB703A68AE for ; Sat, 28 Aug 2010 11:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.067
X-Spam-Level: 
X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.181,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3A766wYIv4hD for ; Sat, 28 Aug 2010 11:07:45 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 7E5A13A686E for ; Sat, 28 Aug 2010 11:07:44 -0700 (PDT)
Received: from p4ffd2ea1.dip.t-dialin.net ([79.253.46.161] helo=[127.0.0.1]) by smtprelay02.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OpPp9-0001oi-8f; Sat, 28 Aug 2010 20:08:15 +0200
Message-ID: <4C795083.1060704@lodderstedt.net>
Date: Sat, 28 Aug 2010 20:08:03 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: David Recordon 
References:  <4C4EBA47.6000700@lodderstedt.net>
In-Reply-To: <4C4EBA47.6000700@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------010406000102010003040009"
X-Df-Sender: 141509
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2010 18:07:47 -0000

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

  David,

any opinion on screen orientation and size?

regards,
Torsten.

Am 27.07.2010 12:51, schrieb Torsten Lodderstedt:
> If I understand your proposal correctly, you assume the clients knows 
> better than the authz server how to fit the client presentation 
> capabilities the best.
>
> Wouldn't it be neccessary to also tell the authz server the screen 
> orientation and available size?
>
> regards,
> Torsten.
>
> Am 12.07.2010 21:51, schrieb David Recordon:
>> I wrote this draft last month based on discussions on the mailing 
>> list, the OpenID user experience extension (which Facebook, Google, 
>> and Yahoo! have deployed), and some OAuth 2.0 implementation 
>> experience from Facebook. It defines language and display preferences 
>> which the client can include in requests to the end-user 
>> authorization endpoint.
>>
>> A previous draft included an immediate mode parameter but further 
>> discussion has shown that it should be removed until identity 
>> information is also addressed. Identity is outside the scope of this 
>> particular extension.
>>
>> I'd like this draft to become a working group document and have done 
>> my best to make it represent the group's consensus. Unfortunately the 
>> internet draft submission process is closed for a few weeks until 
>> after the meeting. :-\
>>
>> Thanks,
>> --David
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>    
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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



  
    
  
  
    David,

    

    any opinion on screen orientation and size?

    

    regards,

    Torsten.

    

    Am 27.07.2010 12:51, schrieb Torsten Lodderstedt:
    

      
      If I understand your proposal correctly, you assume the clients
      knows
      better than the authz server how to fit the client presentation
      capabilities the best.

      

      Wouldn't it be neccessary to also tell the authz server the screen
      orientation and available size?

      

      regards,

      Torsten. 

      

      Am 12.07.2010 21:51, schrieb David Recordon:
      
I wrote this draft last month based on discussions
        on the
        mailing list, the OpenID user experience extension (which
        Facebook,
        Google, and Yahoo! have deployed), and some OAuth 2.0
        implementation
        experience from Facebook. It defines language and display
        preferences
        which the client can include in requests to the end-user
        authorization
        endpoint.
        


        

        
A previous draft included an immediate mode parameter but
          further discussion has shown that it should be removed until
          identity
          information is also addressed. Identity is outside the scope
          of this
          particular extension.

        


        

        
I'd like this draft to become a working group document and
          have
          done my best to make it represent the group's consensus.
          Unfortunately
          the internet draft submission process is closed for a few
          weeks until
          after the meeting. :-\

        


        

        
Thanks,

        
--David

        

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

      

      

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


    

  


--------------010406000102010003040009--


From recordond@gmail.com  Sat Aug 28 11:20:17 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3146E3A694D for ; Sat, 28 Aug 2010 11:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.455
X-Spam-Level: 
X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.143,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv+c3hDz9WlD for ; Sat, 28 Aug 2010 11:20:16 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B2CC43A68AE for ; Sat, 28 Aug 2010 11:20:15 -0700 (PDT)
Received: by bwz9 with SMTP id 9so3290972bwz.31 for ; Sat, 28 Aug 2010 11:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=08vQphZw4jVv2AWUICervOJ5LWgVND4MfHSEuzZ5My8=; b=p+56C72uBgwTZ97K4ht0LDcYtuQLKLNEhzsVW2725d20P7gkJTDNlmT/wHGbLSNaNN k2zIA5kpMTQKak36Od2fJjaSUK+G5auoFLTZrYQL3huNpQnl2+9cNY0WrRAatvDTgHQD qGUtm3PuPLu6uukULeComWbMO+Q7GJEoSJ3CM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PM2c5NJp+5irYaq5vcNuUmVRJ9CfgEi3TDeVQCWY1ziRTyqb/gdGHePekNMNwle22C NNRjVkzeZscTFf1I1bCXVhm3hS/hyjstyRunVgGx4e22+FG4DoY1G0J6k7XMRBKaoDAp rwFwOG+BGVvj17ZI2VAfa6sMRhKJgkunAeXVQ=
MIME-Version: 1.0
Received: by 10.204.35.5 with SMTP id n5mr1637464bkd.155.1283019646656; Sat, 28 Aug 2010 11:20:46 -0700 (PDT)
Received: by 10.204.7.139 with HTTP; Sat, 28 Aug 2010 11:20:46 -0700 (PDT)
In-Reply-To: <4C795083.1060704@lodderstedt.net>
References:  <4C4EBA47.6000700@lodderstedt.net> <4C795083.1060704@lodderstedt.net>
Date: Sat, 28 Aug 2010 11:20:46 -0700
Message-ID: 
From: David Recordon 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=0003255590ae4760b3048ee64ad9
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2010 18:20:17 -0000

--0003255590ae4760b3048ee64ad9
Content-Type: text/plain; charset=ISO-8859-1

I guess my reply is similar to Marius. We haven't had a need for it yet in
our production deployment.


On Sat, Aug 28, 2010 at 11:08 AM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

>  David,
>
> any opinion on screen orientation and size?
>
> regards,
> Torsten.
>
> Am 27.07.2010 12:51, schrieb Torsten Lodderstedt:
>
> If I understand your proposal correctly, you assume the clients knows
> better than the authz server how to fit the client presentation capabilities
> the best.
>
> Wouldn't it be neccessary to also tell the authz server the screen
> orientation and available size?
>
> regards,
> Torsten.
>
> Am 12.07.2010 21:51, schrieb David Recordon:
>
> I wrote this draft last month based on discussions on the mailing list, the
> OpenID user experience extension (which Facebook, Google, and Yahoo! have
> deployed), and some OAuth 2.0 implementation experience from Facebook. It
> defines language and display preferences which the client can include in
> requests to the end-user authorization endpoint.
>
>  A previous draft included an immediate mode parameter but further
> discussion has shown that it should be removed until identity information is
> also addressed. Identity is outside the scope of this particular extension.
>
>  I'd like this draft to become a working group document and have done my
> best to make it represent the group's consensus. Unfortunately the internet
> draft submission process is closed for a few weeks until after the meeting.
> :-\
>
>  Thanks,
> --David
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>

--0003255590ae4760b3048ee64ad9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I guess my reply is similar to Marius. We haven't had a need for it yet=
 in our production deployment.


On Sa=
t, Aug 28, 2010 at 11:08 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:




 =20
   =20
 =20
  

    David,

    

    any opinion on screen orientation and size?

    

    regards,

    Torsten.

    

    Am 27.07.2010 12:51, schrieb Torsten Lodderstedt:
    

     =20
      If I understand your proposal correctly, you assume the clients
      knows
      better than the authz server how to fit the client presentation
      capabilities the best.

      

      Wouldn't it be neccessary to also tell the authz server the scree=
n
      orientation and available size?

      

      regards,

      Torsten. 

      

      Am 12.07.2010 21:51, schrieb David Recordon:
      
I wrote this draft last month based on disc=
ussions
        on the
        mailing list, the OpenID user experience extension (which
        Facebook,
        Google, and Yahoo! have deployed), and some OAuth 2.0
        implementation
        experience from Facebook. It defines language and display
        preferences
        which the client can include in requests to the end-user
        authorization
        endpoint.
        


        

        
A previous draft included an immediate mode=A0parameter=A0but
          further discussion has shown that it should be removed until
          identity
          information is also addressed. Identity is outside the scope
          of this
          particular extension.

        


        

        
I'd like this draft to become a working group document and
          have
          done my best to make it represent the group's consensus.
          Unfortunately
          the internet draft submission process is closed for a few
          weeks until
          after the meeting. :-\

        


        

        
Thanks,

        
--David

        

_______________________________________________
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


    

  






--0003255590ae4760b3048ee64ad9--

From torsten@lodderstedt.net  Sat Aug 28 11:37:57 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DDF23A6918 for ; Sat, 28 Aug 2010 11:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.071
X-Spam-Level: 
X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.177,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vReEa9GOB1CG for ; Sat, 28 Aug 2010 11:37:55 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id 3E3573A6899 for ; Sat, 28 Aug 2010 11:37:54 -0700 (PDT)
Received: from p4ffd2ea1.dip.t-dialin.net ([79.253.46.161] helo=[127.0.0.1]) by smtprelay01.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OpQIK-0007VK-S2; Sat, 28 Aug 2010 20:38:24 +0200
Message-ID: <4C79579E.1010906@lodderstedt.net>
Date: Sat, 28 Aug 2010 20:38:22 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: David Recordon 
References: <4C744AAD.3050309@lodderstedt.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050103080002010804020602"
X-Df-Sender: 141509
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] comments/questions on draft 10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2010 18:37:57 -0000

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

  I think a bit more then just defining the delimiter is required in 
order to make things work as you described (in a interoperable way).

5.2.1 states "The "scope" attribute is a space-delimited list of scope 
values indicating the required scope of the access token for accessing 
the requested resource."

So in my understanding the resource may indicate the scope required for 
access, no word about addition. There is no relation stated to the scope 
associated with a insufficient token sent to a resource.

Even if this attribute would contain a scope diff, some more questions 
are open: How does the client know what scope values from different 
WWW-Authenticate headers can be combined? Moreover, the draft does not 
support to extend a token's scope. So how should the client use that 
knowledge? Kick-off another authorization process?

regards,
Torsten.

Am 25.08.2010 00:59, schrieb David Recordon:
> Giving scope basic structure (space delimitated) allows any app 
> developer to store a list of scopes which they have and compare any 
> desired scopes to that list. While the meaning of each scope is not 
> standardized, it allows for this sort of simple operation on scope. 
> 5.2.1 also defines how a protected resource can tell the client what 
> additional scope(s) are needed in order to make their request 
> successful. Standardizing the delimiter allows for this sort of 
> "addition" interaction.
>
> --David
>
>
>
> On Tue, Aug 24, 2010 at 10:41 PM, Torsten Lodderstedt 
> > wrote:
>
>      --- p.6 terminology/authorization server
>     "         A server capable of issuing tokens after successfully
>             authenticating the resource owner and obtaining authorization.
>             The authorization server may be the same server as the
>     resource
>             server, or a separate entity. "
>     Based on the discussion in
>     http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html,
>     I would suggest to add the following: "A single authorization
>     server may issue tokens for different resource servers."
>
>     --- p.11 What is the meaning of "... the authentication of the
>     client is based on the user-agent's same-origin policy." ? As far
>     as I know, this policy restricts the hosts the JavaScript client
>     is allowed to interact with. How does this "feature" authenticate
>     the client on the authorization server?
>
>     --- Examples and client authentication: Since BASIC authentication
>     is the default mechanisms for client authentication, I would
>     suggest to use it in all examples.
>
>     --- Scope syntax and usage
>     The discussion in
>     http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html
>     revealed most WG members do not want to define the scope's syntax
>     and semantics in the spec. Instead these aspects shall be kept
>     deployment specific. Accepted. To me, this means the scope is
>     specified as a placeholder/pattern only and not as a fullblown
>     parameter. In contrast, the draft raises the expectation to
>     specify more than that e.g. by defining delimiters and talking
>     about orders on scopes (less/equal). In my opinion, we should not
>     pretend to standardize something we don't really standardize.
>     Moreover, if we want to give the deployments the freedom to define
>     the scope's syntax and semantics, then we should not impose any
>     needless restrictions. Here are some examples:
>
>     p. 17
>     scope
>             OPTIONAL.  The scope of the access request expressed as a list
>             of space-delimited strings.  ..
>
>     Why is it neccessary to define a delimiter for a parameter that
>     otherwise is completly left unspecified? What is the benefit? I
>     would suggest to remove the delimiter definition and let the scope
>     just be an opaque string that can be used by the deployment in any
>     way. Lists of spec-delimited strings are one options, other
>     deployments would probably use JSON documents or an elaborated
>     scope-expression language.
>
>     p.22 "If the access grant being used already
>             represents an approved scope (e.g. authorization code,
>             assertion), the requested scope MUST be equal or lesser than
>             the scope previously granted."
>
>     This statement is useless without a definition of an order and
>     equality among scope values. And there might also be a sets,
>     subsets and supersets of scopes.
>     Proposal:
>     Either (a) add an clarification that equality, order, e.t.c. of
>     scopes is deployment specific or (b) remove the statement.
>
>     p. 33    The "scope" attribute is a space-delimited list of scope
>     values
>       indicating the required scope of the access token for accessing the
>       requested resource."
>
>     There is no explanation what a compliant client should do with the
>     scope attribute value of a WWW-Authenticate header.
>     Proposal:
>     Either a) state that usage of the scope value is deployment
>     specific or b) that the client shall pass this attribute to the
>     respective scope parameters on end-user authorization and tokens
>     endpoint or c) remove the attribute.
>
>     --- section 3: "The authorization server MUST support the use of
>       the HTTP "GET" method for the end-user authorization endpoint, and
>       MAY support the use of the "POST" method as well."
>
>     What is the use case behind POST on that endpoint? Is the
>     authorization server expected to behave differently with respect
>     to the redirect back to the client? For example, shall HTML FORM
>     Redirection be used for the way back?
>
>     section 4.3. In my opinion, unauthorized_client should be used on
>     conjunction with status code 403.
>
>     section 5.1.1. access token charset: This definition allows
>     authorization server for the issuance of token, which cannot be
>     safely passed with URI query parameters (e.g. they are allowd to
>     contain "&"). But section 5.1.2 specifies that access tokens can
>     directly be used as such parameters. This may cause problems.
>
>     Proposal: Either a) modify the access token charset to be URI
>     query parameter compliant or b) advice resource server/clients
>     using URI query parameters to additionaly URL-safe-base64-encode
>     tokens before sending them to the resource server.
>
>     regards,
>     Torsten.
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>

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



  
    
  
  
    I think a bit more then just defining the delimiter is required in
    order to make things work as you described (in a interoperable way).

    

    5.2.1 states "The "scope" attribute is a space-delimited list of
    scope values indicating the required scope of the access token for
    accessing the requested resource."

    

    So in my understanding the resource may indicate the scope required
    for access, no word about addition. There is no relation stated to
    the scope associated with a insufficient token sent to a resource.

    

    Even if this attribute would contain a scope diff, some more
    questions are open: How does the client know what scope values from
    different WWW-Authenticate headers can be combined? Moreover, the
    draft does not support to extend a token's scope. So how should the
    client use that knowledge? Kick-off another authorization process?

    

    regards,

    Torsten.

    

    Am 25.08.2010 00:59, schrieb David Recordon:
    
Giving scope basic structure (space delimitated)
      allows any app developer to store a list of scopes which they have
      and compare any desired scopes to that list. While the meaning of
      each scope is not standardized, it allows for this sort of simple
      operation on scope. 5.2.1 also defines how a protected resource
      can tell the client what additional scope(s) are needed in order
      to make their request successful. Standardizing the delimiter
      allows for this sort of "addition" interaction.
      

        

      

      
--David

      


        


          

          
On Tue, Aug 24, 2010 at 10:41 PM,
            Torsten Lodderstedt <torsten@lodderstedt.net>
            wrote:

            
 --- p.6 terminology/authorization
              server

              "         A server capable of issuing tokens after
              successfully

                      authenticating the resource owner and obtaining
              authorization.

                      The authorization server may be the same server as
              the resource

                      server, or a separate entity. "

              Based on the discussion in http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html,
              I would suggest to add the following: "A single
              authorization server may issue tokens for different
              resource servers."

              

              --- p.11 What is the meaning of "... the authentication of
              the client is based on the user-agent's same-origin
              policy." ? As far as I know, this policy restricts the
              hosts the JavaScript client is allowed to interact with.
              How does this "feature" authenticate the client on the
              authorization server?

              

              --- Examples and client authentication: Since BASIC
              authentication is the default mechanisms for client
              authentication, I would suggest to use it in all examples.

              

              --- Scope syntax and usage

              The discussion in http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html
              revealed most WG members do not want to define the scope's
              syntax and semantics in the spec. Instead these aspects
              shall be kept deployment specific. Accepted. To me, this
              means the scope is specified as a placeholder/pattern only
              and not as a fullblown parameter. In contrast, the draft
              raises the expectation to specify more than that e.g. by
              defining delimiters and talking about orders on scopes
              (less/equal). In my opinion, we should not pretend to
              standardize something we don't really standardize.
              Moreover, if we want to give the deployments the freedom
              to define the scope's syntax and semantics, then we should
              not impose any needless restrictions. Here are some
              examples:

              

              p. 17

              scope

                      OPTIONAL.  The scope of the access request
              expressed as a list

                      of space-delimited strings.  ..

              

              Why is it neccessary to define a delimiter for a parameter
              that otherwise is completly left unspecified? What is the
              benefit? I would suggest to remove the delimiter
              definition and let the scope just be an opaque string that
              can be used by the deployment in any way. Lists of
              spec-delimited strings are one options, other deployments
              would probably use JSON documents or an elaborated
              scope-expression language.

              

              p.22 "If the access grant being used already

                      represents an approved scope (e.g. authorization
              code,

                      assertion), the requested scope MUST be equal or
              lesser than

                      the scope previously granted."

              

              This statement is useless without a definition of an order
              and equality among scope values. And there might also be a
              sets, subsets and supersets of scopes.

              Proposal:

              Either (a) add an clarification that equality, order,
              e.t.c. of scopes is deployment specific or (b) remove the
              statement.

              

              p. 33    The "scope" attribute is a space-delimited list
              of scope values

                indicating the required scope of the access token for
              accessing the

                requested resource."

              

              There is no explanation what a compliant client should do
              with the scope attribute value of a WWW-Authenticate
              header.

              Proposal:

              Either a) state that usage of the scope value is
              deployment specific or b) that the client shall pass this
              attribute to the respective scope parameters on end-user
              authorization and tokens endpoint or c) remove the
              attribute.

              

              --- section 3: "The authorization server MUST support the
              use of

                the HTTP "GET" method for the end-user authorization
              endpoint, and

                MAY support the use of the "POST" method as well."

              

              What is the use case behind POST on that endpoint? Is the
              authorization server expected to behave differently with
              respect to the redirect back to the client? For example,
              shall HTML FORM Redirection be used for the way back?

              

              section 4.3. In my opinion, unauthorized_client should be
              used on conjunction with status code 403.

              

              section 5.1.1. access token charset: This definition
              allows authorization server for the issuance of token,
              which cannot be safely passed with URI query parameters
              (e.g. they are allowd to contain "&"). But section
              5.1.2 specifies that access tokens can directly be used as
              such parameters. This may cause problems.

              

              Proposal: Either a) modify the access token charset to be
              URI query parameter compliant or b) advice resource
              server/clients using URI query parameters to additionaly
              URL-safe-base64-encode tokens before sending them to the
              resource server.

              

              regards,

              Torsten.

              _______________________________________________

              OAuth mailing list

              OAuth@ietf.org

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

            

          

          

        

      

    

  


--------------050103080002010804020602--


From torsten@lodderstedt.net  Sat Aug 28 11:45:09 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 270533A693E for ; Sat, 28 Aug 2010 11:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.076
X-Spam-Level: 
X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.172,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgsjTYhOVZUW for ; Sat, 28 Aug 2010 11:45:08 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id B9CBE3A693B for ; Sat, 28 Aug 2010 11:45:07 -0700 (PDT)
Received: from p4ffd2ea1.dip.t-dialin.net ([79.253.46.161] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OpQPJ-0005oA-DS; Sat, 28 Aug 2010 20:45:37 +0200
Message-ID: <4C795950.3090303@lodderstedt.net>
Date: Sat, 28 Aug 2010 20:45:36 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: David Recordon 
References: 	<4C4EBA47.6000700@lodderstedt.net>	<4C795083.1060704@lodderstedt.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050801030505000305020106"
X-Df-Sender: 141509
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2010 18:45:09 -0000

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

  So your login forms e.t.c. are the same for horicontal (e.g. iPad) and 
vertical (e.g. iPhone/normal operation) orientation?

what posting of Marius do you refer to?

regards,
Torsten.

Am 28.08.2010 20:20, schrieb David Recordon:
> I guess my reply is similar to Marius. We haven't had a need for it 
> yet in our production deployment.
>
>
> On Sat, Aug 28, 2010 at 11:08 AM, Torsten Lodderstedt 
> > wrote:
>
>     David,
>
>     any opinion on screen orientation and size?
>
>     regards,
>     Torsten.
>
>     Am 27.07.2010 12:51, schrieb Torsten Lodderstedt:
>>     If I understand your proposal correctly, you assume the clients
>>     knows better than the authz server how to fit the client
>>     presentation capabilities the best.
>>
>>     Wouldn't it be neccessary to also tell the authz server the
>>     screen orientation and available size?
>>
>>     regards,
>>     Torsten.
>>
>>     Am 12.07.2010 21:51, schrieb David Recordon:
>>>     I wrote this draft last month based on discussions on the
>>>     mailing list, the OpenID user experience extension (which
>>>     Facebook, Google, and Yahoo! have deployed), and some OAuth 2.0
>>>     implementation experience from Facebook. It defines language and
>>>     display preferences which the client can include in requests to
>>>     the end-user authorization endpoint.
>>>
>>>     A previous draft included an immediate mode parameter but
>>>     further discussion has shown that it should be removed until
>>>     identity information is also addressed. Identity is outside the
>>>     scope of this particular extension.
>>>
>>>     I'd like this draft to become a working group document and have
>>>     done my best to make it represent the group's consensus.
>>>     Unfortunately the internet draft submission process is closed
>>>     for a few weeks until after the meeting. :-\
>>>
>>>     Thanks,
>>>     --David
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     OAuth@ietf.org  
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>        
>>
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org  
>>     https://www.ietf.org/mailman/listinfo/oauth
>
>

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



  
    
  
  
    So your login forms e.t.c. are the same for horicontal (e.g. iPad)
    and vertical (e.g. iPhone/normal operation) orientation?

    

    what posting of Marius do you refer to?

    

    regards,

    Torsten.

    

    Am 28.08.2010 20:20, schrieb David Recordon:
    
I guess my reply is similar to Marius. We haven't had
      a need for it yet in our production deployment.
      


        

        
On Sat, Aug 28, 2010 at 11:08 AM,
          Torsten Lodderstedt <torsten@lodderstedt.net>
          wrote:

          

            
 David,

              

              any opinion on screen orientation and size?

              

              regards,

              Torsten.

              

              Am 27.07.2010 12:51, schrieb Torsten Lodderstedt:
              

                

                  
 If I understand your proposal
                    correctly, you assume the clients knows better than
                    the authz server how to fit the client presentation
                    capabilities the best.

                    

                    Wouldn't it be neccessary to also tell the authz
                    server the screen orientation and available size?

                    

                    regards,

                    Torsten. 

                    

                    Am 12.07.2010 21:51, schrieb David Recordon:
                    
I wrote this draft last
                      month based on discussions on the mailing list,
                      the OpenID user experience extension (which
                      Facebook, Google, and Yahoo! have deployed), and
                      some OAuth 2.0 implementation experience from
                      Facebook. It defines language and display
                      preferences which the client can include in
                      requests to the end-user authorization endpoint.
                      


                      

                      
A previous draft included an immediate
                        mode parameter but further discussion has shown
                        that it should be removed until identity
                        information is also addressed. Identity is
                        outside the scope of this particular extension.

                      


                      

                      
I'd like this draft to become a working group
                        document and have done my best to make it
                        represent the group's consensus. Unfortunately
                        the internet draft submission process is closed
                        for a few weeks until after the meeting. :-\

                      


                      

                      
Thanks,

                      
--David

                      

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

                    

                    

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


                  

                

              

            

          

        

        

      

    

  


--------------050801030505000305020106--


From torsten@lodderstedt.net  Sat Aug 28 11:45:56 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B420D3A68C0 for ; Sat, 28 Aug 2010 11:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.08
X-Spam-Level: 
X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.168,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5voJGoCcATG for ; Sat, 28 Aug 2010 11:45:55 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id 266783A693B for ; Sat, 28 Aug 2010 11:45:55 -0700 (PDT)
Received: from p4ffd2ea1.dip.t-dialin.net ([79.253.46.161] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OpQQ6-0008IX-9D; Sat, 28 Aug 2010 20:46:26 +0200
Message-ID: <4C795981.7060604@lodderstedt.net>
Date: Sat, 28 Aug 2010 20:46:25 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: David Recordon 
References: 	 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090904020401000007010505"
X-Df-Sender: 141509
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2010 18:45:56 -0000

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

  +1 on making this a WG item

Am 27.08.2010 22:23, schrieb David Recordon:
> Given our implementation experience, an iPad should use "popup" as 
> it's a full web browser on a reasonably large screen. Android and the 
> iPhone should use "touch". I'd be happy to add clarifying language in 
> the extension but am weary about adding the complexity of the client 
> requesting dimensions.
>
> As a side note, this draft is now up at 
> http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.
>
> --David
>
>
> On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu 
> > wrote:
>
>     David,
>
>     Here is some feedback I received internally from Greg Robbins:
>
>     "Having "display" as an extension is useful, though considering the
>     trend towards tablet devices like the iPad, "touch" and "popup" seem
>     orthogonal rather than mutually exclusive.
>
>     It would also be nice if the client could indicate the dimensions
>     available for display so the server can make a smarter presentation.
>     Desktop, netbook, tablet, and mobile screen dimensions vary widely
>     now."
>
>     Marius
>
>
>
>     On Mon, Jul 12, 2010 at 12:51 PM, David Recordon
>     > wrote:
>     > I wrote this draft last month based on discussions on the
>     mailing list, the
>     > OpenID user experience extension (which Facebook, Google, and
>     Yahoo! have
>     > deployed), and some OAuth 2.0 implementation experience from
>     Facebook. It
>     > defines language and display preferences which the client can
>     include in
>     > requests to the end-user authorization endpoint.
>     > A previous draft included an immediate mode parameter but
>     further discussion
>     > has shown that it should be removed until identity information
>     is also
>     > addressed. Identity is outside the scope of this particular
>     extension.
>     > I'd like this draft to become a working group document and have
>     done my best
>     > to make it represent the group's consensus. Unfortunately the
>     internet draft
>     > submission process is closed for a few weeks until after the
>     meeting. :-\
>     > Thanks,
>     > --David
>     > _______________________________________________
>     > OAuth mailing list
>     > OAuth@ietf.org 
>     > https://www.ietf.org/mailman/listinfo/oauth
>     >
>     >
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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



  
    
  
  
    +1 on making this a WG item

    

    Am 27.08.2010 22:23, schrieb David Recordon:
    
Given our implementation experience, an iPad should
      use "popup" as it's a full web browser on a reasonably large
      screen. Android and the iPhone should use "touch". I'd be happy to
      add clarifying language in the extension but am weary about adding
      the complexity of the client requesting dimensions.
      

        

      

      
As a side note, this draft is now up at http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.

      


      

      
--David

      


        

        
On Wed, Aug 25, 2010 at 8:39 PM, Marius
          Scurtescu <mscurtescu@google.com>
          wrote:

          

            David,

            

            Here is some feedback I received internally from Greg
            Robbins:

            

            "Having "display" as an extension is useful, though
            considering the

            trend towards tablet devices like the iPad, "touch" and
            "popup" seem

            orthogonal rather than mutually exclusive.

            

            It would also be nice if the client could indicate the
            dimensions

            available for display so the server can make a smarter
            presentation.

            Desktop, netbook, tablet, and mobile screen dimensions vary
            widely

            now."

            

              Marius

            
            

              


                

                

                On Mon, Jul 12, 2010 at 12:51 PM, David Recordon <recordond@gmail.com>
                wrote:

                > I wrote this draft last month based on discussions
                on the mailing list, the

                > OpenID user experience extension (which Facebook,
                Google, and Yahoo! have

                > deployed), and some OAuth 2.0 implementation
                experience from Facebook. It

                > defines language and display preferences which the
                client can include in

                > requests to the end-user authorization endpoint.

                > A previous draft included an immediate
                mode parameter but further discussion

                > has shown that it should be removed until identity
                information is also

                > addressed. Identity is outside the scope of this
                particular extension.

                > I'd like this draft to become a working group
                document and have done my best

                > to make it represent the group's consensus.
                Unfortunately the internet draft

                > submission process is closed for a few weeks until
                after the meeting. :-\

                > Thanks,

                > --David

              

            

            

              
>
                _______________________________________________

                > OAuth mailing list

                > OAuth@ietf.org

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

                >

                >

              

            

          

        

        

      

      

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


    

  


--------------090904020401000007010505--


From recordond@gmail.com  Sat Aug 28 11:48:33 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A4C73A68B9 for ; Sat, 28 Aug 2010 11:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.459
X-Spam-Level: 
X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.139,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QEwfSfIUNej for ; Sat, 28 Aug 2010 11:48:31 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 70F573A67F8 for ; Sat, 28 Aug 2010 11:48:30 -0700 (PDT)
Received: by bwz9 with SMTP id 9so3304050bwz.31 for ; Sat, 28 Aug 2010 11:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3CKhj3U6JbSxhMJoI3G1HPY7dl0okYgzHhAWEiap93Y=; b=YMd/YjXFJnxDu+NBcUTPRF3AZmjUlcVSTv6JKv8qbqcdTyTyC5/hn3atGZE1oTRuQB ObtdYp1+7AilwhNT/5S/uYo9vdozLsRydL61BmVH5fhH1IMqZ+gWXVsKElQ2PTGDtfLf 6zFgoTLu8stLjFh40gnEbeuoM9DYV1QbhETSk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aOSsAvjx0hc5WzLzqX1f8lJeZNhGRLltMOuRIpFO+TOroMV2XkigcI/L0OP8xoKM2A CYK+gp5Mah6LG34DLNSqV6hnqftoIZrGCuXITamKFdpuT9PhN17cHOqoxRZ12H8g2wuA 8zRz8prGc7b7BUs/ztkWlG4R1hPk2KEfQzAzw=
MIME-Version: 1.0
Received: by 10.204.82.137 with SMTP id b9mr1673915bkl.127.1283021338458; Sat, 28 Aug 2010 11:48:58 -0700 (PDT)
Received: by 10.204.7.139 with HTTP; Sat, 28 Aug 2010 11:48:58 -0700 (PDT)
In-Reply-To: <4C79579E.1010906@lodderstedt.net>
References: <4C744AAD.3050309@lodderstedt.net>  <4C79579E.1010906@lodderstedt.net>
Date: Sat, 28 Aug 2010 11:48:58 -0700
Message-ID: 
From: David Recordon 
To: Torsten Lodderstedt 
Content-Type: multipart/alternative; boundary=0016e6db6c281e3fd1048ee6afb4
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] comments/questions on draft 10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2010 18:48:33 -0000

--0016e6db6c281e3fd1048ee6afb4
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Aug 28, 2010 at 11:38 AM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

>  I think a bit more then just defining the delimiter is required in order
> to make things work as you described (in a interoperable way).
>
> 5.2.1 states "The "scope" attribute is a space-delimited list of scope
> values indicating the required scope of the access token for accessing the
> requested resource."
>
> So in my understanding the resource may indicate the scope required for
> access, no word about addition.
>

The deployments thus far have treated scope as additive. I'd be fine with
clarifying that in the spec.


There is no relation stated to the scope associated with a insufficient
> token sent to a resource.
>

I may be misunderstanding you, but 5.2.1 defines an error code
of insufficient_scope. It states that, "the request requires higher
privileges than provided by the access token." It goes on to say that the
resource server, "MAY include the 'scope' attribute with the scope necessary
to access the protected resource."

I suppose that we can clarify that the resource server should include only
with missing scope(s) in this error response.


Even if this attribute would contain a scope diff, some more questions are
> open: How does the client know what scope values from different
> WWW-Authenticate headers can be combined?
>

Do you have a use case where scopes aren't additive and thus couldn't freely
be combined? Like I said earlier, all of the deployments thusfar treat scope
as additive.


Moreover, the draft does not support to extend a token's scope. So how
> should the client use that knowledge? Kick-off another authorization
> process?
>

Yes. Given that the client is asking for a greater scope, the user would
have to authorize it. A client can ask for a decreased scope when refreshing
a token (which makes similar assumptions about how scope works as I have
been in this email).


regards,
> Torsten.
>
> Am 25.08.2010 00:59, schrieb David Recordon:
>
> Giving scope basic structure (space delimitated) allows any app developer
> to store a list of scopes which they have and compare any desired scopes to
> that list. While the meaning of each scope is not standardized, it allows
> for this sort of simple operation on scope. 5.2.1 also defines how a
> protected resource can tell the client what additional scope(s) are needed
> in order to make their request successful. Standardizing the delimiter
> allows for this sort of "addition" interaction.
>
>  --David
>
>
>
> On Tue, Aug 24, 2010 at 10:41 PM, Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
>
>>  --- p.6 terminology/authorization server
>> "         A server capable of issuing tokens after successfully
>>         authenticating the resource owner and obtaining authorization.
>>         The authorization server may be the same server as the resource
>>         server, or a separate entity. "
>> Based on the discussion in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html, I would
>> suggest to add the following: "A single authorization server may issue
>> tokens for different resource servers."
>>
>> --- p.11 What is the meaning of "... the authentication of the client is
>> based on the user-agent's same-origin policy." ? As far as I know, this
>> policy restricts the hosts the JavaScript client is allowed to interact
>> with. How does this "feature" authenticate the client on the authorization
>> server?
>>
>> --- Examples and client authentication: Since BASIC authentication is the
>> default mechanisms for client authentication, I would suggest to use it in
>> all examples.
>>
>> --- Scope syntax and usage
>> The discussion in
>> http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html revealed
>> most WG members do not want to define the scope's syntax and semantics in
>> the spec. Instead these aspects shall be kept deployment specific. Accepted.
>> To me, this means the scope is specified as a placeholder/pattern only and
>> not as a fullblown parameter. In contrast, the draft raises the expectation
>> to specify more than that e.g. by defining delimiters and talking about
>> orders on scopes (less/equal). In my opinion, we should not pretend to
>> standardize something we don't really standardize. Moreover, if we want to
>> give the deployments the freedom to define the scope's syntax and semantics,
>> then we should not impose any needless restrictions. Here are some examples:
>>
>> p. 17
>> scope
>>         OPTIONAL.  The scope of the access request expressed as a list
>>         of space-delimited strings.  ..
>>
>> Why is it neccessary to define a delimiter for a parameter that otherwise
>> is completly left unspecified? What is the benefit? I would suggest to
>> remove the delimiter definition and let the scope just be an opaque string
>> that can be used by the deployment in any way. Lists of spec-delimited
>> strings are one options, other deployments would probably use JSON documents
>> or an elaborated scope-expression language.
>>
>> p.22 "If the access grant being used already
>>         represents an approved scope (e.g. authorization code,
>>         assertion), the requested scope MUST be equal or lesser than
>>         the scope previously granted."
>>
>> This statement is useless without a definition of an order and equality
>> among scope values. And there might also be a sets, subsets and supersets of
>> scopes.
>> Proposal:
>> Either (a) add an clarification that equality, order, e.t.c. of scopes is
>> deployment specific or (b) remove the statement.
>>
>> p. 33    The "scope" attribute is a space-delimited list of scope values
>>   indicating the required scope of the access token for accessing the
>>   requested resource."
>>
>> There is no explanation what a compliant client should do with the scope
>> attribute value of a WWW-Authenticate header.
>> Proposal:
>> Either a) state that usage of the scope value is deployment specific or b)
>> that the client shall pass this attribute to the respective scope parameters
>> on end-user authorization and tokens endpoint or c) remove the attribute.
>>
>> --- section 3: "The authorization server MUST support the use of
>>   the HTTP "GET" method for the end-user authorization endpoint, and
>>   MAY support the use of the "POST" method as well."
>>
>> What is the use case behind POST on that endpoint? Is the authorization
>> server expected to behave differently with respect to the redirect back to
>> the client? For example, shall HTML FORM Redirection be used for the way
>> back?
>>
>> section 4.3. In my opinion, unauthorized_client should be used on
>> conjunction with status code 403.
>>
>> section 5.1.1. access token charset: This definition allows authorization
>> server for the issuance of token, which cannot be safely passed with URI
>> query parameters (e.g. they are allowd to contain "&"). But section 5.1.2
>> specifies that access tokens can directly be used as such parameters. This
>> may cause problems.
>>
>> Proposal: Either a) modify the access token charset to be URI query
>> parameter compliant or b) advice resource server/clients using URI query
>> parameters to additionaly URL-safe-base64-encode tokens before sending them
>> to the resource server.
>>
>> regards,
>> Torsten.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>

--0016e6db6c281e3fd1048ee6afb4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 28, 2010 at 11:38 AM, Torsten Lodderstedt <=
;torsten@lodderstedt.net>=
 wrote:

    I think a bit more then just defining the delimiter is required in
    order to make things work as you described (in a interoperable way).
    

    5.2.1 states "The "scope" attribute is a space-delimited=
 list of
    scope values indicating the required scope of the access token for
    accessing the requested resource."

    

    So in my understanding the resource may indicate the scope required
    for access, no word about addition.

The deployments thus far have treated scope as additive. I'd be fine=
 with clarifying that in the spec.




T=
here is no relation stated to
    the scope associated with a insufficient token sent to a resource.
<=
/div>

I may be misunderstanding you, but 5.=
2.1 defines an error code of=A0insufficient_scope. It states that,=A0"=
the request requires higher privileges than provided by the access token.&q=
uot; It goes on to say that the resource server, "MAY include the '=
;scope' attribute with the scope necessary to access the protected reso=
urce."



I suppose that we can clarify that the resource server =
should include only with missing scope(s) in this error response.




Even if this attribute would cont=
ain a scope diff, some more
    questions are open: How does the client know what scope values from
    different WWW-Authenticate headers can be combined?
<=
div>
Do you have a use case where scopes aren't additive =
and thus couldn't freely be combined? Like I said earlier, all of the d=
eployments thusfar treat scope as additive.




Moreover, the
    draft does not support to extend a token's scope. So how should the
    client use that knowledge? Kick-off another authorization process?
<=
/div>

Yes. Given that the client is asking =
for a greater scope, the user would have to authorize it. A client can ask =
for a decreased scope when refreshing a token (which makes similar assumpti=
ons about how scope works as I have been in this email).




regards,

    Torsten.

    

    Am 25.08.2010 00:59, schrieb David Recordon:
    
Giving scop=
e basic structure (space=A0delimitated)
      allows any app developer to store a list of scopes which they have
      and compare any desired scopes to that list. While the meaning of
      each scope is not standardized, it allows for this sort of simple
      operation on scope. 5.2.1 also defines how a protected resource
      can tell the client what additional scope(s) are needed in order
      to make their request successful. Standardizing the delimiter
      allows for this sort of "addition" interaction.
      

        

      

      
--David

      


        


          

          
On Tue, Aug 24, 2010 at 10:41 PM,
            Torsten Lodderstedt <torsten@lodderstedt.net>
            wrote:

            
=A0--- p.6 =
terminology/authorization
              server

              " =A0 =A0 =A0 =A0 A server capable of issuing tokens aft=
er
              successfully

              =A0 =A0 =A0 =A0 authenticating the resource owner and obtaini=
ng
              authorization.

              =A0 =A0 =A0 =A0 The authorization server may be the same serv=
er as
              the resource

              =A0 =A0 =A0 =A0 server, or a separate entity. "

              Based on the discussion in http://www.iet=
f.org/mail-archive/web/oauth/current/msg03812.html,
              I would suggest to add the following: "A single
              authorization server may issue tokens for different
              resource servers."

              

              --- p.11 What is the meaning of "... the authentication =
of
              the client is based on the user-agent's same-origin
              policy." ? As far as I know, this policy restricts the
              hosts the JavaScript client is allowed to interact with.
              How does this "feature" authenticate the client on =
the
              authorization server?

              

              --- Examples and client authentication: Since BASIC
              authentication is the default mechanisms for client
              authentication, I would suggest to use it in all examples.
              

              --- Scope syntax and usage

              The discussion in http://www.ietf.org/mai=
l-archive/web/oauth/current/msg03812.html
              revealed most WG members do not want to define the scope'=
s
              syntax and semantics in the spec. Instead these aspects
              shall be kept deployment specific. Accepted. To me, this
              means the scope is specified as a placeholder/pattern only
              and not as a fullblown parameter. In contrast, the draft
              raises the expectation to specify more than that e.g. by
              defining delimiters and talking about orders on scopes
              (less/equal). In my opinion, we should not pretend to
              standardize something we don't really standardize.
              Moreover, if we want to give the deployments the freedom
              to define the scope's syntax and semantics, then we shoul=
d
              not impose any needless restrictions. Here are some
              examples:

              

              p. 17

              scope

              =A0 =A0 =A0 =A0 OPTIONAL. =A0The scope of the access request
              expressed as a list

              =A0 =A0 =A0 =A0 of space-delimited strings. =A0..

              

              Why is it neccessary to define a delimiter for a parameter
              that otherwise is completly left unspecified? What is the
              benefit? I would suggest to remove the delimiter
              definition and let the scope just be an opaque string that
              can be used by the deployment in any way. Lists of
              spec-delimited strings are one options, other deployments
              would probably use JSON documents or an elaborated
              scope-expression language.

              

              p.22 "If the access grant being used already

              =A0 =A0 =A0 =A0 represents an approved scope (e.g. authorizat=
ion
              code,

              =A0 =A0 =A0 =A0 assertion), the requested scope MUST be equal=
 or
              lesser than

              =A0 =A0 =A0 =A0 the scope previously granted."

              

              This statement is useless without a definition of an order
              and equality among scope values. And there might also be a
              sets, subsets and supersets of scopes.

              Proposal:

              Either (a) add an clarification that equality, order,
              e.t.c. of scopes is deployment specific or (b) remove the
              statement.

              

              p. 33 =A0 =A0The "scope" attribute is a space-delim=
ited list
              of scope values

              =A0 indicating the required scope of the access token for
              accessing the

              =A0 requested resource."

              

              There is no explanation what a compliant client should do
              with the scope attribute value of a WWW-Authenticate
              header.

              Proposal:

              Either a) state that usage of the scope value is
              deployment specific or b) that the client shall pass this
              attribute to the respective scope parameters on end-user
              authorization and tokens endpoint or c) remove the
              attribute.

              

              --- section 3: "The authorization server MUST support th=
e
              use of

              =A0 the HTTP "GET" method for the end-user authoriz=
ation
              endpoint, and

              =A0 MAY support the use of the "POST" method as wel=
l."

              

              What is the use case behind POST on that endpoint? Is the
              authorization server expected to behave differently with
              respect to the redirect back to the client? For example,
              shall HTML FORM Redirection be used for the way back?

              

              section 4.3. In my opinion, unauthorized_client should be
              used on conjunction with status code 403.

              

              section 5.1.1. access token charset: This definition
              allows authorization server for the issuance of token,
              which cannot be safely passed with URI query parameters
              (e.g. they are allowd to contain "&"). But sect=
ion
              5.1.2 specifies that access tokens can directly be used as
              such parameters. This may cause problems.

              

              Proposal: Either a) modify the access token charset to be
              URI query parameter compliant or b) advice resource
              server/clients using URI query parameters to additionaly
              URL-safe-base64-encode tokens before sending them to the
              resource server.

              

              regards,

              Torsten.

              _______________________________________________

              OAuth mailing list

              OAuth@iet=
f.org

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

            

          

          

        

      

    

  






--0016e6db6c281e3fd1048ee6afb4--

From torsten@lodderstedt.net  Sat Aug 28 11:53:48 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9874D3A68B9 for ; Sat, 28 Aug 2010 11:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.084
X-Spam-Level: 
X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.164,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9kUgWFoQlE9 for ; Sat, 28 Aug 2010 11:53:46 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by core3.amsl.com (Postfix) with ESMTP id 2A70A3A67F8 for ; Sat, 28 Aug 2010 11:53:45 -0700 (PDT)
Received: from p4ffd2ea1.dip.t-dialin.net ([79.253.46.161] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OpQXh-00059F-0H; Sat, 28 Aug 2010 20:54:17 +0200
Message-ID: <4C795B57.9080702@lodderstedt.net>
Date: Sat, 28 Aug 2010 20:54:15 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: David Recordon 
References: <4C744AAD.3050309@lodderstedt.net>		<4C79579E.1010906@lodderstedt.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030500030008000902080301"
X-Df-Sender: 141509
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] comments/questions on draft 10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2010 18:53:48 -0000

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

  Am 28.08.2010 20:48, schrieb David Recordon:
> On Sat, Aug 28, 2010 at 11:38 AM, Torsten Lodderstedt 
> > wrote:
>
>     I think a bit more then just defining the delimiter is required in
>     order to make things work as you described (in a interoperable way).
>
>     5.2.1 states "The "scope" attribute is a space-delimited list of
>     scope values indicating the required scope of the access token for
>     accessing the requested resource."
>
>     So in my understanding the resource may indicate the scope
>     required for access, no word about addition.
>
>
> The deployments thus far have treated scope as additive. I'd be fine 
> with clarifying that in the spec.
>
>
>     There is no relation stated to the scope associated with a
>     insufficient token sent to a resource.
>
>
> I may be misunderstanding you, but 5.2.1 defines an error code 
> of insufficient_scope. It states that, "the request requires higher 
> privileges than provided by the access token." It goes on to say that 
> the resource server, "MAY include the 'scope' attribute with the scope 
> necessary to access the protected resource."
>
> I suppose that we can clarify that the resource server should include 
> only with missing scope(s) in this error response.
>
>
>     Even if this attribute would contain a scope diff, some more
>     questions are open: How does the client know what scope values
>     from different WWW-Authenticate headers can be combined?
>
>
> Do you have a use case where scopes aren't additive and thus couldn't 
> freely be combined? Like I said earlier, all of the deployments 
> thusfar treat scope as additive.

I would assume that scopes from different resources (esp. from different 
service providers) can be combined into a single token.
For our deployment holds, tokens (and associated scopes) are valid for a 
certain type of resource server, only.

regards,
Torsten.

>
>
>     Moreover, the draft does not support to extend a token's scope. So
>     how should the client use that knowledge? Kick-off another
>     authorization process?
>
>
> Yes. Given that the client is asking for a greater scope, the user 
> would have to authorize it. A client can ask for a decreased scope 
> when refreshing a token (which makes similar assumptions about how 
> scope works as I have been in this email).
>
>
>     regards,
>     Torsten.
>
>     Am 25.08.2010 00:59, schrieb David Recordon:
>>     Giving scope basic structure (space delimitated) allows any app
>>     developer to store a list of scopes which they have and compare
>>     any desired scopes to that list. While the meaning of each scope
>>     is not standardized, it allows for this sort of simple operation
>>     on scope. 5.2.1 also defines how a protected resource can tell
>>     the client what additional scope(s) are needed in order to make
>>     their request successful. Standardizing the delimiter allows for
>>     this sort of "addition" interaction.
>>
>>     --David
>>
>>
>>
>>     On Tue, Aug 24, 2010 at 10:41 PM, Torsten Lodderstedt
>>     > wrote:
>>
>>          --- p.6 terminology/authorization server
>>         "         A server capable of issuing tokens after successfully
>>                 authenticating the resource owner and obtaining
>>         authorization.
>>                 The authorization server may be the same server as
>>         the resource
>>                 server, or a separate entity. "
>>         Based on the discussion in
>>         http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html,
>>         I would suggest to add the following: "A single authorization
>>         server may issue tokens for different resource servers."
>>
>>         --- p.11 What is the meaning of "... the authentication of
>>         the client is based on the user-agent's same-origin policy."
>>         ? As far as I know, this policy restricts the hosts the
>>         JavaScript client is allowed to interact with. How does this
>>         "feature" authenticate the client on the authorization server?
>>
>>         --- Examples and client authentication: Since BASIC
>>         authentication is the default mechanisms for client
>>         authentication, I would suggest to use it in all examples.
>>
>>         --- Scope syntax and usage
>>         The discussion in
>>         http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html
>>         revealed most WG members do not want to define the scope's
>>         syntax and semantics in the spec. Instead these aspects shall
>>         be kept deployment specific. Accepted. To me, this means the
>>         scope is specified as a placeholder/pattern only and not as a
>>         fullblown parameter. In contrast, the draft raises the
>>         expectation to specify more than that e.g. by defining
>>         delimiters and talking about orders on scopes (less/equal).
>>         In my opinion, we should not pretend to standardize something
>>         we don't really standardize. Moreover, if we want to give the
>>         deployments the freedom to define the scope's syntax and
>>         semantics, then we should not impose any needless
>>         restrictions. Here are some examples:
>>
>>         p. 17
>>         scope
>>                 OPTIONAL.  The scope of the access request expressed
>>         as a list
>>                 of space-delimited strings.  ..
>>
>>         Why is it neccessary to define a delimiter for a parameter
>>         that otherwise is completly left unspecified? What is the
>>         benefit? I would suggest to remove the delimiter definition
>>         and let the scope just be an opaque string that can be used
>>         by the deployment in any way. Lists of spec-delimited strings
>>         are one options, other deployments would probably use JSON
>>         documents or an elaborated scope-expression language.
>>
>>         p.22 "If the access grant being used already
>>                 represents an approved scope (e.g. authorization code,
>>                 assertion), the requested scope MUST be equal or
>>         lesser than
>>                 the scope previously granted."
>>
>>         This statement is useless without a definition of an order
>>         and equality among scope values. And there might also be a
>>         sets, subsets and supersets of scopes.
>>         Proposal:
>>         Either (a) add an clarification that equality, order, e.t.c.
>>         of scopes is deployment specific or (b) remove the statement.
>>
>>         p. 33    The "scope" attribute is a space-delimited list of
>>         scope values
>>           indicating the required scope of the access token for
>>         accessing the
>>           requested resource."
>>
>>         There is no explanation what a compliant client should do
>>         with the scope attribute value of a WWW-Authenticate header.
>>         Proposal:
>>         Either a) state that usage of the scope value is deployment
>>         specific or b) that the client shall pass this attribute to
>>         the respective scope parameters on end-user authorization and
>>         tokens endpoint or c) remove the attribute.
>>
>>         --- section 3: "The authorization server MUST support the use of
>>           the HTTP "GET" method for the end-user authorization
>>         endpoint, and
>>           MAY support the use of the "POST" method as well."
>>
>>         What is the use case behind POST on that endpoint? Is the
>>         authorization server expected to behave differently with
>>         respect to the redirect back to the client? For example,
>>         shall HTML FORM Redirection be used for the way back?
>>
>>         section 4.3. In my opinion, unauthorized_client should be
>>         used on conjunction with status code 403.
>>
>>         section 5.1.1. access token charset: This definition allows
>>         authorization server for the issuance of token, which cannot
>>         be safely passed with URI query parameters (e.g. they are
>>         allowd to contain "&"). But section 5.1.2 specifies that
>>         access tokens can directly be used as such parameters. This
>>         may cause problems.
>>
>>         Proposal: Either a) modify the access token charset to be URI
>>         query parameter compliant or b) advice resource
>>         server/clients using URI query parameters to additionaly
>>         URL-safe-base64-encode tokens before sending them to the
>>         resource server.
>>
>>         regards,
>>         Torsten.
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>

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



  
    
    
  
  
    Am 28.08.2010 20:48, schrieb David Recordon:
    
On Sat, Aug 28, 2010 at 11:38 AM, Torsten Lodderstedt
      <torsten@lodderstedt.net>
      wrote:

      

        

          
 I think a bit more then
            just defining the delimiter is required in order to make
            things work as you described (in a interoperable way).

            

            5.2.1 states "The "scope" attribute is a space-delimited
            list of scope values indicating the required scope of the
            access token for accessing the requested resource."

            

            So in my understanding the resource may indicate the scope
            required for access, no word about addition.

        

        


        

        
The deployments thus far have treated scope as additive.
          I'd be fine with clarifying that in the spec.

        


        

        


        

        

          
There is no relation
            stated to the scope associated with a insufficient token
            sent to a resource.

          

        

        


        

        
I may be misunderstanding you, but 5.2.1 defines an error
          code of insufficient_scope. It states that, "the request
          requires higher privileges than provided by the access token."
          It goes on to say that the resource server, "MAY include the
          'scope' attribute with the scope necessary to access the
          protected resource."

        


        

        
I suppose that we can clarify that the resource server
          should include only with missing scope(s) in this error
          response.

        


        

        


        

        

          
Even if this attribute
            would contain a scope diff, some more questions are open:
            How does the client know what scope values from different
            WWW-Authenticate headers can be combined?

        

        


        

        
Do you have a use case where scopes aren't additive and
          thus couldn't freely be combined? Like I said earlier, all of
          the deployments thusfar treat scope as additive.

      

    

    

    I would assume that scopes from different resources (esp. from
    different service providers) can be combined into a single token.

    For our deployment holds, tokens (and associated scopes) are valid
    for a certain type of resource server, only.

    

    regards,

    Torsten.

    

    

      

        


        

        


        

        

          
Moreover, the draft does
            not support to extend a token's scope. So how should the
            client use that knowledge? Kick-off another authorization
            process?

          

        

        


        

        
Yes. Given that the client is asking for a greater scope,
          the user would have to authorize it. A client can ask for a
          decreased scope when refreshing a token (which makes similar
          assumptions about how scope works as I have been in this
          email).

        


        

        


        

        

          
regards,

            Torsten.

            

            Am 25.08.2010 00:59, schrieb David Recordon:
            

              

                
Giving scope basic structure
                  (space delimitated) allows any app developer to store
                  a list of scopes which they have and compare any
                  desired scopes to that list. While the meaning of each
                  scope is not standardized, it allows for this sort of
                  simple operation on scope. 5.2.1 also defines how a
                  protected resource can tell the client what additional
                  scope(s) are needed in order to make their request
                  successful. Standardizing the delimiter allows for
                  this sort of "addition" interaction.
                  
 

                  

                  
--David

                  


                    


                      

                      
On Tue, Aug 24, 2010 at
                        10:41 PM, Torsten Lodderstedt <torsten@lodderstedt.net>
                        wrote:

                        
 ---
                          p.6 terminology/authorization server

                          "         A server capable of issuing tokens
                          after successfully

                                  authenticating the resource owner and
                          obtaining authorization.

                                  The authorization server may be the
                          same server as the resource

                                  server, or a separate entity. "

                          Based on the discussion in http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html,
                          I would suggest to add the following: "A
                          single authorization server may issue tokens
                          for different resource servers."

                          

                          --- p.11 What is the meaning of "... the
                          authentication of the client is based on the
                          user-agent's same-origin policy." ? As far as
                          I know, this policy restricts the hosts the
                          JavaScript client is allowed to interact with.
                          How does this "feature" authenticate the
                          client on the authorization server?

                          

                          --- Examples and client authentication: Since
                          BASIC authentication is the default mechanisms
                          for client authentication, I would suggest to
                          use it in all examples.

                          

                          --- Scope syntax and usage

                          The discussion in http://www.ietf.org/mail-archive/web/oauth/current/msg03812.html
                          revealed most WG members do not want to define
                          the scope's syntax and semantics in the spec.
                          Instead these aspects shall be kept deployment
                          specific. Accepted. To me, this means the
                          scope is specified as a placeholder/pattern
                          only and not as a fullblown parameter. In
                          contrast, the draft raises the expectation to
                          specify more than that e.g. by defining
                          delimiters and talking about orders on scopes
                          (less/equal). In my opinion, we should not
                          pretend to standardize something we don't
                          really standardize. Moreover, if we want to
                          give the deployments the freedom to define the
                          scope's syntax and semantics, then we should
                          not impose any needless restrictions. Here are
                          some examples:

                          

                          p. 17

                          scope

                                  OPTIONAL.  The scope of the access
                          request expressed as a list

                                  of space-delimited strings.  ..

                          

                          Why is it neccessary to define a delimiter for
                          a parameter that otherwise is completly left
                          unspecified? What is the benefit? I would
                          suggest to remove the delimiter definition and
                          let the scope just be an opaque string that
                          can be used by the deployment in any way.
                          Lists of spec-delimited strings are one
                          options, other deployments would probably use
                          JSON documents or an elaborated
                          scope-expression language.

                          

                          p.22 "If the access grant being used already

                                  represents an approved scope (e.g.
                          authorization code,

                                  assertion), the requested scope MUST
                          be equal or lesser than

                                  the scope previously granted."

                          

                          This statement is useless without a definition
                          of an order and equality among scope values.
                          And there might also be a sets, subsets and
                          supersets of scopes.

                          Proposal:

                          Either (a) add an clarification that equality,
                          order, e.t.c. of scopes is deployment specific
                          or (b) remove the statement.

                          

                          p. 33    The "scope" attribute is a
                          space-delimited list of scope values

                            indicating the required scope of the access
                          token for accessing the

                            requested resource."

                          

                          There is no explanation what a compliant
                          client should do with the scope attribute
                          value of a WWW-Authenticate header.

                          Proposal:

                          Either a) state that usage of the scope value
                          is deployment specific or b) that the client
                          shall pass this attribute to the respective
                          scope parameters on end-user authorization and
                          tokens endpoint or c) remove the attribute.

                          

                          --- section 3: "The authorization server MUST
                          support the use of

                            the HTTP "GET" method for the end-user
                          authorization endpoint, and

                            MAY support the use of the "POST" method as
                          well."

                          

                          What is the use case behind POST on that
                          endpoint? Is the authorization server expected
                          to behave differently with respect to the
                          redirect back to the client? For example,
                          shall HTML FORM Redirection be used for the
                          way back?

                          

                          section 4.3. In my opinion,
                          unauthorized_client should be used on
                          conjunction with status code 403.

                          

                          section 5.1.1. access token charset: This
                          definition allows authorization server for the
                          issuance of token, which cannot be safely
                          passed with URI query parameters (e.g. they
                          are allowd to contain "&"). But section
                          5.1.2 specifies that access tokens can
                          directly be used as such parameters. This may
                          cause problems.

                          

                          Proposal: Either a) modify the access token
                          charset to be URI query parameter compliant or
                          b) advice resource server/clients using URI
                          query parameters to additionaly
                          URL-safe-base64-encode tokens before sending
                          them to the resource server.

                          

                          regards,

                          Torsten.

_______________________________________________

                          OAuth mailing list

                          OAuth@ietf.org

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

                        

                      

                      

                    

                  

                

              

            

          

        

      

      

    

  


--------------030500030008000902080301--


From torsten@lodderstedt.net  Sat Aug 28 11:58:09 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081F13A68CD for ; Sat, 28 Aug 2010 11:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=0.161,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UP+DteL9q4Rc for ; Sat, 28 Aug 2010 11:58:08 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id B36803A68C0 for ; Sat, 28 Aug 2010 11:58:07 -0700 (PDT)
Received: from p4ffd2ea1.dip.t-dialin.net ([79.253.46.161] helo=[127.0.0.1]) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OpQbu-0006RV-MJ for oauth@ietf.org; Sat, 28 Aug 2010 20:58:38 +0200
Message-ID: <4C795C5D.2030301@lodderstedt.net>
Date: Sat, 28 Aug 2010 20:58:37 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: OAuth WG 
References: <4C69A909.2060006@lodderstedt.net>
In-Reply-To: <4C69A909.2060006@lodderstedt.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
X-Df-Sender: 141509
Subject: Re: [OAUTH-WG] survey: token revocation design options (intermediate result)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Aug 2010 18:58:09 -0000

  seams option 2 took the lead by one vote.

1a II
1b I
1c
2 III

If no one objects by 08/29, I start writing the I-D based on option 2.

regards,
Torsten.

Am 16.08.2010 23:09, schrieb Torsten Lodderstedt:
> Hi all,
>
> I intend to submit a I-D for token revocation. Based on previous 
> discussions on the mailing list and here at Deutsche Telekom, I see a 
> couple of design options. I would like to share those options with the 
> WG and try to reach consensus on a single option before investing the 
> time to write the I-D.
>
> 1) HTTP Delete on tokens endpoint
>
> DELETE seems a natural way for revoking (deleting) tokens. Although 
> the HTTP spec is a bit vaque in this concern, current practice 
> prohibits a body for DELETE requests. So the token must be addressed 
> by the request's URI. Lets assume the token is passed as URI query 
> parameter as follows:
>
>  DELETE /tokens?refresh_token=8xLOxBtZp8&&&# HTTP/1.1
>  Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>
> But is it advisable to pass tokens as URI query parameters? The 
> current character set definition for access tokens (§5.1.1) is not 
> URL-safe since it includes URI reserved characters (e.g. '/'). 
> Additionally, there is no definition of a refresh tokens character 
> set. So compliant authorization servers could issue tokens, which 
> cannot be safely passed as URI query parameters.
>
> Note: As an additional challenge, self-contained tokens can be very 
> large. So passing them as URI parameter may exceed URL length limits.
>
> I see the following alternatives to cope with the encoding problem:
>
> a) Force usage of a URL-safe character set for access and request tokens.
> - rather restrictive, will most likely collide with existing token 
> formats
> - does not solve URL length problem
>
> b) Force base64-URL-safe encoding for all tokens on transit.
> - does not solve URL length problem
> - significant API change
>
> c) Authorization servers supporting revocation may additionally issue 
> a URL-safe token id in the access token response. This id is used to 
> reference the token in DELETE requests.
>
>     HTTP/1.1 200 OK
>     Content-Type: application/json
>     Cache-Control: no-store
>     {
>       "access_token":"SlAV32hkKG/hhh/&%",
>       "access_token_id":"234567890",
>       "expires_in":3600,
>       "refresh_token":"8xLOxBtZp8&&&#&",
>       "refresh_token_id":"asdfghjklhgf"
>     }
>
>
>  DELETE /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1
>  Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>
> Note: Since tokens become addressable resources on the authz server, 
> one could also query or modify token data using a GET/PUT requests
>
>  GET /tokens?refresh_token_id=asdfghjklhgf HTTP/1.1
>  Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>
>     HTTP/1.1 200 OK
>     Content-Type: application/json
>     Cache-Control: no-store
>
>     {
>       "scope":"abc",
>       "issued_on":"08/11/2010",
>       "last_usage":"08/13/2010"                   }
>
>
> 2) HTTP Post on dedicated revocation endpoint
>
> An additional endpoint is used to revoke tokens. The token to be 
> revoked is sent as request body parameter.
>
>     POST /revocation HTTP/1.1
>     Host: server.example.com
>     Content-Type: application/x-www-form-urlencoded
>     Authorization: BASIC czZCaGRSa3F0Mzo4ZVNFSXBucW1N
>
>     refresh_token=n4E9O119d
>
> This option requires some support for the client to discover the 
> revocation endpoint.
>
> Please indicate your prefered option (1a, 1b, 1c, and 2) or suggest 
> additional design options.
>
> regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From James.H.Manger@team.telstra.com  Sun Aug 29 06:25:52 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4EE23A6819 for ; Sun, 29 Aug 2010 06:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.454
X-Spam-Level: 
X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.446,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QthvQ1Osp4se for ; Sun, 29 Aug 2010 06:25:49 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id 93E413A6823 for ; Sun, 29 Aug 2010 06:25:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,287,1280671200"; d="scan'208,217";a="10659345"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 29 Aug 2010 23:26:13 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6088"; a="7103311"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 29 Aug 2010 23:26:16 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Sun, 29 Aug 2010 23:26:15 +1000
From: "Manger, James H" 
To: David Recordon , OAuth WG 
Date: Sun, 29 Aug 2010 23:26:13 +1000
Thread-Topic: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
Thread-Index: ActGJiZUg7ViR9w/QnilogCxdMLtkgBVmmYQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E1126A070761@WSMSG3153V.srv.dir.telstra.com>
References:  
In-Reply-To: 
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1126A070761WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Aug 2010 13:25:52 -0000

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

Editorial: JSON strings use double quotes, not single quotes, so the exampl=
e in section 2 "Assertion Request" should be:



...

assertion=3D%7B%22token%22%3A%22rjmaGaw9ATW%22%2C%22token_secret%22%3A%22Og=
FcfEjBR%22%7D&

...



--

James Manger



From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of D=
avid Recordon
Sent: Saturday, 28 August 2010 6:26 AM
To: OAuth WG
Cc: Tschofenig, Hannes (NSN - FI/Espoo)
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension



This draft is now an Internet Draft and I'm curious if anyone has any feedb=
ack on it? http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00



I'd also like to request that this draft moves to become a Working Group it=
em. I'm am happy to act as the editor unless someone else wishes to do so m=
oving forward.



Thanks,

--David




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











Editorial: JSON strings use double quotes, not single quotes=
, so the example in section 2 “Assertion Request” should be:


 


…


assertion=
=3D%7B%22token%22%3A%22rjmaGaw9ATW%22%2C%22token_secret%22%3A%22OgFcfEjBR%2=
2%7D&


…


 


--


James Manger


 




From: oauth-bounces@ietf.=
org [mailto:oauth-bounces@ietf.org]
On Behalf Of David Recordon

Sent: Saturday, 28 August 2010 6:26 AM

To: OAuth WG

Cc: Tschofenig, Hannes (NSN - FI/Espoo)

Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension=





 


This draft is now an Internet Draft and I'm curious =
if anyone has any feedback on it? http://tools.ietf.org/html/draft-reco=
rdon-oauth-v2-upgrade-00




 






I'd also like to request that this draft moves to be=
come a Working Group item. I'm am happy to act as the editor unless someone=
 else wishes to do so moving forward.






 






Thanks,






--David






 








--_000_255B9BB34FB7D647A506DC292726F6E1126A070761WSMSG3153Vsrv_--

From bill@dehora.net  Mon Aug 30 05:46:21 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123C53A6811 for ; Mon, 30 Aug 2010 05:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level: 
X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=0.744,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TMLx2xfr2y6 for ; Mon, 30 Aug 2010 05:46:20 -0700 (PDT)
Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by core3.amsl.com (Postfix) with ESMTP id A46D43A6999 for ; Mon, 30 Aug 2010 05:46:18 -0700 (PDT)
Received: from [192.168.1.8] (unknown [89.100.172.151]) by chilco.textdrive.com (Postfix) with ESMTP id 7A6FBDEAB1; Mon, 30 Aug 2010 12:46:48 +0000 (UTC)
From: Bill de =?ISO-8859-1?Q?h=D3ra?= 
To: David Recordon 
In-Reply-To: 
References:  
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 30 Aug 2010 13:46:44 +0100
Message-ID: <1283172404.2719.35.camel@dehora-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , OAuth WG 
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bill@dehora.net
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 12:46:21 -0000

On Fri, 2010-08-27 at 20:26 +0000, David Recordon wrote:
> This draft is now an Internet Draft and I'm curious if anyone has any
> feedback on
> it? http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00
> 

replace

[[[
client_id
      REQUIRED.  The client identifier as described in Section 2 of
      [I-D.ietf.oauth-v2].

   client_secret
      REQUIRED.  The client secret as described in Section 2 of
      [I-D.ietf.oauth-v2].
]]]

with

{{{
client_id
      REQUIRED.  The client identifier as described in Section 2 of
      [I-D.ietf.oauth-v2], the value of which is the oauth_consumer_key
      as described in [@@@rfc5849]

   client_secret
      REQUIRED.  The client secret as described in Section 2 of
      [I-D.ietf.oauth-v2],the value of which is the shared-secret
      as described in "3.4 Signature" of [@@@rfc5849]
}}}

The draft needs to reference rfc5849 rather than OAuth 1.0.

Bill




From bill@dehora.net  Mon Aug 30 06:12:12 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36D863A6818 for ; Mon, 30 Aug 2010 06:12:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.627
X-Spam-Level: 
X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8-SUJXVsunf for ; Mon, 30 Aug 2010 06:11:41 -0700 (PDT)
Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by core3.amsl.com (Postfix) with ESMTP id B34773A680E for ; Mon, 30 Aug 2010 06:11:27 -0700 (PDT)
Received: from [192.168.1.8] (unknown [89.100.172.151]) by chilco.textdrive.com (Postfix) with ESMTP id EADE7E3456 for ; Mon, 30 Aug 2010 13:11:57 +0000 (UTC)
From: Bill de =?ISO-8859-1?Q?h=D3ra?= 
To: OAuth WG 
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 30 Aug 2010 14:11:55 +0100
Message-ID: <1283173915.2719.37.camel@dehora-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] [RFC2104]
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bill@dehora.net
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 13:12:12 -0000

[RFC2104] is a normative reference but isn't referred to in
draft-ietf-oauth-v2-10 and all the hmac stuff seems to be gone from
OAuth2 since 06 - so should the [RFC2104] reference be removed?

Bill



From ionathan@gmail.com  Mon Aug 30 06:44:13 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C443A6818 for ; Mon, 30 Aug 2010 06:44:13 -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=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo9IetvUe-79 for ; Mon, 30 Aug 2010 06:44:13 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AE2193A6816 for ; Mon, 30 Aug 2010 06:44:12 -0700 (PDT)
Received: by wwb28 with SMTP id 28so5488753wwb.13 for ; Mon, 30 Aug 2010 06:44:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=cHr9YAnYhn+sBuKbL/QNpGoHjpZXOnLpo2Voy4or6io=; b=BwVFd2IYCPQu2B6Iw5vGSPAAzVZLC4dWbN1PklA0cfiXn+o2sqmXTgtW6ZBvrW43Hm Bh1mwVzoSb3L7U6F3L5iCUqn8FtVWEeDLKy9xGiCz+fIcpDxS7JNMiAHgGqRK2wBUmCV LoHpEtMBBikCnaJ4ncrhbUnMokE/TCFI2jaaQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fRQyCeBQ3UInOiMHbclrHHWrWtcHNbWmbQztb8inbpugydbxmHNDrrN291Qohh4p5V 72C7wqRYFQlCyV7CX5Ybk1pbNXaNjgs76bOj4hGZD6FmQvstiSQRNxo8Jkmo7GTL3Xhv FyIvg0lQsRmVkDgAFCSnXNlF2tHhBDc220wjM=
MIME-Version: 1.0
Received: by 10.216.159.72 with SMTP id r50mr4923075wek.92.1283175883195; Mon, 30 Aug 2010 06:44:43 -0700 (PDT)
Received: by 10.216.220.217 with HTTP; Mon, 30 Aug 2010 06:44:43 -0700 (PDT)
Date: Mon, 30 Aug 2010 10:44:43 -0300
Message-ID: 
From: Jonathan Leibiusky 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=0016364ef6fab3c55b048f0aaac1
Subject: [OAUTH-WG] Doubts about the User-Agent Profile in OAuth2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 13:47:45 -0000

--0016364ef6fab3c55b048f0aaac1
Content-Type: text/plain; charset=ISO-8859-1

Hi, I read the OAuth2 draft and I still have lots of doubts regard security
when talking about the User-Agent Profile.
I can't really understand how steps D, E and F works. Once I get the
access_token in the fragment, what happens then?
How can I avoid from a malicious user check the source of my user-agent app,
get the app-id and repeat the same steps from his own application somewhere
else?

Thanks!

Jonathan

--0016364ef6fab3c55b048f0aaac1
Content-Type: text/html; charset=ISO-8859-1

Hi, I read the OAuth2 draft and I still have lots of doubts regard security when talking about the User-Agent Profile.
I can't really understand how steps D, E and F works. Once I get the access_token in the fragment, what happens then?

How can I avoid from a malicious user check the source of my user-agent app, get the app-id and repeat the same steps from his own application somewhere else?

Thanks!

Jonathan



--0016364ef6fab3c55b048f0aaac1--

From jricher@mitre.org  Mon Aug 30 07:01:39 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31993A6821 for ; Mon, 30 Aug 2010 07:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.489
X-Spam-Level: 
X-Spam-Status: No, score=-6.489 tagged_above=-999 required=5 tests=[AWL=0.110,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6gqSfZFtbBR for ; Mon, 30 Aug 2010 07:01:38 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 76DD53A6811 for ; Mon, 30 Aug 2010 07:01:38 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7UE28qj017863 for ; Mon, 30 Aug 2010 10:02:09 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7UE28ex017859;  Mon, 30 Aug 2010 10:02:08 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Mon, 30 Aug 2010 10:02:08 -0400
From: Justin Richer 
To: David Recordon 
In-Reply-To: 
References:    <1282941436.23839.112.camel@localhost.localdomain> 
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 30 Aug 2010 10:02:07 -0400
Message-ID: <1283176927.23839.131.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 14:01:39 -0000

Your first example is the textbook case, actually. You're still being
asked to authorize TweetDeck, which is identified by its client_id
parameter. Say your laptop gets stolen -- you'd want to be able to
differentiate between the two "TweetDeck" tokens listed on your
authorized apps account instead of nuking all tokens for that client.
You're right in that the Facebook example you gave below doesn't apply,
unless someone has multiple iPhones or Androids. 

XMPP already does this kind of thing, allowing you to set the "Resource"
field so you know at some level which endpoint you're actually talking
to, even though the account name is the same across all of them. 

The important thing is that this information would be a hint, meant to
be human-readable, and only trusted insofar as the client itself is
trusted to present information (since it's intended to be used in both
registered and unregistered/dynamic clients). The instance_name would
not be a replacement for a registered client name, but an optional
addendum to it. The server has the option of allowing the user to edit
it, though I believe Google has some data about that not actually
happening in practice. 

We've got two direct use cases for this. One system is a Java WebStart
client that is accessible from a browser but stores its creds on the
local machine. Different browsers and different machines can get
different instances of the same app, and our users end up with a whole
stack of authorizations for the same app with no way to tell them apart
from the server after the fact. The other case is a system that uses
email as the gateway, and each email address gets its own authorization
token. In this case, all the credentials are stored on a web/email
server but are tied to different entry points. However we end up with
the same problem as above, where all instances of the same client look
identical to the end user. 

All that this proposal really does is give us a standard slot to put
identification information for the different tokens. 

 -- justin

On Fri, 2010-08-27 at 22:06 -0400, David Recordon wrote:
> Hey Justin, what's a good example of where the instance name parameter
> would be used? Desktop apps like TweetDeck just ask me to authorize
> "TweetDesk" and don't separate between my laptop and desktop. Another
> example would be our Facebook mobile apps but "Facebook for iPhone"
> has a different client id than "Facebook for Android".
> 
> 
> On Fri, Aug 27, 2010 at 8:37 PM, Justin Richer 
> wrote:
>         Does the group have an opinion on adding the instance
>         information that I
>         proposed before* to this UX extension vs. having it live in
>         its own
>         extension?
>         
>          -- Justin
>         
>         *
>         http://www.ietf.org/mail-archive/web/oauth/current/msg03717.html
>         
>         
>         On Fri, 2010-08-27 at 16:23 -0400, David Recordon wrote:
>         > Given our implementation experience, an iPad should use
>         "popup" as
>         > it's a full web browser on a reasonably large screen.
>         Android and the
>         > iPhone should use "touch". I'd be happy to add clarifying
>         language in
>         > the extension but am weary about adding the complexity of
>         the client
>         > requesting dimensions.
>         >
>         >
>         > As a side note, this draft is now up
>         > at http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.
>         >
>         >
>         > --David
>         >
>         >
>         > On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu
>         >  wrote:
>         >         David,
>         >
>         >         Here is some feedback I received internally from
>         Greg Robbins:
>         >
>         >         "Having "display" as an extension is useful, though
>         >         considering the
>         >         trend towards tablet devices like the iPad, "touch"
>         and
>         >         "popup" seem
>         >         orthogonal rather than mutually exclusive.
>         >
>         >         It would also be nice if the client could indicate
>         the
>         >         dimensions
>         >         available for display so the server can make a
>         smarter
>         >         presentation.
>         >         Desktop, netbook, tablet, and mobile screen
>         dimensions vary
>         >         widely
>         >         now."
>         >
>         >         Marius
>         >
>         >
>         >
>         >
>         >         On Mon, Jul 12, 2010 at 12:51 PM, David Recordon
>         >          wrote:
>         >         > I wrote this draft last month based on discussions
>         on the
>         >         mailing list, the
>         >         > OpenID user experience extension (which Facebook,
>         Google,
>         >         and Yahoo! have
>         >         > deployed), and some OAuth 2.0 implementation
>         experience from
>         >         Facebook. It
>         >         > defines language and display preferences which the
>         client
>         >         can include in
>         >         > requests to the end-user authorization endpoint.
>         >         > A previous draft included an immediate mode
>         parameter but
>         >         further discussion
>         >         > has shown that it should be removed until identity
>         >         information is also
>         >         > addressed. Identity is outside the scope of this
>         particular
>         >         extension.
>         >         > I'd like this draft to become a working group
>         document and
>         >         have done my best
>         >         > to make it represent the group's consensus.
>         Unfortunately
>         >         the internet draft
>         >         > submission process is closed for a few weeks until
>         after the
>         >         meeting. :-\
>         >         > Thanks,
>         >         > --David
>         >
>         >
>         >         > _______________________________________________
>         >         > OAuth mailing list
>         >         > OAuth@ietf.org
>         >         > https://www.ietf.org/mailman/listinfo/oauth
>         >         >
>         >         >
>         >
>         >
>         >
>         
>         
>         
> 
> 



From jricher@mitre.org  Mon Aug 30 07:16:20 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250F83A688D for ; Mon, 30 Aug 2010 07:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.494
X-Spam-Level: 
X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OSXmCTd6TSM for ; Mon, 30 Aug 2010 07:16:18 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 7131E3A699C for ; Mon, 30 Aug 2010 07:16:17 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7UEGk8n001771 for ; Mon, 30 Aug 2010 10:16:46 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7UEGkKA001766;  Mon, 30 Aug 2010 10:16:46 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Mon, 30 Aug 2010 10:16:46 -0400
From: Justin Richer 
To: David Recordon 
In-Reply-To: 
References:  
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 30 Aug 2010 10:16:46 -0400
Message-ID: <1283177806.23839.140.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , OAuth WG 
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 14:16:20 -0000

I'm more in favor of this alternative:

[1] http://www.ietf.org/mail-archive/web/oauth/current/msg02300.html

But I can see use cases for both: they basically look at the same
problem from both sides. If Marius would like to bring his draft up to
current spec, I would support its inclusion as a WG item along side of
David's.

 -- Justin

On Fri, 2010-08-27 at 16:26 -0400, David Recordon wrote:
> This draft is now an Internet Draft and I'm curious if anyone has any
> feedback on
> it? http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00
> 
> 
> I'd also like to request that this draft moves to become a Working
> Group item. I'm am happy to act as the editor unless someone else
> wishes to do so moving forward.
> 
> 
> Thanks,
> --David
> 
> 
> On Mon, Jul 12, 2010 at 10:39 PM, David Recordon 
> wrote:
>         The ability to upgrade OAuth 1.0 tokens and secrets to OAuth
>         2.0 access tokens has come up on the list a few times.
>         Attached is a draft assertion format which allows a client to
>         trade an OAuth 1.0 token/secret pair for an OAuth 2.0 access
>         token. The assertion format is a JSON object with values for
>         the token and token secret. My goal is that this draft become
>         a working group document.
>         
>         
>         A question for the group is if upgrading multiple tokens at
>         once is a necessary use case? The assertion format within the
>         core spec only supports issuing a single access token.
>         Facebook has a custom endpoint which allows upgrading multiple
>         tokens at once, but I don't actually have data about how many
>         developers make use of that functionality.
>         
>         
>         Thanks,
>         --David
> 
> 



From recordond@gmail.com  Mon Aug 30 07:53:29 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0466D3A6842 for ; Mon, 30 Aug 2010 07:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Level: 
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw092OzfMjGj for ; Mon, 30 Aug 2010 07:53:27 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id BEBE93A69B0 for ; Mon, 30 Aug 2010 07:53:26 -0700 (PDT)
Received: by bwz9 with SMTP id 9so4554203bwz.31 for ; Mon, 30 Aug 2010 07:53:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fNVpBFB7jBRVQToByn+QjYseitBljDFJuHstAQKcsJU=; b=HJ7j/AffQ637pa+p5pxjrRhI4Q9G6IXQVLZitwaiAllnGDB6galMKbco/4a4FGMSMn cYc2Fi3nZ/wPKIPSR2ZC1jGllPjzZUeoQC+HB5McLVAQMDF2rH0LB2vO9d0bV9CYw6lD sR/vQSeF+KaPjjE6mpQYtW3H5rS85XXKIYrjI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=vKI7uxmQAXLsstO1OBKaB6rZArjDCSWVY1Ztu+ZC0/FoRS2zr/SaN8Vy2QpV1r4/3/ yEA/C2P4HeSUM09Ij4EY03ta+mwG2JWztoBRLwnizKlT0B9iNYDGdSFAR7CN93ylj56m 5oxNuLHH2csVAzDfrwGbGHCDfaXohss+bJt9w=
MIME-Version: 1.0
Received: by 10.204.4.156 with SMTP id 28mr3312875bkr.207.1283180036822; Mon, 30 Aug 2010 07:53:56 -0700 (PDT)
Received: by 10.204.7.139 with HTTP; Mon, 30 Aug 2010 07:53:56 -0700 (PDT)
In-Reply-To: <1283176927.23839.131.camel@localhost.localdomain>
References:    <1282941436.23839.112.camel@localhost.localdomain>  <1283176927.23839.131.camel@localhost.localdomain>
Date: Mon, 30 Aug 2010 07:53:56 -0700
Message-ID: 
From: David Recordon 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=0015175888844716c6048f0ba25f
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 14:53:29 -0000

--0015175888844716c6048f0ba25f
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Aug 30, 2010 at 7:02 AM, Justin Richer  wrote:

> Your first example is the textbook case, actually. You're still being
> asked to authorize TweetDeck, which is identified by its client_id
> parameter. Say your laptop gets stolen -- you'd want to be able to
> differentiate between the two "TweetDeck" tokens listed on your
> authorized apps account instead of nuking all tokens for that client.
>

That makes sense, but none of the servers TweetDeck works with support this
concept today. I like it, but only want to standardize what we've seen to
work in the wild. (This is why I argued that the device flow shouldn't be in
core because the community hasn't successfully deployed it yet.)



> You're right in that the Facebook example you gave below doesn't apply,
> unless someone has multiple iPhones or Androids.
>
> XMPP already does this kind of thing, allowing you to set the "Resource"
> field so you know at some level which endpoint you're actually talking
> to, even though the account name is the same across all of them.
>
> The important thing is that this information would be a hint, meant to
> be human-readable, and only trusted insofar as the client itself is
> trusted to present information (since it's intended to be used in both
> registered and unregistered/dynamic clients). The instance_name would
> not be a replacement for a registered client name, but an optional
> addendum to it. The server has the option of allowing the user to edit
> it, though I believe Google has some data about that not actually
> happening in practice.
>
> We've got two direct use cases for this. One system is a Java WebStart
> client that is accessible from a browser but stores its creds on the
> local machine. Different browsers and different machines can get
> different instances of the same app, and our users end up with a whole
> stack of authorizations for the same app with no way to tell them apart
> from the server after the fact. The other case is a system that uses
> email as the gateway, and each email address gets its own authorization
> token. In this case, all the credentials are stored on a web/email
> server but are tied to different entry points. However we end up with
> the same problem as above, where all instances of the same client look
> identical to the end user.
>
> All that this proposal really does is give us a standard slot to put
> identification information for the different tokens.
>
>  -- justin
>
> On Fri, 2010-08-27 at 22:06 -0400, David Recordon wrote:
> > Hey Justin, what's a good example of where the instance name parameter
> > would be used? Desktop apps like TweetDeck just ask me to authorize
> > "TweetDesk" and don't separate between my laptop and desktop. Another
> > example would be our Facebook mobile apps but "Facebook for iPhone"
> > has a different client id than "Facebook for Android".
> >
> >
> > On Fri, Aug 27, 2010 at 8:37 PM, Justin Richer 
> > wrote:
> >         Does the group have an opinion on adding the instance
> >         information that I
> >         proposed before* to this UX extension vs. having it live in
> >         its own
> >         extension?
> >
> >          -- Justin
> >
> >         *
> >         http://www.ietf.org/mail-archive/web/oauth/current/msg03717.html
> >
> >
> >         On Fri, 2010-08-27 at 16:23 -0400, David Recordon wrote:
> >         > Given our implementation experience, an iPad should use
> >         "popup" as
> >         > it's a full web browser on a reasonably large screen.
> >         Android and the
> >         > iPhone should use "touch". I'd be happy to add clarifying
> >         language in
> >         > the extension but am weary about adding the complexity of
> >         the client
> >         > requesting dimensions.
> >         >
> >         >
> >         > As a side note, this draft is now up
> >         > at http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.
> >         >
> >         >
> >         > --David
> >         >
> >         >
> >         > On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu
> >         >  wrote:
> >         >         David,
> >         >
> >         >         Here is some feedback I received internally from
> >         Greg Robbins:
> >         >
> >         >         "Having "display" as an extension is useful, though
> >         >         considering the
> >         >         trend towards tablet devices like the iPad, "touch"
> >         and
> >         >         "popup" seem
> >         >         orthogonal rather than mutually exclusive.
> >         >
> >         >         It would also be nice if the client could indicate
> >         the
> >         >         dimensions
> >         >         available for display so the server can make a
> >         smarter
> >         >         presentation.
> >         >         Desktop, netbook, tablet, and mobile screen
> >         dimensions vary
> >         >         widely
> >         >         now."
> >         >
> >         >         Marius
> >         >
> >         >
> >         >
> >         >
> >         >         On Mon, Jul 12, 2010 at 12:51 PM, David Recordon
> >         >          wrote:
> >         >         > I wrote this draft last month based on discussions
> >         on the
> >         >         mailing list, the
> >         >         > OpenID user experience extension (which Facebook,
> >         Google,
> >         >         and Yahoo! have
> >         >         > deployed), and some OAuth 2.0 implementation
> >         experience from
> >         >         Facebook. It
> >         >         > defines language and display preferences which the
> >         client
> >         >         can include in
> >         >         > requests to the end-user authorization endpoint.
> >         >         > A previous draft included an immediate mode
> >         parameter but
> >         >         further discussion
> >         >         > has shown that it should be removed until identity
> >         >         information is also
> >         >         > addressed. Identity is outside the scope of this
> >         particular
> >         >         extension.
> >         >         > I'd like this draft to become a working group
> >         document and
> >         >         have done my best
> >         >         > to make it represent the group's consensus.
> >         Unfortunately
> >         >         the internet draft
> >         >         > submission process is closed for a few weeks until
> >         after the
> >         >         meeting. :-\
> >         >         > Thanks,
> >         >         > --David
> >         >
> >         >
> >         >         > _______________________________________________
> >         >         > OAuth mailing list
> >         >         > OAuth@ietf.org
> >         >         > https://www.ietf.org/mailman/listinfo/oauth
> >         >         >
> >         >         >
> >         >
> >         >
> >         >
> >
> >
> >
> >
> >
>
>
>

--0015175888844716c6048f0ba25f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 30, 2010 at 7:02 AM, Justin Richer <jricher@mitre.org> wrote:
<=
div class=3D"gmail_quote">

Your first example is the textbook case, actually. You're still being
asked to authorize TweetDeck, which is identified by its client_id

parameter. Say your laptop gets stolen -- you'd want to be able to

differentiate between the two "TweetDeck" tokens listed on your
authorized apps account instead of nuking all tokens for that client.

That makes sense, but none of the servers Tw=
eetDeck works with support this concept today. I like it, but only want to =
standardize what we've seen to work in the wild. (This is why I argued =
that the device flow shouldn't be in core because the community hasn=
9;t successfully deployed it yet.)



=A0

You're right in that the Facebook example you gave below doesn't ap=
ply,

unless someone has multiple iPhones or Androids.



XMPP already does this kind of thing, allowing you to set the "Resourc=
e"

field so you know at some level which endpoint you're actually talking<=
br>
to, even though the account name is the same across all of them.



The important thing is that this information would be a hint, meant to

be human-readable, and only trusted insofar as the client itself is

trusted to present information (since it's intended to be used in both<=
br>
registered and unregistered/dynamic clients). The instance_name would

not be a replacement for a registered client name, but an optional

addendum to it. The server has the option of allowing the user to edit

it, though I believe Google has some data about that not actually

happening in practice.



We've got two direct use cases for this. One system is a Java WebStart<=
br>
client that is accessible from a browser but stores its creds on the

local machine. Different browsers and different machines can get

different instances of the same app, and our users end up with a whole

stack of authorizations for the same app with no way to tell them apart

from the server after the fact. The other case is a system that uses

email as the gateway, and each email address gets its own authorization

token. In this case, all the credentials are stored on a web/email

server but are tied to different entry points. However we end up with

the same problem as above, where all instances of the same client look

identical to the end user.



All that this proposal really does is give us a standard slot to put

identification information for the different tokens.



=A0-- justin




On Fri, 2010-08-27 at 22:06 -0400, David Recordon wrote:

> Hey Justin, what's a good example of where the instance name param=
eter

> would be used? Desktop apps like TweetDeck just ask me to authorize
> "TweetDesk" and don't separate between my laptop and des=
ktop. Another

> example would be our Facebook mobile apps but "Facebook for iPhon=
e"

> has a different client id than "Facebook for Android".

>

>

> On Fri, Aug 27, 2010 at 8:37 PM, Justin Richer <jricher@mitre.org>

> wrote:

> =A0 =A0 =A0 =A0 Does the group have an opinion on adding the instance<=
br>
> =A0 =A0 =A0 =A0 information that I

> =A0 =A0 =A0 =A0 proposed before* to this UX extension vs. having it li=
ve in

> =A0 =A0 =A0 =A0 its own

> =A0 =A0 =A0 =A0 extension?

>

> =A0 =A0 =A0 =A0 =A0-- Justin

>

> =A0 =A0 =A0 =A0 *

> =A0 =A0 =A0 =A0 http://www.ietf.org/mail-archive/w=
eb/oauth/current/msg03717.html

>

>

> =A0 =A0 =A0 =A0 On Fri, 2010-08-27 at 16:23 -0400, David Recordon wrot=
e:

> =A0 =A0 =A0 =A0 > Given our implementation experience, an iPad shou=
ld use

> =A0 =A0 =A0 =A0 "popup" as

> =A0 =A0 =A0 =A0 > it's a full web browser on a reasonably large=
 screen.

> =A0 =A0 =A0 =A0 Android and the

> =A0 =A0 =A0 =A0 > iPhone should use "touch". I'd be h=
appy to add clarifying

> =A0 =A0 =A0 =A0 language in

> =A0 =A0 =A0 =A0 > the extension but am weary about adding the compl=
exity of

> =A0 =A0 =A0 =A0 the client

> =A0 =A0 =A0 =A0 > requesting dimensions.

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > As a side note, this draft is now up

> =A0 =A0 =A0 =A0 > at http://tools.ietf.org/html/draft-r=
ecordon-oauth-v2-ux-00.

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > --David

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu=


> =A0 =A0 =A0 =A0 > <mscu=
rtescu@google.com> wrote:

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 David,

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Here is some feedback I received =
internally from

> =A0 =A0 =A0 =A0 Greg Robbins:

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 "Having "display" =
as an extension is useful, though

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 considering the

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 trend towards tablet devices like=
 the iPad, "touch"

> =A0 =A0 =A0 =A0 and

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 "popup" seem

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 orthogonal rather than mutually e=
xclusive.

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 It would also be nice if the clie=
nt could indicate

> =A0 =A0 =A0 =A0 the

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 dimensions

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 available for display so the serv=
er can make a

> =A0 =A0 =A0 =A0 smarter

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 presentation.

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Desktop, netbook, tablet, and mob=
ile screen

> =A0 =A0 =A0 =A0 dimensions vary

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 widely

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 now."

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Marius

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 On Mon, Jul 12, 2010 at 12:51 PM,=
 David Recordon

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 <recordond@gmail.com> wrote:

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > I wrote this draft last mont=
h based on discussions

> =A0 =A0 =A0 =A0 on the

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 mailing list, the

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > OpenID user experience exten=
sion (which Facebook,

> =A0 =A0 =A0 =A0 Google,

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 and Yahoo! have

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > deployed), and some OAuth 2.=
0 implementation

> =A0 =A0 =A0 =A0 experience from

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 Facebook. It

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > defines language and display=
 preferences which the

> =A0 =A0 =A0 =A0 client

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 can include in

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > requests to the end-user aut=
horization endpoint.

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > A previous draft included an=
 immediate mode

> =A0 =A0 =A0 =A0 parameter but

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 further discussion

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > has shown that it should be =
removed until identity

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 information is also

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > addressed. Identity is outsi=
de the scope of this

> =A0 =A0 =A0 =A0 particular

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 extension.

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > I'd like this draft to b=
ecome a working group

> =A0 =A0 =A0 =A0 document and

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 have done my best

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > to make it represent the gro=
up's consensus.

> =A0 =A0 =A0 =A0 Unfortunately

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 the internet draft

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > submission process is closed=
 for a few weeks until

> =A0 =A0 =A0 =A0 after the

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 meeting. :-\

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > Thanks,

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > --David

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > ____________________________=
___________________

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

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 > OAuth@ietf.org

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

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 > =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

> =A0 =A0 =A0 =A0 >

>

>

>

>

>









--0015175888844716c6048f0ba25f--

From jricher@mitre.org  Mon Aug 30 08:01:43 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB47D3A676A for ; Mon, 30 Aug 2010 08:01:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.498
X-Spam-Level: 
X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtPyw78csMvW for ; Mon, 30 Aug 2010 08:01:42 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id BC8C63A6962 for ; Mon, 30 Aug 2010 08:01:41 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7UF2CIO028569 for ; Mon, 30 Aug 2010 11:02:12 -0400
Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o7UF2Bgu028564;  Mon, 30 Aug 2010 11:02:11 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Mon, 30 Aug 2010 11:02:11 -0400
From: Justin Richer 
To: David Recordon 
In-Reply-To: 
References:    <1282941436.23839.112.camel@localhost.localdomain>  <1283176927.23839.131.camel@localhost.localdomain> 
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 30 Aug 2010 11:02:10 -0400
Message-ID: <1283180530.23839.149.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 7bit
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Moving the User Experience Extension draft forward
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 15:01:43 -0000

On Mon, 2010-08-30 at 10:53 -0400, David Recordon wrote:
> On Mon, Aug 30, 2010 at 7:02 AM, Justin Richer 
> wrote:
>         Your first example is the textbook case, actually. You're
>         still being
>         asked to authorize TweetDeck, which is identified by its
>         client_id
>         parameter. Say your laptop gets stolen -- you'd want to be
>         able to
>         differentiate between the two "TweetDeck" tokens listed on
>         your
>         authorized apps account instead of nuking all tokens for that
>         client.
> 
> 
> That makes sense, but none of the servers TweetDeck works with support
> this concept today. I like it, but only want to standardize what we've
> seen to work in the wild. (This is why I argued that the device flow
> shouldn't be in core because the community hasn't successfully
> deployed it yet.)


And likewise, I'm totally fine with it being in an extension. The
question was whether to put it in the UX extension or a separate
Instance-Data extension instead.

 
>         You're right in that the Facebook example you gave below
>         doesn't apply,
>         unless someone has multiple iPhones or Androids.
>         
>         XMPP already does this kind of thing, allowing you to set the
>         "Resource"
>         field so you know at some level which endpoint you're actually
>         talking
>         to, even though the account name is the same across all of
>         them.
>         
>         The important thing is that this information would be a hint,
>         meant to
>         be human-readable, and only trusted insofar as the client
>         itself is
>         trusted to present information (since it's intended to be used
>         in both
>         registered and unregistered/dynamic clients). The
>         instance_name would
>         not be a replacement for a registered client name, but an
>         optional
>         addendum to it. The server has the option of allowing the user
>         to edit
>         it, though I believe Google has some data about that not
>         actually
>         happening in practice.
>         
>         We've got two direct use cases for this. One system is a Java
>         WebStart
>         client that is accessible from a browser but stores its creds
>         on the
>         local machine. Different browsers and different machines can
>         get
>         different instances of the same app, and our users end up with
>         a whole
>         stack of authorizations for the same app with no way to tell
>         them apart
>         from the server after the fact. The other case is a system
>         that uses
>         email as the gateway, and each email address gets its own
>         authorization
>         token. In this case, all the credentials are stored on a
>         web/email
>         server but are tied to different entry points. However we end
>         up with
>         the same problem as above, where all instances of the same
>         client look
>         identical to the end user.
>         
>         All that this proposal really does is give us a standard slot
>         to put
>         identification information for the different tokens.
>         
>          -- justin
>         
>         
>         On Fri, 2010-08-27 at 22:06 -0400, David Recordon wrote:
>         > Hey Justin, what's a good example of where the instance name
>         parameter
>         > would be used? Desktop apps like TweetDeck just ask me to
>         authorize
>         > "TweetDesk" and don't separate between my laptop and
>         desktop. Another
>         > example would be our Facebook mobile apps but "Facebook for
>         iPhone"
>         > has a different client id than "Facebook for Android".
>         >
>         >
>         > On Fri, Aug 27, 2010 at 8:37 PM, Justin Richer
>         
>         > wrote:
>         >         Does the group have an opinion on adding the
>         instance
>         >         information that I
>         >         proposed before* to this UX extension vs. having it
>         live in
>         >         its own
>         >         extension?
>         >
>         >          -- Justin
>         >
>         >         *
>         >
>         http://www.ietf.org/mail-archive/web/oauth/current/msg03717.html
>         >
>         >
>         >         On Fri, 2010-08-27 at 16:23 -0400, David Recordon
>         wrote:
>         >         > Given our implementation experience, an iPad
>         should use
>         >         "popup" as
>         >         > it's a full web browser on a reasonably large
>         screen.
>         >         Android and the
>         >         > iPhone should use "touch". I'd be happy to add
>         clarifying
>         >         language in
>         >         > the extension but am weary about adding the
>         complexity of
>         >         the client
>         >         > requesting dimensions.
>         >         >
>         >         >
>         >         > As a side note, this draft is now up
>         >         > at
>         http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00.
>         >         >
>         >         >
>         >         > --David
>         >         >
>         >         >
>         >         > On Wed, Aug 25, 2010 at 8:39 PM, Marius Scurtescu
>         >         >  wrote:
>         >         >         David,
>         >         >
>         >         >         Here is some feedback I received
>         internally from
>         >         Greg Robbins:
>         >         >
>         >         >         "Having "display" as an extension is
>         useful, though
>         >         >         considering the
>         >         >         trend towards tablet devices like the
>         iPad, "touch"
>         >         and
>         >         >         "popup" seem
>         >         >         orthogonal rather than mutually exclusive.
>         >         >
>         >         >         It would also be nice if the client could
>         indicate
>         >         the
>         >         >         dimensions
>         >         >         available for display so the server can
>         make a
>         >         smarter
>         >         >         presentation.
>         >         >         Desktop, netbook, tablet, and mobile
>         screen
>         >         dimensions vary
>         >         >         widely
>         >         >         now."
>         >         >
>         >         >         Marius
>         >         >
>         >         >
>         >         >
>         >         >
>         >         >         On Mon, Jul 12, 2010 at 12:51 PM, David
>         Recordon
>         >         >          wrote:
>         >         >         > I wrote this draft last month based on
>         discussions
>         >         on the
>         >         >         mailing list, the
>         >         >         > OpenID user experience extension (which
>         Facebook,
>         >         Google,
>         >         >         and Yahoo! have
>         >         >         > deployed), and some OAuth 2.0
>         implementation
>         >         experience from
>         >         >         Facebook. It
>         >         >         > defines language and display preferences
>         which the
>         >         client
>         >         >         can include in
>         >         >         > requests to the end-user authorization
>         endpoint.
>         >         >         > A previous draft included an immediate
>         mode
>         >         parameter but
>         >         >         further discussion
>         >         >         > has shown that it should be removed
>         until identity
>         >         >         information is also
>         >         >         > addressed. Identity is outside the scope
>         of this
>         >         particular
>         >         >         extension.
>         >         >         > I'd like this draft to become a working
>         group
>         >         document and
>         >         >         have done my best
>         >         >         > to make it represent the group's
>         consensus.
>         >         Unfortunately
>         >         >         the internet draft
>         >         >         > submission process is closed for a few
>         weeks until
>         >         after the
>         >         >         meeting. :-\
>         >         >         > Thanks,
>         >         >         > --David
>         >         >
>         >         >
>         >         >         >
>         _______________________________________________
>         >         >         > OAuth mailing list
>         >         >         > OAuth@ietf.org
>         >         >         >
>         https://www.ietf.org/mailman/listinfo/oauth
>         >         >         >
>         >         >         >
>         >         >
>         >         >
>         >         >
>         >
>         >
>         >
>         >
>         >
>         
>         
>         
> 



From eran@hueniverse.com  Mon Aug 30 10:09:40 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543A73A6840 for ; Mon, 30 Aug 2010 10:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level: 
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPPvgQpG9HZK for ; Mon, 30 Aug 2010 10:09:39 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 64BCF3A6837 for ; Mon, 30 Aug 2010 10:09:39 -0700 (PDT)
Received: (qmail 1503 invoked from network); 30 Aug 2010 17:10:09 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Aug 2010 17:10:08 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 30 Aug 2010 10:10:01 -0700
From: Eran Hammer-Lahav 
To: "bill@dehora.net" , David Recordon 
Date: Mon, 30 Aug 2010 10:10:00 -0700
Thread-Topic: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
Thread-Index: ActIQW9srvRu5+ncSdGl8YeehcGHvgAJLKrQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3F35B370@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:   <1283172404.2719.35.camel@dehora-laptop>
In-Reply-To: <1283172404.2719.35.camel@dehora-laptop>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth, "Tschofenig, Hannes \(NSN - FI/Espoo\)" , WG 
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 17:09:40 -0000

It does not need to have any normative references to 5849.

EHL

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B=
ill de h=D3ra
Sent: Monday, August 30, 2010 5:47 AM
To: David Recordon
Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension

On Fri, 2010-08-27 at 20:26 +0000, David Recordon wrote:
> This draft is now an Internet Draft and I'm curious if anyone has any=20
> feedback on it?=20
> http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00
>=20

replace

[[[
client_id
      REQUIRED.  The client identifier as described in Section 2 of
      [I-D.ietf.oauth-v2].

   client_secret
      REQUIRED.  The client secret as described in Section 2 of
      [I-D.ietf.oauth-v2].
]]]

with

{{{
client_id
      REQUIRED.  The client identifier as described in Section 2 of
      [I-D.ietf.oauth-v2], the value of which is the oauth_consumer_key
      as described in [@@@rfc5849]

   client_secret
      REQUIRED.  The client secret as described in Section 2 of
      [I-D.ietf.oauth-v2],the value of which is the shared-secret
      as described in "3.4 Signature" of [@@@rfc5849] }}}

The draft needs to reference rfc5849 rather than OAuth 1.0.

Bill



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

From yarong@microsoft.com  Mon Aug 30 11:47:46 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007343A69D8 for ; Mon, 30 Aug 2010 11:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.058
X-Spam-Level: 
X-Spam-Status: No, score=-9.058 tagged_above=-999 required=5 tests=[AWL=-1.428, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, URI_HEX=0.368]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suJho3MpQw3C for ; Mon, 30 Aug 2010 11:47:12 -0700 (PDT)
Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4085B3A67E5 for ; Mon, 30 Aug 2010 11:47:12 -0700 (PDT)
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Aug 2010 11:47:37 -0700
Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.83]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0218.010; Mon, 30 Aug 2010 11:47:37 -0700
From: Yaron Goland 
To: Nat Sakimura , oauth 
Thread-Topic: [OAUTH-WG] OAuth Signature Draft Pre 00
Thread-Index: AQHLQ5NTskJRZ9216Eiyqpsl+JC0y5L6XcEw
Date: Mon, 30 Aug 2010 18:47:36 +0000
Message-ID: <7C01E631FF4B654FA1E783F1C0265F8C62D263BB@TK5EX14MBXC111.redmond.corp.microsoft.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.71]
Content-Type: multipart/mixed; boundary="_005_7C01E631FF4B654FA1E783F1C0265F8C62D263BBTK5EX14MBXC111r_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth Signature Draft Pre 00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 18:47:46 -0000

--_005_7C01E631FF4B654FA1E783F1C0265F8C62D263BBTK5EX14MBXC111r_
Content-Type: multipart/alternative;
	boundary="_000_7C01E631FF4B654FA1E783F1C0265F8C62D263BBTK5EX14MBXC111r_"

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

BTW, Nat and I, as mentioned below, are talking. Here is my current draft. =
Please keep in mind that it's really just a set of notes trying to capture =
all the issues involved in creating a secure token format so it's a bit den=
se. My hope is that once all the issues are captured it can be completely r=
e-written to be in something that looks more like English and is easier for=
 actual implementers to follow. But for now I think it gives a good sense o=
f the some of the security challenges in creating a secure token format.
                Yaron

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Tuesday, August 24, 2010 6:50 AM
To: oauth
Subject: [OAUTH-WG] OAuth Signature Draft Pre 00

Hi.

It has been a few weeks since then I volunteered to do this work.
I have written up to this pre 00 draft then have been doing some reality ch=
ecks on some script languages etc.

No. This pre-00 draft is far from being feature complete.
I still need to copy and paste the Magic Signatures text etc.
Also, I should add how this spec is being used in some of the major flows.

However, since I will not be able to work on it this week, I thought it wou=
ld be worthwhile to share this early draft so that you have some clarity in=
to the progress.

Apparently, Yaron has been working on it as well. We will compare the notes=
 and try to merge, I hope.

So, here it is!

#For those of you who have seen the private draft, it has not been changed =
since July 31.

Best,

=3Dnat



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











BTW, Nat and I, as mentio=
ned below, are talking. Here is my current draft. Please keep in mind that =
it's really just a set of notes trying to capture all the
 issues involved in creating a secure token format so it's a bit dense. My =
hope is that once all the issues are captured it can be completely re-writt=
en to be in something that looks more like English and is easier for actual=
 implementers to follow. But for
 now I think it gives a good sense of the some of the security challenges i=
n creating a secure token format.


    &=
nbsp;           Yaron


 <=
/p>







From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Nat Sakimura

Sent: Tuesday, August 24, 2010 6:50 AM

To: oauth

Subject: [OAUTH-WG] OAuth Signature Draft Pre 00





 


Hi.  




 






It has been a few weeks since then I volunteered to =
do this work. 






I have written up to this pre 00 draft then have bee=
n doing some reality checks on some script languages etc. <=
/p>





 






No. This pre-00 draft is far from being feature comp=
lete. 






I still need to copy and paste the Magic Signatures =
text etc. 






Also, I should add how this spec is being used in so=
me of the major flows. 






 






However, since I will not be able to work on it this=
 week, I thought it would be worthwhile to share this early draft so that y=
ou have some clarity into the progress. 






 






Apparently, Yaron has been working on it as well. We=
 will compare the notes and try to merge, I hope. 






 






So, here it is! 






 






#For those of you who have seen the private draft, i=
t has not been changed since July 31. 






 






Best, 






 






=3Dnat






 






 










--_000_7C01E631FF4B654FA1E783F1C0265F8C62D263BBTK5EX14MBXC111r_--

--_005_7C01E631FF4B654FA1E783F1C0265F8C62D263BBTK5EX14MBXC111r_
Content-Type: text/html; name="jsontokens.html"
Content-Description: jsontokens.html
Content-Disposition: attachment; filename="jsontokens.html"; size=57020;
	creation-date="Wed, 25 Aug 2010 05:14:16 GMT";
	modification-date="Mon, 30 Aug 2010 18:42:11 GMT"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFs
Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL2h0bWw0L2xvb3NlLmR0ZCI+DQo8aHRtbCBsYW5n
PSJlbiI+PGhlYWQ+PHRpdGxlPkpTT04gVG9rZW5zPC90aXRsZT4NCjxtZXRhIGh0dHAtZXF1aXY9
IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRh
IG5hbWU9ImRlc2NyaXB0aW9uIiBjb250ZW50PSJKU09OIFRva2VucyI+DQo8bWV0YSBuYW1lPSJr
ZXl3b3JkcyIgY29udGVudD0iUkZDLCBSZXF1ZXN0IGZvciBDb21tZW50cywgSS1ELCBJbnRlcm5l
dC1EcmFmdCwgQXNzZXJ0aW9uLCBTaW1wbGUgV2ViIFRva2VucywgU1dULCBKU09OIFRva2Vucywg
SlNPTiI+DQo8bWV0YSBuYW1lPSJnZW5lcmF0b3IiIGNvbnRlbnQ9InhtbDJyZmMgdjEuMzUgKGh0
dHA6Ly94bWwucmVzb3VyY2Uub3JnLykiPg0KPHN0eWxlIHR5cGU9J3RleHQvY3NzJz48IS0tDQog
ICAgICAgIGJvZHkgew0KICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiB2ZXJkYW5hLCBjaGFy
Y29hbCwgaGVsdmV0aWNhLCBhcmlhbCwgc2Fucy1zZXJpZjsNCiAgICAgICAgICAgICAgICBmb250
LXNpemU6IHNtYWxsOyBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsNCiAgICAg
ICAgICAgICAgICBtYXJnaW46IDJlbTsNCiAgICAgICAgfQ0KICAgICAgICBoMSwgaDIsIGgzLCBo
NCwgaDUsIGg2IHsNCiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogaGVsdmV0aWNhLCBtb25h
Y28sICJNUyBTYW5zIFNlcmlmIiwgYXJpYWwsIHNhbnMtc2VyaWY7DQogICAgICAgICAgICAgICAg
Zm9udC13ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgICAgfQ0KICAgICAg
ICBoMSB7IGNvbG9yOiAjOTAwOyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgdGV4dC1h
bGlnbjogcmlnaHQ7IH0NCiAgICAgICAgaDMgeyBjb2xvcjogIzMzMzsgYmFja2dyb3VuZC1jb2xv
cjogdHJhbnNwYXJlbnQ7IH0NCg0KICAgICAgICB0ZC5SRkNidWcgew0KICAgICAgICAgICAgICAg
IGZvbnQtc2l6ZTogeC1zbWFsbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOw0KICAgICAgICAgICAg
ICAgIHdpZHRoOiAzMHB4OyBoZWlnaHQ6IDMwcHg7IHBhZGRpbmctdG9wOiAycHg7DQogICAgICAg
ICAgICAgICAgdGV4dC1hbGlnbjoganVzdGlmeTsgdmVydGljYWwtYWxpZ246IG1pZGRsZTsNCiAg
ICAgICAgICAgICAgICBiYWNrZ3JvdW5kLWNvbG9yOiAjMDAwOw0KICAgICAgICB9DQogICAgICAg
IHRkLlJGQ2J1ZyBzcGFuLlJGQyB7DQogICAgICAgICAgICAgICAgZm9udC1mYW1pbHk6IG1vbmFj
bywgY2hhcmNvYWwsIGdlbmV2YSwgIk1TIFNhbnMgU2VyaWYiLCBoZWx2ZXRpY2EsIHZlcmRhbmEs
IHNhbnMtc2VyaWY7DQogICAgICAgICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGNvbG9yOiAj
NjY2Ow0KICAgICAgICB9DQogICAgICAgIHRkLlJGQ2J1ZyBzcGFuLmhvdFRleHQgew0KICAgICAg
ICAgICAgICAgIGZvbnQtZmFtaWx5OiBjaGFyY29hbCwgbW9uYWNvLCBnZW5ldmEsICJNUyBTYW5z
IFNlcmlmIiwgaGVsdmV0aWNhLCB2ZXJkYW5hLCBzYW5zLXNlcmlmOw0KICAgICAgICAgICAgICAg
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IHRleHQtYWxpZ246IGNlbnRlcjsgY29sb3I6ICNGRkY7DQog
ICAgICAgIH0NCg0KICAgICAgICB0YWJsZS5UT0NidWcgeyB3aWR0aDogMzBweDsgaGVpZ2h0OiAx
NXB4OyB9DQogICAgICAgIHRkLlRPQ2J1ZyB7DQogICAgICAgICAgICAgICAgdGV4dC1hbGlnbjog
Y2VudGVyOyB3aWR0aDogMzBweDsgaGVpZ2h0OiAxNXB4Ow0KICAgICAgICAgICAgICAgIGNvbG9y
OiAjRkZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjOTAwOw0KICAgICAgICB9DQogICAgICAgIHRkLlRP
Q2J1ZyBhIHsNCiAgICAgICAgICAgICAgICBmb250LWZhbWlseTogbW9uYWNvLCBjaGFyY29hbCwg
Z2VuZXZhLCAiTVMgU2FucyBTZXJpZiIsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsNCiAgICAgICAg
ICAgICAgICBmb250LXdlaWdodDogYm9sZDsgZm9udC1zaXplOiB4LXNtYWxsOyB0ZXh0LWRlY29y
YXRpb246IG5vbmU7DQogICAgICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tncm91bmQtY29s
b3I6IHRyYW5zcGFyZW50Ow0KICAgICAgICB9DQoNCiAgICAgICAgdGQuaGVhZGVyIHsNCiAgICAg
ICAgICAgICAgICBmb250LWZhbWlseTogYXJpYWwsIGhlbHZldGljYSwgc2Fucy1zZXJpZjsgZm9u
dC1zaXplOiB4LXNtYWxsOw0KICAgICAgICAgICAgICAgIHZlcnRpY2FsLWFsaWduOiB0b3A7IHdp
ZHRoOiAzMyU7DQogICAgICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tncm91bmQtY29sb3I6
ICM2NjY7DQogICAgICAgIH0NCiAgICAgICAgdGQuYXV0aG9yIHsgZm9udC13ZWlnaHQ6IGJvbGQ7
IGZvbnQtc2l6ZTogeC1zbWFsbDsgbWFyZ2luLWxlZnQ6IDRlbTsgfQ0KICAgICAgICB0ZC5hdXRo
b3ItdGV4dCB7IGZvbnQtc2l6ZTogeC1zbWFsbDsgfQ0KDQogICAgICAgIC8qIGluZm8gY29kZSBm
cm9tIFNhbnRhS2xhdXNzIGF0IGh0dHA6Ly93d3cubWFkYWJvdXRzdHlsZS5jb20vdG9vbHRpcDIu
aHRtbCAqLw0KICAgICAgICBhLmluZm8gew0KICAgICAgICAgICAgICAgIC8qIFRoaXMgaXMgdGhl
IGtleS4gKi8NCiAgICAgICAgICAgICAgICBwb3NpdGlvbjogcmVsYXRpdmU7DQogICAgICAgICAg
ICAgICAgei1pbmRleDogMjQ7DQogICAgICAgICAgICAgICAgdGV4dC1kZWNvcmF0aW9uOiBub25l
Ow0KICAgICAgICB9DQogICAgICAgIGEuaW5mbzpob3ZlciB7DQogICAgICAgICAgICAgICAgei1p
bmRleDogMjU7DQogICAgICAgICAgICAgICAgY29sb3I6ICNGRkY7IGJhY2tncm91bmQtY29sb3I6
ICM5MDA7DQogICAgICAgIH0NCiAgICAgICAgYS5pbmZvIHNwYW4geyBkaXNwbGF5OiBub25lOyB9
DQogICAgICAgIGEuaW5mbzpob3ZlciBzcGFuLmluZm8gew0KICAgICAgICAgICAgICAgIC8qIFRo
ZSBzcGFuIHdpbGwgZGlzcGxheSBqdXN0IG9uIDpob3ZlciBzdGF0ZS4gKi8NCiAgICAgICAgICAg
ICAgICBkaXNwbGF5OiBibG9jazsNCiAgICAgICAgICAgICAgICBwb3NpdGlvbjogYWJzb2x1dGU7
DQogICAgICAgICAgICAgICAgZm9udC1zaXplOiBzbWFsbGVyOw0KICAgICAgICAgICAgICAgIHRv
cDogMmVtOyBsZWZ0OiAtNWVtOyB3aWR0aDogMTVlbTsNCiAgICAgICAgICAgICAgICBwYWRkaW5n
OiAycHg7IGJvcmRlcjogMXB4IHNvbGlkICMzMzM7DQogICAgICAgICAgICAgICAgY29sb3I6ICM5
MDA7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7DQogICAgICAgICAgICAgICAgdGV4dC1hbGlnbjog
bGVmdDsNCiAgICAgICAgfQ0KDQogICAgICAgIGEgeyBmb250LXdlaWdodDogYm9sZDsgfQ0KICAg
ICAgICBhOmxpbmsgICAgeyBjb2xvcjogIzkwMDsgYmFja2dyb3VuZC1jb2xvcjogdHJhbnNwYXJl
bnQ7IH0NCiAgICAgICAgYTp2aXNpdGVkIHsgY29sb3I6ICM2MzM7IGJhY2tncm91bmQtY29sb3I6
IHRyYW5zcGFyZW50OyB9DQogICAgICAgIGE6YWN0aXZlICB7IGNvbG9yOiAjNjMzOyBiYWNrZ3Jv
dW5kLWNvbG9yOiB0cmFuc3BhcmVudDsgfQ0KDQogICAgICAgIHAgeyBtYXJnaW4tbGVmdDogMmVt
OyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQ0KICAgICAgICBwLmNvcHlyaWdodCB7IGZvbnQtc2l6ZTog
eC1zbWFsbDsgfQ0KICAgICAgICBwLnRvYyB7IGZvbnQtc2l6ZTogc21hbGw7IGZvbnQtd2VpZ2h0
OiBib2xkOyBtYXJnaW4tbGVmdDogM2VtOyB9DQogICAgICAgIHRhYmxlLnRvYyB7IG1hcmdpbjog
MCAwIDAgM2VtOyBwYWRkaW5nOiAwOyBib3JkZXI6IDA7IHZlcnRpY2FsLWFsaWduOiB0ZXh0LXRv
cDsgfQ0KICAgICAgICB0ZC50b2MgeyBmb250LXNpemU6IHNtYWxsOyBmb250LXdlaWdodDogYm9s
ZDsgdmVydGljYWwtYWxpZ246IHRleHQtdG9wOyB9DQoNCiAgICAgICAgb2wudGV4dCB7IG1hcmdp
bi1sZWZ0OiAyZW07IG1hcmdpbi1yaWdodDogMmVtOyB9DQogICAgICAgIHVsLnRleHQgeyBtYXJn
aW4tbGVmdDogMmVtOyBtYXJnaW4tcmlnaHQ6IDJlbTsgfQ0KICAgICAgICBsaSAgICAgIHsgbWFy
Z2luLWxlZnQ6IDNlbTsgfQ0KDQogICAgICAgIC8qIFJGQy0yNjI5IDxzcGFueD5zIGFuZCA8YXJ0
d29yaz5zLiAqLw0KICAgICAgICBlbSAgICAgeyBmb250LXN0eWxlOiBpdGFsaWM7IH0NCiAgICAg
ICAgc3Ryb25nIHsgZm9udC13ZWlnaHQ6IGJvbGQ7IH0NCiAgICAgICAgZGZuICAgIHsgZm9udC13
ZWlnaHQ6IGJvbGQ7IGZvbnQtc3R5bGU6IG5vcm1hbDsgfQ0KICAgICAgICBjaXRlICAgeyBmb250
LXdlaWdodDogbm9ybWFsOyBmb250LXN0eWxlOiBub3JtYWw7IH0NCiAgICAgICAgdHQgICAgIHsg
Y29sb3I6ICMwMzY7IH0NCiAgICAgICAgdHQsIHByZSwgcHJlIGRmbiwgcHJlIGVtLCBwcmUgY2l0
ZSwgcHJlIHNwYW4gew0KICAgICAgICAgICAgICAgIGZvbnQtZmFtaWx5OiAiQ291cmllciBOZXci
LCBDb3VyaWVyLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogc21hbGw7DQogICAgICAgIH0NCiAgICAg
ICAgcHJlIHsNCiAgICAgICAgICAgICAgICB0ZXh0LWFsaWduOiBsZWZ0OyBwYWRkaW5nOiA0cHg7
DQogICAgICAgICAgICAgICAgY29sb3I6ICMwMDA7IGJhY2tncm91bmQtY29sb3I6ICNDQ0M7DQog
ICAgICAgIH0NCiAgICAgICAgcHJlIGRmbiAgeyBjb2xvcjogIzkwMDsgfQ0KICAgICAgICBwcmUg
ZW0gICB7IGNvbG9yOiAjNjZGOyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZDOyBmb250LXdlaWdodDog
bm9ybWFsOyB9DQogICAgICAgIHByZSAua2V5IHsgY29sb3I6ICMzM0M7IGZvbnQtd2VpZ2h0OiBi
b2xkOyB9DQogICAgICAgIHByZSAuaWQgIHsgY29sb3I6ICM5MDA7IH0NCiAgICAgICAgcHJlIC5z
dHIgeyBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0NGRjsgfQ0KICAgICAgICBwcmUg
LnZhbCB7IGNvbG9yOiAjMDY2OyB9DQogICAgICAgIHByZSAucmVwIHsgY29sb3I6ICM5MDk7IH0N
CiAgICAgICAgcHJlIC5vdGggeyBjb2xvcjogIzAwMDsgYmFja2dyb3VuZC1jb2xvcjogI0ZDRjsg
fQ0KICAgICAgICBwcmUgLmVyciB7IGJhY2tncm91bmQtY29sb3I6ICNGQ0M7IH0NCg0KICAgICAg
ICAvKiBSRkMtMjYyOSA8dGV4dHRhYmxlPnMuICovDQogICAgICAgIHRhYmxlLmFsbCwgdGFibGUu
ZnVsbCwgdGFibGUuaGVhZGVycywgdGFibGUubm9uZSB7DQogICAgICAgICAgICAgICAgZm9udC1z
aXplOiBzbWFsbDsgdGV4dC1hbGlnbjogY2VudGVyOyBib3JkZXItd2lkdGg6IDJweDsNCiAgICAg
ICAgICAgICAgICB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBib3JkZXItY29sbGFwc2U6IGNvbGxhcHNl
Ow0KICAgICAgICB9DQogICAgICAgIHRhYmxlLmFsbCwgdGFibGUuZnVsbCB7IGJvcmRlci1zdHls
ZTogc29saWQ7IGJvcmRlci1jb2xvcjogYmxhY2s7IH0NCiAgICAgICAgdGFibGUuaGVhZGVycywg
dGFibGUubm9uZSB7IGJvcmRlci1zdHlsZTogbm9uZTsgfQ0KICAgICAgICB0aCB7DQogICAgICAg
ICAgICAgICAgZm9udC13ZWlnaHQ6IGJvbGQ7IGJvcmRlci1jb2xvcjogYmxhY2s7DQogICAgICAg
ICAgICAgICAgYm9yZGVyLXdpZHRoOiAycHggMnB4IDNweCAycHg7DQogICAgICAgIH0NCiAgICAg
ICAgdGFibGUuYWxsIHRoLCB0YWJsZS5mdWxsIHRoIHsgYm9yZGVyLXN0eWxlOiBzb2xpZDsgfQ0K
ICAgICAgICB0YWJsZS5oZWFkZXJzIHRoIHsgYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgc29saWQg
bm9uZTsgfQ0KICAgICAgICB0YWJsZS5ub25lIHRoIHsgYm9yZGVyLXN0eWxlOiBub25lOyB9DQog
ICAgICAgIHRhYmxlLmFsbCB0ZCB7DQogICAgICAgICAgICAgICAgYm9yZGVyLXN0eWxlOiBzb2xp
ZDsgYm9yZGVyLWNvbG9yOiAjMzMzOw0KICAgICAgICAgICAgICAgIGJvcmRlci13aWR0aDogMXB4
IDJweDsNCiAgICAgICAgfQ0KICAgICAgICB0YWJsZS5mdWxsIHRkLCB0YWJsZS5oZWFkZXJzIHRk
LCB0YWJsZS5ub25lIHRkIHsgYm9yZGVyLXN0eWxlOiBub25lOyB9DQoNCiAgICAgICAgaHIgeyBo
ZWlnaHQ6IDFweDsgfQ0KICAgICAgICBoci5pbnNlcnQgew0KICAgICAgICAgICAgICAgIHdpZHRo
OiA4MCU7IGJvcmRlci1zdHlsZTogbm9uZTsgYm9yZGVyLXdpZHRoOiAwOw0KICAgICAgICAgICAg
ICAgIGNvbG9yOiAjQ0NDOyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NDOw0KICAgICAgICB9DQotLT48
L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk
ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy
Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90
ZD48L3RyPjwvdGFibGU+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiB3aWR0aD0iNjYlIiBib3Jk
ZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+PHRyPjx0ZD48dGFibGUgc3Vt
bWFyeT0ibGF5b3V0IiB3aWR0aD0iMTAwJSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMiIgY2Vs
bHNwYWNpbmc9IjEiPg0KPHRyPjx0ZCBjbGFzcz0iaGVhZGVyIj5OZXR3b3JrIFdvcmtpbmcgR3Jv
dXA8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj5BLiBOYW1lPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFz
cz0iaGVhZGVyIj5JbnRlcm5ldC1EcmFmdDwvdGQ+PHRkIGNsYXNzPSJoZWFkZXIiPkF1Z3VzdCAy
NCwgMjAxMDwvdGQ+PC90cj4NCjx0cj48dGQgY2xhc3M9ImhlYWRlciI+SW50ZW5kZWQgc3RhdHVz
OiBFeHBlcmltZW50YWw8L3RkPjx0ZCBjbGFzcz0iaGVhZGVyIj4mbmJzcDs8L3RkPjwvdHI+DQo8
dHI+PHRkIGNsYXNzPSJoZWFkZXIiPkV4cGlyZXM6IEZlYnJ1YXJ5IDI1LCAyMDExPC90ZD48dGQg
Y2xhc3M9ImhlYWRlciI+Jm5ic3A7PC90ZD48L3RyPg0KPC90YWJsZT48L3RkPjwvdHI+PC90YWJs
ZT4NCjxoMT48YnIgLz5KU09OIFRva2VuczxiciAvPmRyYWZ0LXNvbWVvbmUtanNvbi10b2tlbnMt
Zm9ybWF0LTAwPC9oMT4NCg0KPGgzPkFic3RyYWN0PC9oMz4NCg0KPHA+SlNPTiBUb2tlbnMgZGVm
aW5lIGFuIGFzc2VydGlvbiBmb3JtYXQgdGhhdCBjYW4gbW92ZSBjbGFpbXMgYmV0d2Vlbg0KICAg
ICAgdHdvIHBhcnRpZXMuIFRoZSBjbGFpbXMgaW4gYSBKU09OIFRva2VuIGFzc2VydGlvbiBhcmUg
ZW5jb2RlZCBhcyBhIEpTT04NCiAgICAgIG9iamVjdCB3aGljaCBpcyB0aGVuIEhNQUMnZCBvciBk
aWdpdGFsbHkgc2lnbmVkLg0KPC9wPg0KPGgzPlJlcXVpcmVtZW50cyBMYW5ndWFnZTwvaDM+DQoN
CjxwPlRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwi
LCAiU0hBTEwgTk9UIiwNCiAgICAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRF
RCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICAgICBkb2N1bWVudCBhcmUgdG8g
YmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZD
MjExOSc+UkZDIDIxMTk8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+QnJhZG5lciwg
Uy4sICZsZHF1bztLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVt
ZW50IExldmVscywmcmRxdW87IE1hcmNoJm5ic3A7MTk5Ny48L3NwYW4+PHNwYW4+KTwvc3Bhbj48
L2E+IFtSRkMyMTE5XS4NCjwvcD4NCjxoMz5TdGF0dXMgb2YgdGhpcyBNZW1vPC9oMz4NCjxwPg0K
VGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgIGluIGZ1bGwNCmNvbmZvcm1hbmNlIHdp
dGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQJm5ic3A7NzggYW5kIEJDUCZuYnNwOzc5LjwvcD4NCjxw
Pg0KSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQg
RW5naW5lZXJpbmcNClRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBt
YXkgYWxzbyBkaXN0cmlidXRlDQp3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMu
ICBUaGUgbGlzdCBvZiBjdXJyZW50DQpJbnRlcm5ldC1EcmFmdHMgaXMgYXQgaHR0cDovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3A+DQo8cD4NCkludGVybmV0LURyYWZ0
cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0K
YW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3Vt
ZW50cyBhdCBhbnkgdGltZS4NCkl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURy
YWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZQ0KdGhlbSBvdGhlciB0aGFuIGFz
ICZsZHF1bzt3b3JrIGluIHByb2dyZXNzLiZyZHF1bzs8L3A+DQo8cD4NClRoaXMgSW50ZXJuZXQt
RHJhZnQgd2lsbCBleHBpcmUgb24gRmVicnVhcnkgMjUsIDIwMTEuPC9wPg0KDQo8aDM+Q29weXJp
Z2h0IE5vdGljZTwvaDM+DQo8cD4NCkNvcHlyaWdodCAoYykgMjAxMCBJRVRGIFRydXN0IGFuZCB0
aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdo
dHMgcmVzZXJ2ZWQuPC9wPg0KPHA+DQpUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4
IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsDQpQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYg
RG9jdW1lbnRzDQooaHR0cDovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZl
Y3Qgb24gdGhlIGRhdGUgb2YNCnB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2Ug
cmV2aWV3IHRoZXNlIGRvY3VtZW50cw0KY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIg
cmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DQp0byB0aGlzIGRvY3VtZW50LiBD
b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0DQppbmNsdWRl
IFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUg
b2YNCnRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3
YXJyYW50eSBhcw0KZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwvcD4N
CjxhIG5hbWU9InRvYyI+PC9hPjxiciAvPjxociAvPg0KPGgzPlRhYmxlIG9mIENvbnRlbnRzPC9o
Mz4NCjxwIGNsYXNzPSJ0b2MiPg0KPGEgaHJlZj0iI2FuY2hvcjEiPjEuPC9hPiZuYnNwOw0KSW50
cm9kdWN0aW9uPGJyIC8+DQo8YSBocmVmPSIjYW5jaG9yMiI+Mi48L2E+Jm5ic3A7DQpUZXJtaW5v
bG9neTxiciAvPg0KPGEgaHJlZj0iI2FuY2hvcjMiPjMuPC9hPiZuYnNwOw0KRXhhbXBsZTxiciAv
Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjQiPjMuMS48L2E+Jm5i
c3A7DQpKU09OIFRva2VuIHVzaW5nIEhtYWNTaGEyNTY8YnIgLz4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9IiNhbmNob3I1Ij4zLjEuMS48
L2E+Jm5ic3A7DQpFbmNvZGluZzxiciAvPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjYiPjMuMS4yLjwvYT4mbmJzcDsNCkRl
Y29kaW5nPGJyIC8+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yNyI+
My4yLjwvYT4mbmJzcDsNCkpTT04gVG9rZW4gdXNpbmcgRUNEU0EgUDI1NiBTSEEyNTY8YnIgLz4N
CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9
IiNhbmNob3I4Ij4zLjIuMS48L2E+Jm5ic3A7DQpFbmNvZGluZzxiciAvPg0KJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iI2FuY2hvcjkiPjMu
Mi4yLjwvYT4mbmJzcDsNCkRlY29kaW5nPGJyIC8+DQo8YSBocmVmPSIjYW5jaG9yMTAiPjQuPC9h
PiZuYnNwOw0KQ2xhaW1zIHRoYXQgY2FuIGJlIG1hZGUgaW4gYSBKU09OIFRva2VuPGJyIC8+DQom
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSIjYW5jaG9yMTEiPjQuMS48L2E+Jm5ic3A7
DQpHZW5lcmF0aW5nIHVuaXF1ZSBuYW1lcyBhbmQgdmFsdWVzPGJyIC8+DQo8YSBocmVmPSIjYmFz
ZTY0dXJsbG9naWMiPjUuPC9hPiZuYnNwOw0KYmFzZTY0dXJsIGVuY29kaW5nIGFzIHVzZWQgYnkg
SlNPTiBUb2tlbnM8YnIgLz4NCjxhIGhyZWY9IiNhbmNob3IxMiI+Ni48L2E+Jm5ic3A7DQpHZW5l
cmFsIHJ1bGVzIGZvciBjcmVhdGluZyBhbmQgdmFsaWRhdGluZyBhIEpTT04gVG9rZW48YnIgLz4N
CjxhIGhyZWY9IiNhbmNob3IxMyI+Ny48L2E+Jm5ic3A7DQpQcm90ZWN0aW5nIGEgSlNPTiBUb2tl
biB3aXRoIEhNQUMgU0hBLTI1NjxiciAvPg0KPGEgaHJlZj0iI2FuY2hvcjE0Ij44LjwvYT4mbmJz
cDsNClByb3RlY3RpbmcgYSBKU09OIFRva2VuIHdpdGggUlNBIGRpZ2l0YWwgc2lnbmF0dXJlczxi
ciAvPg0KPGEgaHJlZj0iI0RlZmluaW5nRUNEU0EiPjkuPC9hPiZuYnNwOw0KUHJvdGVjdGluZyBh
IEpTT04gVG9rZW4gd2l0aCBFQ0RTQTxiciAvPg0KPGEgaHJlZj0iI0lBTkEiPjEwLjwvYT4mbmJz
cDsNCklBTkEgQ29uc2lkZXJhdGlvbnM8YnIgLz4NCjxhIGhyZWY9IiNTZWN1cml0eSI+MTEuPC9h
PiZuYnNwOw0KU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8YnIgLz4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOzxhIGhyZWY9IiNhbmNob3IxNSI+MTEuMS48L2E+Jm5ic3A7DQpVbmljb2RlIGNvbXBh
cmlzb24gc2VjdXJpdHkgaXNzdWVzPGJyIC8+DQo8YSBocmVmPSIjQWNrbm93bGVkZ2VtZW50cyI+
MTIuPC9hPiZuYnNwOw0KQWNrbm93bGVkZ2VtZW50czxiciAvPg0KPGEgaHJlZj0iI2FuY2hvcjE2
Ij4xMy48L2E+Jm5ic3A7DQpBcHBlbmRpeCAtIE5vbi1Ob3JtYXRpdmUgLSBSZWxhdGlvbnNoaXAg
b2YgSlNPTiBUb2tlbnMgdG8gU0FNTCBBc3NlcnRpb25zPGJyIC8+DQo8YSBocmVmPSIjcmZjLnJl
ZmVyZW5jZXMxIj4xNC48L2E+Jm5ic3A7DQpSZWZlcmVuY2VzPGJyIC8+DQombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDs8YSBocmVmPSIjcmZjLnJlZmVyZW5jZXMxIj4xNC4xLjwvYT4mbmJzcDsNCk5v
cm1hdGl2ZSBSZWZlcmVuY2VzPGJyIC8+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVm
PSIjcmZjLnJlZmVyZW5jZXMyIj4xNC4yLjwvYT4mbmJzcDsNCkluZm9ybWF0aXZlIFJlZmVyZW5j
ZXM8YnIgLz4NCjxhIGhyZWY9IiNyZmMuYXV0aG9ycyI+JiMxNjc7PC9hPiZuYnNwOw0KQXV0aG9y
J3MgQWRkcmVzczxiciAvPg0KPC9wPg0KPGJyIGNsZWFyPSJhbGwiIC8+DQoNCjxhIG5hbWU9ImFu
Y2hvcjEiPjwvYT48YnIgLz48aHIgLz4NCjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRk
aW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+
PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3Rk
PjwvdHI+PC90YWJsZT4NCjxhIG5hbWU9InJmYy5zZWN0aW9uLjEiPjwvYT48aDM+MS4mbmJzcDsN
CkludHJvZHVjdGlvbjwvaDM+DQoNCjxwPkpTT04gVG9rZW5zIHByb3ZpZGUgYSBzaW1wbGlmaWVk
IGFzc2VydGlvbiBmb3JtYXQgaW50ZW5kZWQgZm9yIHNwYWNlDQogICAgICBjb25zdHJhaW5lZCBl
bnZpcm9ubWVudHMgc3VjaCBhcyBIVFRQIEF1dGhvcml6YXRpb24gaGVhZGVycyBhbmQgVVJJDQog
ICAgICBxdWVyeSBwYXJhbWV0ZXJzLiBKU09OIFRva2VucyBlbmNvZGUgdGhlIGFzc2VydGlvbiB0
byBiZSB0cmFuc21pdHRlZCBhcw0KICAgICAgYSBKU09OIG9iamVjdCAoYXMgZGVmaW5lZCBpbiA8
YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzQ2MjcnPlJGQyA0NjI3PHNwYW4+ICg8L3NwYW4+PHNw
YW4gY2xhc3M9J2luZm8nPkNyb2NrZm9yZCwgRC4sICZsZHF1bztUaGUgYXBwbGljYXRpb24vanNv
biBNZWRpYSBUeXBlIGZvciBKYXZhU2NyaXB0IE9iamVjdCBOb3RhdGlvbiAoSlNPTiksJnJkcXVv
OyBKdWx5Jm5ic3A7MjAwNi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM0NjI3XSkNCiAg
ICAgIHdoaWNoIGlzIHRoZW4gZWl0aGVyIEhNQUMnZCBvciBkaWdpdGFsbHkgc2lnbmVkLg0KPC9w
Pg0KPGEgbmFtZT0iYW5jaG9yMiI+PC9hPjxiciAvPjxociAvPg0KPHRhYmxlIHN1bW1hcnk9Imxh
eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln
bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D
Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0KPGEgbmFtZT0icmZjLnNlY3Rpb24uMiI+PC9h
PjxoMz4yLiZuYnNwOw0KVGVybWlub2xvZ3k8L2gzPg0KDQo8cD48L3A+DQo8YmxvY2txdW90ZSBj
bGFzcz0idGV4dCI+PGRsPg0KPGR0PkpTT04gVG9rZW4gU2VnbWVudDwvZHQ+DQo8ZGQ+T25lIG9m
IHRoZSB0d28gcGFydHMgdGhhdCBtYWtlIHVwIGENCiAgICAgICAgICBKU09OIFRva2VuLg0KPC9k
ZD4NCjxkdD5KU09OIENyeXB0byBTZWdtZW50PC9kdD4NCjxkZD5UaGUgZmlyc3QgSlNPTiBUb2tl
biBTZWdtZW50IHRoYXQNCiAgICAgICAgICBjb250YWlucyBjcnlwdG9ncmFwaGljIG1hdGVyaWFs
IHN1Y2ggYXMgYSBITUFDIG9yIHNpZ25hdHVyZSB0aGF0DQogICAgICAgICAgc2VjdXJlcyB0aGUg
dG9rZW4ncyBjb250ZW50cy4NCjwvZGQ+DQo8ZHQ+SlNPTiBDbGFpbSBTZWdtZW50PC9kdD4NCjxk
ZD5UaGUgc2Vjb25kIEpTT04gVG9rZW4gU2VnbWVudCB0aGF0DQogICAgICAgICAgY29udGFpbnMg
YSBKU09OIG9iamVjdCB0aGF0IGVuY29kZXMgdGhlIGNsYWltcyBiZWluZyBtYWRlIGJ5IHRoZQ0K
ICAgICAgICAgIEpTT04gVG9rZW4gYW5kIGhhcyBiZWVuIGJhc2U2NHVybCBlbmNvZGVkLg0KPC9k
ZD4NCjxkdD5KU09OIFRva2VuPC9kdD4NCjxkZD5BIHN0cmluZyBjb25zaXN0aW5nIG9mIHR3byBK
U09OIFRva2VuDQogICAgICAgICAgU2VnbWVudHMsIGZpcnN0IHRoZSBKU09OIENyeXB0byBTZWdt
ZW50LCB0aGVuIHRoZSBKU09OIENsYWltDQogICAgICAgICAgU2VnbWVudCwgc2VwYXJhdGVkIGJ5
IGEgcGVyaW9kIGNoYXJhY3Rlci4NCjwvZGQ+DQo8ZHQ+RGVjb2RlZCBKU09OIENsYWltIFNlZ21l
bnQ8L2R0Pg0KPGRkPkEgSlNPTiBDbGFpbSBTZWdtZW50IHRoYXQNCiAgICAgICAgICBoYXMgYmVl
biBiYXNlNjR1cmwgZGVjb2RlZCBiYWNrIGludG8gYSBKU09OIG9iamVjdC4NCjwvZGQ+DQo8ZHQ+
TWVtYmVyPC9kdD4NCjxkZD5BIEpTT04gdGVybSByZWZlcnJpbmcgdG8gdGhlIGNvbnRlbnRzIG9m
IGEgSlNPTg0KICAgICAgICAgIG9iamVjdC4NCjwvZGQ+DQo8L2RsPjwvYmxvY2txdW90ZT4NCg0K
PGEgbmFtZT0iYW5jaG9yMyI+PC9hPjxiciAvPjxociAvPg0KPHRhYmxlIHN1bW1hcnk9ImxheW91
dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0i
cmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5i
c3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0KPGEgbmFtZT0icmZjLnNlY3Rpb24uMyI+PC9hPjxo
Mz4zLiZuYnNwOw0KRXhhbXBsZTwvaDM+DQoNCjxhIG5hbWU9ImFuY2hvcjQiPjwvYT48YnIgLz48
aHIgLz4NCjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2lu
Zz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWci
PjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4NCjxh
IG5hbWU9InJmYy5zZWN0aW9uLjMuMSI+PC9hPjxoMz4zLjEuJm5ic3A7DQpKU09OIFRva2VuIHVz
aW5nIEhtYWNTaGEyNTY8L2gzPg0KDQo8YSBuYW1lPSJhbmNob3I1Ij48L2E+PGJyIC8+PGhyIC8+
DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi
IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo
cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1l
PSJyZmMuc2VjdGlvbi4zLjEuMSI+PC9hPjxoMz4zLjEuMS4mbmJzcDsNCkVuY29kaW5nPC9oMz4N
Cg0KPHA+VGhlIGRlY29kZWQgSlNPTiBDbGFpbSBTZWdtZW50IHdlIHdpbGwgdXNlIGluIHRoaXMg
ZXhhbXBsZSBpczoNCjwvcD48YnIgLz48aHIgY2xhc3M9Imluc2VydCIgLz4NCjxhIG5hbWU9IlNh
bXBsZURlY29kZWQiPjwvYT4NCjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsg
bWFyZ2luLWxlZnQ6IDNlbTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPnsiaXNzdWVyIjoiam9l
IiwNCiAiYWxnb3JpdGhtIjoiSG1hY1NoYTI1NiIsDQogIm5vdF9hZnRlciI6IjEyODI4ODUyNDUi
LA0KICJodHRwOi8vZXhhbXBsZS5jb20vaXNfcm9vdCI6dHJ1ZX08L3ByZT48L2Rpdj48dGFibGUg
Ym9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGFsaWduPSJjZW50ZXIi
Pjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNlcmlm
IiBzaXplPSIxIj48Yj4mbmJzcDtGaWd1cmUmbmJzcDsxOiBTYW1wbGUgZGVjb2RlZCBKU09OIENs
YWltIFNlZ21lbnQmbmJzcDs8L2I+PC9mb250PjxiciAvPjwvdGQ+PC90cj48L3RhYmxlPjxociBj
bGFzcz0iaW5zZXJ0IiAvPg0KDQo8cD5Ob3RlIHRoYXQgd2hpdGUgc3BhY2UgaXMgZXhwbGljaXRs
eSBhbGxvd2VkIGluIEpTT04gb2JqZWN0cy4gVGhlIGZvbGxvd2luZyBpcyBhIGJ5dGUgYXJyYXkg
Y29udGFpbmluZyB0aGUgVVRGLTggY2hhcmFjdGVycyB0aGF0IG1ha2UgdXAgdGhlIGRlY29kZWQg
SlNPTiBDbGFpbXMgU2VnbWVudDogWzEyMywgMzQsIDEwNSwgMTE1LCAxMTUsIDExNywgMTAxLCAx
MTQsIDM0LCA1OCwgMzQsDQogICAgMTA2LCAxMTEsIDEwMSwgMzQsIDQ0LCAxMCwgMzIsIDM0LCA5
NywgMTA4LCAxMDMsDQogICAgMTExLCAxMTQsIDEwNSwgMTE2LCAxMDQsIDEwOSwgMzQsIDU4LCAz
NCwgNzIsIDEwOSwNCiAgICA5NywgOTksIDgzLCAxMDQsIDk3LCA1MCwgNTMsIDU0LCAzNCwgNDQs
IDEwLCAzMiwNCiAgICAzNCwgMTEwLCAxMTEsIDExNiwgOTUsIDk3LCAxMDIsIDExNiwgMTAxLCAx
MTQsIDM0LCA1OCwgMzQsIDQ5LCA1MCwgNTYsIDUwLCA1NiwNCiAgICA1NiwgNTMsIDUwLCA1Miwg
NTMsIDM0LCA0NCwgMTAsIDMyLCAzNCwgMTA0LCAxMTYsDQogICAgMTE2LCAxMTIsIDU4LCA0Nywg
NDcsIDEwMSwgMTIwLCA5NywgMTA5LCAxMTIsIDEwOCwNCiAgICAxMDEsIDQ2LCA5OSwgMTExLCAx
MDksIDQ3LCAxMDUsIDExNSwgOTUsIDExNCwgMTExLA0KICAgIDExMSwgMTE2LCAzNCwgNTgsIDEx
NiwgMTE0LCAxMTcsIDEwMSwgMTI1XQ0KPC9wPg0KPHA+VGhlIHByZXZpb3VzIGlzIHRoZW4gYmFz
ZTY0dXJsIGVuY29kZWQgYW5kIGhhcyBpdHMgcGFkZGluZyBjaGFyYWN0ZXJzIHJlbW92ZWQuIFRo
aXMgd2lsbCB0aGVuIG91dHB1dCB0aGUgc3RyaW5nOiAiZXlKcGMzTjFaWElpT2lKcWIyVWlMQW9n
SW1Gc1oyOXlhWFJvYlNJNklraHRZV05UYUdFeU5UWWlMQW9nSW01dmRGOWhablJsY2lJNklqRXlP
REk0T0RVeU5EVWlMQW9nSW1oMGRIQTZMeTlsZUdGdGNHeGxMbU52YlM5cGMxOXliMjkwSWpwMGNu
VmxmUSIuIFRoaXMgc3RyaW5nIGlzIHRoZSBKU09OIENsYWltIFNlZ21lbnQuDQo8L3A+DQo8cD5I
TUFDcyBhcmUgZ2VuZXJhdGVkIHVzaW5nIGtleXMuIEluIHRoaXMgY2FzZSB3ZSB3aWxsIHVzZSB0
aGUgZm9sbG93aW5nIGtleSB3aGljaCBpcyByZXByZXNlbnRlZCBhcyBhIGJ5dGUgYXJyYXk6IFsy
MzMsIDM3LCA1NywgOTksIDcyLCAyOSwgMTk2LCAyMjAsIDkwLCAxMDcsIDIzMCwNCiAgICAxOTAs
IDI0MSwgMTQ1LCAyNDMsIDEyLCAxMTQsIDE1NCwgMTgsIDk0LCA1OSwgNTYsDQogICAgMTM0LCA5
MywgMjA4LCAxMTUsIDIzMiwgMTcyLCA4OCwgMjA4LCAyNCwgMTk1LCAxNzQsDQogICAgMTk3LCAx
NDgsIDk2LCAxMzksIDIwNiwgOTAsIDI0NywgMTczLCAxOTgsIDE5MCwgMTYyLA0KICAgIDEwLCA4
MywgODQsIDIxNywgMjA2LCAxMDIsIDE1NCwgMjIsIDE4OSwgODksIDM5LA0KICAgIDE1NywgMTUy
LCAxOTUsIDI0NiwgMjQ5LCAxMzIsIDE2MiwgMCwgMjMzXS4NCjwvcD4NCjxwPkFsdGVybmF0aXZl
bHkgc2luY2UgaXQgbWF5IGJlIGVhc2llciB0byBwcm9jZXNzIGhlcmUgaXMgdGhlIHNhbWUga2V5
IGFzIGEgYmFzZTY0dXJsIGVuY29kZWQgdmFsdWUgd2l0aCBwYWRkaW5nIHJlbW92ZWQ6ICI2U1U1
WTBnZHhOeGFhLWEtOFpIekRIS2FFbDQ3T0laZDBIUG9yRmpRR01PdXhaUmdpODVhOTYzR3ZxSUtV
MVRaem1hYUZyMVpKNTJZd19iNWhLSUE2USIuDQo8L3A+DQo8cD5Ob3cgd2UgY2FuIHN1Ym1pdCB0
aGUgSlNPTiBDbGFpbSBTZWdtZW50IGFsb25nIHdpdGggdGhlIGtleSB0byBhIFNIQSAyNTYgYmFz
ZWQgSE1BQyB3aGljaCB3aWxsIG91dHB1dCB0aGUgZm9sbG93aW5nIGJ5dGUgYXJyYXk6IFsxMjYs
IDEwNSwgMTgyLCAxMjksIDI3LCAyMDEsIDE2NSwgMTQ3LCA5MSwgMjM3LCAyNCwNCiAgICAyMjks
IDc2LCA1NywgNTIsIDIzOCwgMTkyLCAzNCwgOTMsIDIyOSwgOTcsIDE1OSwgMSwNCiAgICAwLCA0
OCwgNTEsIDE4NSwgMTU0LCAxNjMsIDIyNywgMTM0LCAyMjVdLg0KPC9wPg0KPHA+VGhpcyBieXRl
IGFycmF5IGlzIHRoZW4gYmFzZTY0dXJsIGVuY29kZWQgd2l0aCBwYWRkaW5nIHJlbW92ZWQgcHJv
ZHVjaW5nIHRoZSBzdHJpbmc6ICJmbW0yZ1J2SnBaTmI3UmpsVERrMDdzQWlYZVZobndFQU1ETzVt
cVBqaHVFIi4gVGhpcyBzdHJpbmcgaXMgdGhlIEpTT04gQ3J5cHRvIFNlZ21lbnQuDQo8L3A+DQo8
cD5UaGVyZWZvcmUgdGhlIEpTT04gVG9rZW4gd291bGQgYmU6ICJmbW0yZ1J2SnBaTmI3UmpsVERr
MDdzQWlYZVZobndFQU1ETzVtcVBqaHVFLmV5SnBjM04xWlhJaU9pSnFiMlVpTEFvZ0ltRnNaMjl5
YVhSb2JTSTZJa2h0WVdOVGFHRXlOVFlpTEFvZ0ltNXZkRjloWm5SbGNpSTZJakV5T0RJNE9EVXlO
RFVpTEFvZ0ltaDBkSEE2THk5bGVHRnRjR3hsTG1OdmJTOXBjMTl5YjI5MElqcDBjblZsZlEiLg0K
PC9wPg0KPGEgbmFtZT0iYW5jaG9yNiI+PC9hPjxiciAvPjxociAvPg0KPHRhYmxlIHN1bW1hcnk9
ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBh
bGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7
VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4x
LjIiPjwvYT48aDM+My4xLjIuJm5ic3A7DQpEZWNvZGluZzwvaDM+DQoNCjxwPkRlY29kaW5nIHRo
ZSBKU09OIENsYWltIFNlZ21lbnQgZmlyc3QgcmVxdWlyZXMgcmVtb3ZpbmcgdGhlIGJhc2U2NHVy
bCBlbmNvZGluZyB3aXRoIG5vIHBhZGRpbmcuIFBlciA8YSBjbGFzcz0naW5mbycgaHJlZj0nI2Jh
c2U2NHVybGxvZ2ljJz5TZWN0aW9uJm5ic3A7NTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdp
bmZvJz5iYXNlNjR1cmwgZW5jb2RpbmcgYXMgdXNlZCBieSBKU09OIFRva2Vuczwvc3Bhbj48c3Bh
bj4pPC9zcGFuPjwvYT4gd2UgbmVlZCB0byBjYWxjdWxhdGUgdGhlIGxlbmd0aCBvZiB0aGUgSlNP
TiBDbGFpbSBTZWdtZW50IHN0cmluZyB3aGljaCBpcyAxNDIgY2hhcmFjdGVycyBhbmQgZGl2aWRl
ZCB0aGF0IG51bWJlciBieSA0IGFuZCBnZXQgdGhlIHJlbWFpbmRlciB3aGljaCBpcyAyLiBQZXIg
PGEgY2xhc3M9J2luZm8nIGhyZWY9JyNQYWRkaW5nSGFuZGxpbmcnPlRhYmxlJm5ic3A7MzxzcGFu
PiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5HdWlkYW5jZSBvbiBob3cgdG8gaGFuZGxlIGJh
c2U2NHVybCBlbmNvZGVkIHZhbHVlcyB3aXRob3V0IHBhZGRpbmcuPC9zcGFuPjxzcGFuPik8L3Nw
YW4+PC9hPiB3ZSBub3cga25vdyB3ZSBuZWVkIHRvIGFkZCB0d28gcGFkZGluZyBieXRlcy4gV2l0
aCB0aGF0IGRhdGEgd2UgY2FuIGJhc2U2NHVybCBkZWNvZGUgdGhlIEpTT04gQ2xhaW0gU2VnbWVu
dCBzdHJpbmcgYW5kIHR1cm4gaXQgaW50byB0aGUgcHJldmlvdXNseSBwcm92aWRlZCBVVEYtOCBi
eXRlIGFycmF5IHdoaWNoIHdlIGNhbiB0aGVuIHRyYW5zbGF0ZSBpbnRvIHRoZSBEZWNvZGVkIEpT
T04gQ2xhaW0gU2VnbWVudCBzdHJpbmcuIEF0IHRoYXQgcG9pbnQgd2UgY2FuIHZhbGlkYXRlIHRo
YXQgdGhlIHJlc3VsdGluZyBzdHJpbmcgaXMgY29tcGxldGVseSBsZWdhbCBKU09OIGFuZCB2YWxp
ZGF0ZSB0aGUgdmFyaW91cyBjbGFpbXMgYW5kIGFsZ29yaXRobS4NCjwvcD4NCjxwPk5vdyB3ZSBq
dXN0IHJlcGVhdCB0aGUgcHJldmlvdXMgcHJvY2VzcyBvZiB1c2luZyB0aGUgZXhwZWN0ZWQga2V5
IGFuZCB0aGUgSlNPTiBDbGFpbSBTZWdtZW50IGFzIGlucHV0IHRvIGEgU0hBIDI1NiBITUFDIGZ1
bmN0aW9uIGFuZCB0aGVuIHRha2luZyB0aGUgb3V0cHV0LCBiYXNlNjR1cmwgZW5jb2RpbmcgaXQg
d2l0aG91dCBwYWRkaW5nIGFuZCBzZWVpbmcgaWYgaXQgaXMgY2hhcmFjdGVyIGZvciBjaGFyYWN0
ZXIgZXF1YWwgdG8gSlNPTiBDcnlwdG8gU2VnbWVudCBpbiB0aGUgSlNPTiBUb2tlbi4NCjwvcD4N
CjxhIG5hbWU9ImFuY2hvcjciPjwvYT48YnIgLz48aHIgLz4NCjx0YWJsZSBzdW1tYXJ5PSJsYXlv
dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249
InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu
YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4NCjxhIG5hbWU9InJmYy5zZWN0aW9uLjMuMiI+PC9h
PjxoMz4zLjIuJm5ic3A7DQpKU09OIFRva2VuIHVzaW5nIEVDRFNBIFAyNTYgU0hBMjU2PC9oMz4N
Cg0KPGEgbmFtZT0iYW5jaG9yOCI+PC9hPjxiciAvPjxociAvPg0KPHRhYmxlIHN1bW1hcnk9Imxh
eW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGln
bj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9D
Jm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0KPGEgbmFtZT0icmZjLnNlY3Rpb24uMy4yLjEi
PjwvYT48aDM+My4yLjEuJm5ic3A7DQpFbmNvZGluZzwvaDM+DQoNCjxwPlRoZSBkZWNvZGVkIEpT
T04gQ2xhaW0gU2VnbWVudCB3ZSB3aWxsIHVzZSBpbiB0aGlzIGV4YW1wbGUgaXM6DQo8L3A+PGJy
IC8+PGhyIGNsYXNzPSJpbnNlcnQiIC8+DQo8YSBuYW1lPSJTYW1wbGVEZWNvZGVkRWNkc2EiPjwv
YT4NCjxkaXYgc3R5bGU9J2Rpc3BsYXk6IHRhYmxlOyB3aWR0aDogMDsgbWFyZ2luLWxlZnQ6IDNl
bTsgbWFyZ2luLXJpZ2h0OiBhdXRvJz48cHJlPnsiaXNzdWVyIjoiam9lIiwNCiAiYWxnb3JpdGht
IjoiRWNkc2FQMjU2U2hhMjU2IiwNCiAibm90X2FmdGVyIjoiMTI4Mjg4NTI0NSIsDQogImh0dHA6
Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfTwvcHJlPjwvZGl2Pjx0YWJsZSBib3JkZXI9IjAi
IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBh
bGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEi
PjxiPiZuYnNwO0ZpZ3VyZSZuYnNwOzI6IFNhbXBsZSBkZWNvZGVkIEpTT04gQ2xhaW0gU2VnbWVu
dCZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3RyPjwvdGFibGU+PGhyIGNsYXNzPSJpbnNl
cnQiIC8+DQoNCjxwPlRoZSBvbmx5IGRpZmZlcmVuY2Ugd2l0aCB0aGUgcHJldmlvdXMgZGVjb2Rl
ZCBKU09OIENsYWltIFNlZ21lbnQgaXMgdGhlIGFsZ29yaXRobS4gSG93ZXZlciB0aGUgcmVzdCBv
ZiB0aGUgcHJvY2VzcyBvZiBnZW5lcmF0aW5nIHRoZSBKU09OIENsYWltIFNlZ21lbnQgaXMgdGhl
IHNhbWUuIFRoZSBmaW5hbCBiYXNlNjR1cmwgd2l0aG91dCBwYWRkaW5nIG91dHB1dCBpcyAiZXlK
cGMzTjFaWElpT2lKcWIyVWlMQW9nSW1Gc1oyOXlhWFJvYlNJNklraHRZV05UYUdFeU5UWWlMQW9n
SW01dmRGOWhablJsY2lJNklqRXlPREk0T0RVeU5EVWlMQW9nSW1oMGRIQTZMeTlsZUdGdGNHeGxM
bU52YlM5cGMxOXliMjkwSWpwMGNuVmxmUSIuDQo8L3A+DQo8cD5UaGUgdmFsdWVzIG9mIHRoZSBF
Q0RTQSBrZXkgdXNlZCBpbiB0aGlzIGV4YW1wbGUsIHByZXNlbnRlZCBhcyBiYXNlNjR1cmwgZW5j
b2RlZCB2YWx1ZXMgd2l0aG91dCBwYWRkaW5nIG9mIGJpZyBlbmRpYW4gYnl0ZSBhcnJheXMgZW5j
b2RpbmcgdW5zaWduZWQgaW50ZWdlcnMgYXJlOg0KPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0
IiAvPg0KPHRhYmxlIGNsYXNzPSJmdWxsIiBhbGlnbj0iY2VudGVyIiBib3JkZXI9IjAiIGNlbGxw
YWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+DQo8Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFsaWdu
PSJsZWZ0Ij4NCjx0cj48dGggYWxpZ249ImxlZnQiPlBhcmFtZXRlciBOYW1lPC90aD48dGggYWxp
Z249ImxlZnQiPlZhbHVlPC90aD48L3RyPg0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij54PC90ZD4N
Cjx0ZCBhbGlnbj0ibGVmdCI+MkppLWRCZFY0NUFyem1zV0lkc0xLMU05TzgyLTBUQnFfOVpZRnph
azYxYzwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij55PC90ZD4NCjx0ZCBhbGln
bj0ibGVmdCI+b0NyMmJGY2NUVENMSFJnSDVPNGwxbHFKamdsemdGbkRuSG9hOVJ6S0g3TTwvdGQ+
DQo8L3RyPg0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij5kPC90ZD4NCjx0ZCBhbGlnbj0ibGVmdCI+
Z1lJang3cGtjR0p5T3JyZnltS2UtWmFJN25wVHU0WWdCVVZvRlNlOFdqbzwvdGQ+DQo8L3RyPg0K
PC90YWJsZT4NCjxiciBjbGVhcj0iYWxsIiAvPg0KPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHBhZGRp
bmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBhbGlnbj0iY2VudGVyIj48dHI+PHRkIGFsaWduPSJjZW50
ZXIiPjxmb250IGZhY2U9Im1vbmFjbywgTVMgU2FucyBTZXJpZiIgc2l6ZT0iMSI+PGI+Jm5ic3A7
RUNEU0EgRXhhbXBsZSBrZXkgdmFsdWVzJm5ic3A7PC9iPjwvZm9udD48YnIgLz48L3RkPjwvdHI+
PC90YWJsZT48aHIgY2xhc3M9Imluc2VydCIgLz4NCg0KPHA+VGhlIEVDRFNBIGtleSAodGhlIHB1
YmxpYyBwYXJ0LCB4IGFuZCB5LCBwbHVzIHRoZSBwcml2YXRlIHBhcnQgZCkgYXJlIHRoZW4gcGFz
c2VkIHRvIGEgRUNEU0Egc2lnbmluZyBmdW5jdGlvbiB3aGljaCBhbHNvIHRha2VzIHRoZSBjdXJ2
ZSB0eXBlLCBQMjU2LCB0aGUgaGFzaCB0eXBlLCBTSEEgMjU2IGFuZCB0aGUgSlNPTiBDbGFpbSBT
ZWdtZW50IGFzIGlucHV0cy4gSXQgd2lsbCBvdXRwdXQgdHdvIHVuc2lnbmVkIGludGVnZXJzIFIg
YW5kIFMuIEluIHRoaXMgZXhhbXBsZSB0aGUgUiBhbmQgUyB2YWx1ZXMsIGdpdmVuIGFzIGJ5dGUg
YXJyYXlzIGluIGJpZyBlbmRpYW4gb3JkZXIgYXJlOg0KPC9wPjxiciAvPjxociBjbGFzcz0iaW5z
ZXJ0IiAvPg0KPHRhYmxlIGNsYXNzPSJmdWxsIiBhbGlnbj0iY2VudGVyIiBib3JkZXI9IjAiIGNl
bGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+DQo8Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFs
aWduPSJsZWZ0Ij4NCjx0cj48dGggYWxpZ249ImxlZnQiPlBhcmFtZXRlciBOYW1lPC90aD48dGgg
YWxpZ249ImxlZnQiPlZhbHVlPC90aD48L3RyPg0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij5SPC90
ZD4NCjx0ZCBhbGlnbj0ibGVmdCI+WzQzLCA3NiwgMjI2LCA1NywgMjA1LCAxOTcsIDEyNiwgNzcs
IDQyLCAyMDIsIDI0NiwNCiAgICA1NSwgNzgsIDIwOSwgMjUzLCAxNjUsIDE2OSwgMTE3LCAzLCAx
ODYsIDIxOSwgMTI1LA0KICAgIDYzLCAyMTUsIDkzLCAyMDksIDEyNywgMTE3LCAyMzgsIDIyNSwg
MjYsIDI0OV08L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBhbGlnbj0ibGVmdCI+UzwvdGQ+DQo8dGQg
YWxpZ249ImxlZnQiPlsyMzMsIDMyLCAxMjgsIDksIDksIDE5MiwgNjAsIDE4MSwgNTgsIDI0NCwg
NzMsIDQ2LA0KICAgIDEwNSwgMTkwLCAyMDAsIDIwMiwgMjA4LCAxMjksIDE1NSwgMTczLCAyNDks
IDEzOSwNCiAgICAyMTYsIDEwOSwgMjQ1LCA4MSwgMjMyLCAxMTksIDIwMiwgNTcsIDQsIDEzOF08
L3RkPg0KPC90cj4NCjwvdGFibGU+DQo8YnIgY2xlYXI9ImFsbCIgLz4NCjx0YWJsZSBib3JkZXI9
IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0
ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9
IjEiPjxiPiZuYnNwO1IgYW5kIFMgdmFsdWVzIGFzIGJpZyBlbmRpYW4gYnl0ZSBhcnJheXMmbmJz
cDs8L2I+PC9mb250PjxiciAvPjwvdGQ+PC90cj48L3RhYmxlPjxociBjbGFzcz0iaW5zZXJ0IiAv
Pg0KDQo8cD5XZSB0aGVuIGNvbmNhdGVuYXRlIHRoZSBTIGFycmF5IHRvIHRoZSBlbmQgb2YgdGhl
IFIgYXJyYXkgYW5kIGJhc2U2NHVybCBlbmNvZGUgdGhlIHJlc3VsdCB3aXRob3V0IHBhZGRpbmcg
cHJvZHVjaW5nIHRoZSBKU09OIENyeXB0byBTZWdtZW50IHN0cmluZyAiSzB6aU9jM0ZmazBxeXZZ
M1R0SDlwYWwxQTdyYmZUX1hYZEZfZGU3aEd2bnBJSUFKQ2NBOHRUcjBTUzVwdnNqSzBJR2JyZm1M
MkczMVVlaDN5amtFaWciLg0KPC9wPg0KPHA+VGhlIEpTT04gVG9rZW4gd291bGQgdGhlcmVmb3Jl
IGJlIHRoZSBzdHJpbmcgIkswemlPYzNGZmswcXl2WTNUdEg5cGFsMUE3cmJmVF9YWGRGX2RlN2hH
dm5wSUlBSkNjQTh0VHIwU1M1cHZzakswSUdicmZtTDJHMzFVZWgzeWprRWlnLmV5SnBjM04xWlhJ
aU9pSnFiMlVpTEFvZ0ltRnNaMjl5YVhSb2JTSTZJa2h0WVdOVGFHRXlOVFlpTEFvZ0ltNXZkRjlo
Wm5SbGNpSTZJakV5T0RJNE9EVXlORFVpTEFvZ0ltaDBkSEE2THk5bGVHRnRjR3hsTG1OdmJTOXBj
MTl5YjI5MElqcDBjblZsZlEiLg0KPC9wPg0KPGEgbmFtZT0iYW5jaG9yOSI+PC9hPjxiciAvPjxo
ciAvPg0KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n
PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+
PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0KPGEg
bmFtZT0icmZjLnNlY3Rpb24uMy4yLjIiPjwvYT48aDM+My4yLjIuJm5ic3A7DQpEZWNvZGluZzwv
aDM+DQoNCjxwPkRlY29kaW5nIHRoZSBKU09OIFRva2VuIGZyb20gdGhpcyBleGFtcGxlIHJlcXVp
cmVzIHByb2Nlc3NpbmcgdGhlIEpTT04gQ2xhaW0gU2VnbWVudCBleGFjdGx5IGFzIGhhbmRsZWQg
aW4gdGhlIHByZXZpb3VzIGV4YW1wbGUuIFZhbGlkYXRpbmcgdGhlIEpTT04gQ3J5cHRvIFNlZ21l
bnQgaXMgYSBsaXR0bGUgZGlmZmVyZW5jZS4gV2UgbXVzdCBiYXNlNjR1cmwgZGVjb2RlIHRoZSBK
U09OIENyeXB0byBTZWdtZW50IGFzIGluIHRoZSBwcmV2aW91cyBleGFtcGxlIGJ1dCB3ZSB0aGVu
IG5lZWQgdG8gc3BsaXQgdGhlIDY0IG1lbWJlciBieXRlIGFycmF5IHRoYXQgbXVzdCByZXN1bHQg
aW50byB0d28gMzIgYnl0ZSBhcnJheXMsIHRoZSBmaXJzdCBSIGFuZCB0aGUgc2Vjb25kIFMuIFdl
IHRoZW4gaGF2ZSB0byBwYXNzIHgsIHksIFIsIFMgYW5kIHRoZSBKU09OIENsYWltIFNlZ21lbnQg
dG8gYW4gRUNEU0Egc2lnbmF0dXJlIHZlcmlmaWVyIHRoYXQgaGFzIGJlZW4gY29uZmlndXJlZCB0
byB1c2UgdGhlIFAyNTYgY3VydmUgd2l0aCB0aGUgU0hBIDI1NiBoYXNoIGZ1bmN0aW9uLiBBcyBl
eHBsYWluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9JyNEZWZpbmluZ0VDRFNBJz5TZWN0aW9u
Jm5ic3A7OTxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5Qcm90ZWN0aW5nIGEgSlNP
TiBUb2tlbiB3aXRoIEVDRFNBPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiB0aGUgdXNlIG9mIHRo
ZSBrIHZhbHVlIGluIEVDRFNBIG1lYW5zIHRoYXQgd2UgY2Fubm90IHZhbGlkYXRlIHRoZSBjb3Jy
ZWN0bmVzcyBvZiB0aGUgc2lnbmF0dXJlIGluIHRoZSBzYW1lIHdheSB3ZSB2YWxpZGF0ZWQgdGhl
IGNvcnJlY3RuZXNzIG9mIHRoZSBITUFDPiBXZSBoYXZlIHRvIGRlcGVuZCBvbiBhbiBFQ0RTQSB2
YWxpZGF0b3IgdG8gdmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBmb3IgdXMuDQo8L3A+DQo8YSBuYW1l
PSJhbmNob3IxMCI+PC9hPjxiciAvPjxociAvPg0KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2Vs
bHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQi
Pjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9h
PjwvdGQ+PC90cj48L3RhYmxlPg0KPGEgbmFtZT0icmZjLnNlY3Rpb24uNCI+PC9hPjxoMz40LiZu
YnNwOw0KQ2xhaW1zIHRoYXQgY2FuIGJlIG1hZGUgaW4gYSBKU09OIFRva2VuPC9oMz4NCg0KPHA+
VGhlIG1lbWJlcnMgb2YgdGhlIEpTT04gb2JqZWN0IGNvbnRhaW4gdGhlIGNsYWltcyBtYWRlIGJ5
IHRoZSBKU09ODQogICAgICBUb2tlbi4gVGhlIGZvbGxvd2luZyBsaXN0cyBzb21lIHByZS1kZWZp
bmVkIGNsYWltcy4gTm90ZSBob3dldmVyIHdoYXQNCiAgICAgIGNsYWltcyBhIEpTT04gVG9rZW4g
bXVzdCBjb250YWluIHRvIGJlIGNvbnNpZGVyZWQgdmFsaWQgZGVwZW5kcyBvbiB0aGUNCiAgICAg
IGNvbnRleHQgaW4gd2hpY2ggdGhlIEpTT04gVG9rZW4gaXMgdXNlZCBhbmQgaXMgb3V0c2lkZSB0
aGUgc2NvcGUgb2YgdGhpcw0KICAgICAgc3BlY2lmaWNhdGlvbi4gTm9uZSBvZiB0aGUgY2xhaW1z
IGRlZmluZWQgaW4gdGhlIHRhYmxlIGJlbG93IGFyZQ0KICAgICAgaW50ZW5kZWQgdG8gYmUgbWFu
ZGF0b3J5IGJ1dCByYXRoZXIgYXMgYSBzdGFydGluZyBwb2ludCBmb3IgYSBjYXRhbG9nIG9mDQog
ICAgICB1c2VmdWwgY2xhaW1zLg0KPC9wPjxiciAvPjxociBjbGFzcz0iaW5zZXJ0IiAvPg0KPGEg
bmFtZT0iQ2xhaW1UYWJsZSI+PC9hPg0KPHRhYmxlIGNsYXNzPSJmdWxsIiBhbGlnbj0iY2VudGVy
IiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+DQo8Y29sIGFsaWdu
PSJsZWZ0Ij48Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFsaWduPSJs
ZWZ0Ij4NCjx0cj48dGggYWxpZ249ImxlZnQiPkNsYWltIE5hbWU8L3RoPjx0aCBhbGlnbj0ibGVm
dCI+SlNPTiBWYWx1ZSBUeXBlPC90aD48dGggYWxpZ249ImxlZnQiPkNsYWltIFN5bnRheDwvdGg+
PHRoIGFsaWduPSJsZWZ0Ij5DbGFpbSBTZW1hbnRpY3M8L3RoPjwvdHI+DQo8dHI+DQo8dGQgYWxp
Z249ImxlZnQiPmlzc3VlcjwvdGQ+DQo8dGQgYWxpZ249ImxlZnQiPnN0cmluZzwvdGQ+DQo8dGQg
YWxpZ249ImxlZnQiPlN0cmluZ0FuZFVSSTwvdGQ+DQo8dGQgYWxpZ249ImxlZnQiPklkZW50aWZp
ZXMgdGhlIHByaW5jaXBhbCB3aG8gaXNzdWVkIHRoZSBKU09OIFRva2VuLjwvdGQ+DQo8L3RyPg0K
PHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij5hbGdvcml0aG08L3RkPg0KPHRkIGFsaWduPSJsZWZ0Ij5z
dHJpbmc8L3RkPg0KPHRkIGFsaWduPSJsZWZ0Ij5TdHJpbmdBbmRVUkk8L3RkPg0KPHRkIGFsaWdu
PSJsZWZ0Ij5JZGVudGlmaWVzIHRoZSBjcnlwdG9ncmFwaGljIGFsZ29yaXRobSBiZWluZyB1c2Vk
IHRvIHNlY3VyZSB0aGUNCiAgICAgICAgSlNPTiBUb2tlbi48L3RkPg0KPC90cj4NCjx0cj4NCjx0
ZCBhbGlnbj0ibGVmdCI+bm90X2FmdGVyPC90ZD4NCjx0ZCBhbGlnbj0ibGVmdCI+aW50ZWdlcjwv
dGQ+DQo8dGQgYWxpZ249ImxlZnQiPkludERhdGU8L3RkPg0KPHRkIGFsaWduPSJsZWZ0Ij5JZGVu
dGlmaWVzIHRoZSB0aW1lIG9uIG9yIGFmdGVyIHdoaWNoIHRoZSB0b2tlbiBNVVNUIE5PVCBiZQ0K
ICAgICAgICBhY2NlcHRlZCBmb3IgcHJvY2Vzc2luZy48L3RkPg0KPC90cj4NCjwvdGFibGU+DQo8
YnIgY2xlYXI9ImFsbCIgLz4NCjx0YWJsZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxs
c3BhY2luZz0iMiIgYWxpZ249ImNlbnRlciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBm
YWNlPSJtb25hY28sIE1TIFNhbnMgU2VyaWYiIHNpemU9IjEiPjxiPiZuYnNwO1RhYmxlIDE6IEEg
bGlzdCBvZiBjbGFpbSBkZWZpbml0aW9ucyZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3Ry
PjwvdGFibGU+PGhyIGNsYXNzPSJpbnNlcnQiIC8+DQoNCjxwPlRoZSBjbGFpbSBzeW50YXhlcyBy
ZWZlcnJlZCB0byBhYm92ZSBhcmUgZGVmaW5lZCBiZWxvdzoNCjwvcD48YnIgLz48aHIgY2xhc3M9
Imluc2VydCIgLz4NCjxhIG5hbWU9IkNsYWltU3ludGF4RGVmaW5pdGlvbiI+PC9hPg0KPHRhYmxl
IGNsYXNzPSJmdWxsIiBhbGlnbj0iY2VudGVyIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIyIiBj
ZWxsc3BhY2luZz0iMiI+DQo8Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFsaWduPSJsZWZ0Ij4NCjx0
cj48dGggYWxpZ249ImxlZnQiPkNsYWltIFN5bnRheCBOYW1lPC90aD48dGggYWxpZ249ImxlZnQi
PkNsYWltIFN5bnRheCBEZWZpbml0aW9uPC90aD48L3RyPg0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0
Ij5TdHJpbmdBbmRVUkk8L3RkPg0KPHRkIGFsaWduPSJsZWZ0Ij5Bbnkgc3RyaW5nIHZhbHVlIE1B
WSBiZSB1c2VkIGJ1dCBhIHZhbHVlIGNvbnRhaW5pbmcgYSAiOiIgY2hhcmFjdGVyDQogICAgICAg
IE1VU1QgYmUgYSBVUkkgYXMgZGVmaW5lZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzM5
ODYnPlJGQw0KICAgICAgICAzOTg2PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkJl
cm5lcnMtTGVlLCBULiwgRmllbGRpbmcsIFIuLCBhbmQgTC4gTWFzaW50ZXIsICZsZHF1bztVbmlm
b3JtIFJlc291cmNlIElkZW50aWZpZXIgKFVSSSk6IEdlbmVyaWMgU3ludGF4LCZyZHF1bzsgSmFu
dWFyeSZuYnNwOzIwMDUuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDMzk4Nl0uPC90ZD4N
CjwvdHI+DQo8dHI+DQo8dGQgYWxpZ249ImxlZnQiPkludERhdGU8L3RkPg0KPHRkIGFsaWduPSJs
ZWZ0Ij5UaGUgbnVtYmVyIG9mIHNlY29uZHMgZnJvbSAxOTcwLTAxLTAxVDA6MDowWiBhcyBtZWFz
dXJlZCBpbiBVVEMNCiAgICAgICAgdW50aWwgdGhlIGRlc2lyZWQgZGF0ZS90aW1lLiBTZWUgPGEg
Y2xhc3M9J2luZm8nIGhyZWY9JyNSRkMzMzM5Jz5SRkMNCiAgICAgICAgMzMzOTxzcGFuPiAoPC9z
cGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5LbHluZSwgRy4sIEVkLiBhbmQgQy4gTmV3bWFuLCAmbGRx
dW87RGF0ZSBhbmQgVGltZSBvbiB0aGUgSW50ZXJuZXQ6IFRpbWVzdGFtcHMsJnJkcXVvOyBKdWx5
Jm5ic3A7MjAwMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkMzMzM5XSBmb3IgZGV0YWls
cyByZWdhcmRpbmcgZGF0ZS90aW1lcyBpbiBnZW5lcmFsIGFuZCBVVEMgaW4NCiAgICAgICAgcGFy
dGljdWxhci48L3RkPg0KPC90cj4NCjwvdGFibGU+DQo8YnIgY2xlYXI9ImFsbCIgLz4NCjx0YWJs
ZSBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgYWxpZ249ImNlbnRl
ciI+PHRyPjx0ZCBhbGlnbj0iY2VudGVyIj48Zm9udCBmYWNlPSJtb25hY28sIE1TIFNhbnMgU2Vy
aWYiIHNpemU9IjEiPjxiPiZuYnNwO1RhYmxlIDI6IEEgbGlzdCBvZiBzeW50YXggdHlwZXMgdXNl
ZCBpbiBjbGFpbSBkZWZpbml0aW9ucyZuYnNwOzwvYj48L2ZvbnQ+PGJyIC8+PC90ZD48L3RyPjwv
dGFibGU+PGhyIGNsYXNzPSJpbnNlcnQiIC8+DQoNCjxwPjwvcD4NCjxvbCBjbGFzcz0idGV4dCI+
DQo8bGk+VGhlIHByb2Nlc3Npbmcgb2YgdGhlIGlzc3VlciBjbGFpbSBpcyBnZW5lcmFsbHkgYXBw
bGljYXRpb24NCiAgICAgICAgICBzcGVjaWZpYy4NCjwvbGk+DQo8bGk+VGhlIHByb2Nlc3Npbmcg
b2YgdGhlIGFsZ29yaXRobSBjbGFpbSByZXF1aXJlcyB0aGF0LCBpZiBwcmVzZW50LA0KICAgICAg
ICAgIHRoZSB2YWx1ZSBvZiB0aGUgYWxnb3JpdGhtIGNsYWltIE1VU1QgYmUgb25lIHRoYXQgaXMg
Ym90aCBzdXBwb3J0ZWQNCiAgICAgICAgICBhbmQgZm9yIHdoaWNoIHRoZXJlIGV4aXN0cyBhIGtl
eSBhc3NvY2lhdGVkIHdpdGggdGhlIGlzc3VlciBvZiB0aGUNCiAgICAgICAgICBKU09OIFRva2Vu
LiBOb3RlIGhvd2V2ZXIgdGhhdCBpZiB0aGUgaXNzdWVyIGNsYWltIGlzIG5vdCBpbmNsdWRlZA0K
ICAgICAgICAgIHRoZW4gdGhlIG1hbm5lciBpbiB3aGljaCB0aGUgaXNzdWVyIGlzIGRldGVybWlu
ZWQgaXMgYXBwbGljYXRpb24NCiAgICAgICAgICBzcGVjaWZpYy4NCjwvbGk+DQo8bGk+VGhlIHBy
b2Nlc3Npbmcgb2YgdGhlIG5vdF9hZnRlciBjbGFpbSByZXF1aXJlcyB0aGF0IHRoZSBjdXJyZW50
DQogICAgICAgICAgZGF0ZS90aW1lIE1VU1QgYmUgYmVmb3JlIHRoZSBkYXRlL3RpbWUgbGlzdGVk
IGluIHRoZSBub3RfYWZ0ZXIgY2xhaW0NCiAgICAgICAgICBpZiBwcmVzZW50LiBJbXBsZW1lbnRl
cnMgTUFZIHByb3ZpZGUgZm9yIHNvbWUgc21hbGwgbGVld2F5LCB1c3VhbGx5DQogICAgICAgICAg
bm8gbW9yZSB0aGFuIGEgZmV3IG1pbnV0ZXMsIHRvIGFjY291bnQgZm9yIGNsb2NrIHNrZXcuDQo8
L2xpPg0KPC9vbD48cD5FRElUT1InUyBOT1RFOiBFZGl0IHRoZSBwcmV2aW91cyB0ZXh0IGluIHNv
IGl0J3MgbW9yZQ0KICAgICAgbmF0dXJhbC4NCjwvcD4NCjxhIG5hbWU9ImFuY2hvcjExIj48L2E+
PGJyIC8+PGhyIC8+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2Vs
bHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0i
VE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFi
bGU+DQo8YSBuYW1lPSJyZmMuc2VjdGlvbi40LjEiPjwvYT48aDM+NC4xLiZuYnNwOw0KR2VuZXJh
dGluZyB1bmlxdWUgbmFtZXMgYW5kIHZhbHVlczwvaDM+DQoNCjxwPkJvdGggY2xhaW0gbmFtZXMg
YXMgd2VsbCBhcyBhbGdvcml0aG0gdmFsdWVzIGNhbiBiZSBkZWZpbmVkIGF0IHdpbGwNCiAgICAg
ICAgYnkgdGhvc2UgdXNpbmcgSlNPTiBUb2tlbnMuIEhvd2V2ZXIsIGluIG9yZGVyIHRvIHByZXZl
bnQgY29sbGlzaW9ucywNCiAgICAgICAgYW55IG5ldyBjbGFpbSBuYW1lIG9yIGFsZ29yaXRobSB2
YWx1ZSBNVVNUIGVpdGhlciBiZSBkZWZpbmVkIGluIGFuIFJGQw0KICAgICAgICBwdWJsaXNoZWQg
dmlhIHRoZSBJRVRGIG9yIE1VU1QgYmUgZGVmaW5lZCBhcyBhIFVSSSB0aGF0IGNvbnRhaW5zIGEN
CiAgICAgICAgY29sbGlzaW9uIHJlc2lzdGFudCBuYW1lc3BhY2UuIEV4YW1wbGVzIG9mIGNvbGxp
c2lvbiByZXNpc3RhbnQNCiAgICAgICAgbmFtZXNwYWNlcyBpbmNsdWRlOiA8L3A+DQo8dWwgY2xh
c3M9InRleHQiPg0KPGxpPkRvbWFpbiBOYW1lcywNCjwvbGk+DQo8bGk+T2JqZWN0IElkZW50aWZp
ZXJzIChPSURzKSBhcyBkZWZpbmVkIGluIHRoZSBJVFUtVCBYIDY2MCBhbmQgWA0KICAgICAgICAg
ICAgNjcwIFJlY29tbWVuZGF0aW9uIHNlcmllcyBvcg0KPC9saT4NCjxsaT5Vbml2ZXJzYWxseSBV
bmlxdWUgSURlbnRpZmllciAoVVVJRCkgYXMgZGVmaW5lZCBpbiA8YSBjbGFzcz0naW5mbycgaHJl
Zj0nI1JGQzQxMjInPlJGQyA0MTIyPHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPkxl
YWNoLCBQLiwgTWVhbGxpbmcsIE0uLCBhbmQgUi4gU2FseiwgJmxkcXVvO0EgVW5pdmVyc2FsbHkg
VW5pcXVlIElEZW50aWZpZXIgKFVVSUQpIFVSTiBOYW1lc3BhY2UsJnJkcXVvOyBKdWx5Jm5ic3A7
MjAwNS48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM0MTIyXS4NCjwvbGk+DQo8L3VsPjxw
PiBJbiBlYWNoIGNhc2UgdGhlIGRlZmluZXIgb2YgdGhlIG5hbWUgb3IgdmFsdWUgTVVTVCB0YWtl
DQogICAgICAgIHJlYXNvbmFibGUgcHJlY2F1dGlvbnMgdG8gbWFrZSBzdXJlIHRoZXkgYXJlIGlu
IGNvbnRyb2wgb2YgdGhlIHBhcnQgb2YNCiAgICAgICAgdGhlIG5hbWVzcGFjZSB0aGV5IHVzZSB0
byBkZWZpbmUgdGhlIG5hbWUgb3IgdmFsdWUuDQo8L3A+DQo8YSBuYW1lPSJiYXNlNjR1cmxsb2dp
YyI+PC9hPjxiciAvPjxociAvPg0KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9
IjAiIGNlbGxzcGFjaW5nPSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQg
Y2xhc3M9IlRPQ2J1ZyI+PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90
cj48L3RhYmxlPg0KPGEgbmFtZT0icmZjLnNlY3Rpb24uNSI+PC9hPjxoMz41LiZuYnNwOw0KYmFz
ZTY0dXJsIGVuY29kaW5nIGFzIHVzZWQgYnkgSlNPTiBUb2tlbnM8L2gzPg0KDQo8cD5KU09OIFRv
a2VucyBtYWtlIHVzZSBvZiB0aGUgYmFzZTY0dXJsIGVuY29kaW5nIGFzIGRlZmluZWQgaW4gPGEg
Y2xhc3M9J2luZm8nIGhyZWY9JyNSRkM0NjQ4Jz5SRkMgNDY0ODxzcGFuPiAoPC9zcGFuPjxzcGFu
IGNsYXNzPSdpbmZvJz5Kb3NlZnNzb24sIFMuLCAmbGRxdW87VGhlIEJhc2UxNiwgQmFzZTMyLCBh
bmQgQmFzZTY0IERhdGEgRW5jb2RpbmdzLCZyZHF1bzsgT2N0b2JlciZuYnNwOzIwMDYuPC9zcGFu
PjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDNDY0OF0uIEhvd2V2ZXIgYXMgYWxsb3dlZCBieSBzZWN0
aW9uIDMuMiBvZg0KICAgICAgUkZDIDQ2NDggdGhpcyBzcGVjaWZpY2F0aW9uIG1hbmRhdGVzIHRo
YXQgYmFzZTY0dXJsIGVuY29kaW5nIHdoZW4gdXNlZA0KICAgICAgd2l0aCBKU09OIFRva2VucyBN
VVNUIE5PVCB1c2UgcGFkZGluZy4gVGhlIHJlYXNvbiBmb3IgdGhpcyByZXN0cmljdGlvbg0KICAg
ICAgaXMgdGhhdCB0aGUgcGFkZGluZyBjaGFyYWN0ZXIgaXMgbm90IFVSTCBzYWZlLg0KPC9wPg0K
PHA+VG8gcHJvY2VzcyBhIGJhc2U2NHVybCB2YWx1ZSBpbiBhIEpTT04gVG9rZW4gb25lIG11c3Qg
Zmlyc3QgY2FsY3VsYXRlDQogICAgICB0aGUgc2l6ZSBvZiB0aGUgYmFzZTY0dXJsIHZhbHVlIGFu
ZCB0aGVuIGRpdmlkZSB0aGF0IHNpemUgYnkgZm91ciB1c2luZw0KICAgICAgbW9kdWxhciBhcml0
aG1ldGljLiBMb29rIHVwIHRoZSByZW1haW5kZXIgb2YgdGhlIG1vZHVsYXIgZGl2aXNpb24gaW4g
dGhlDQogICAgICB0YWJsZSBiZWxvdy4NCjwvcD48YnIgLz48aHIgY2xhc3M9Imluc2VydCIgLz4N
CjxhIG5hbWU9IlBhZGRpbmdIYW5kbGluZyI+PC9hPg0KPHRhYmxlIGNsYXNzPSJmdWxsIiBhbGln
bj0iY2VudGVyIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+DQo8
Y29sIGFsaWduPSJsZWZ0Ij48Y29sIGFsaWduPSJsZWZ0Ij4NCjx0cj48dGggYWxpZ249ImxlZnQi
PlJlbWFpbmRlcjwvdGg+PHRoIGFsaWduPSJsZWZ0Ij5BY3Rpb24gdG8gdGFrZTwvdGg+PC90cj4N
Cjx0cj4NCjx0ZCBhbGlnbj0ibGVmdCI+MDwvdGQ+DQo8dGQgYWxpZ249ImxlZnQiPk5vIHBhZGRp
bmcgaXMgbmVlZGVkLjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIGFsaWduPSJsZWZ0Ij4xPC90ZD4N
Cjx0ZCBhbGlnbj0ibGVmdCI+VGhlIGJhc2U2NHVybCBlbmNvZGVkIHZhbHVlIGlzIG1hbGZvcm1l
ZCBhbmQgTVVTVCBiZSByZWplY3RlZCBmb3INCiAgICAgICAgcHJvY2Vzc2luZy48L3RkPg0KPC90
cj4NCjx0cj4NCjx0ZCBhbGlnbj0ibGVmdCI+MjwvdGQ+DQo8dGQgYWxpZ249ImxlZnQiPlR3byBw
YWRkaW5nIGNoYXJhY3RlcnMgYXJlIG5lZWRlZC48L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBhbGln
bj0ibGVmdCI+MzwvdGQ+DQo8dGQgYWxpZ249ImxlZnQiPk9uZSBwYWRkaW5nIGNoYXJhY3RlciBp
cyBuZWVkZWQuPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KPGJyIGNsZWFyPSJhbGwiIC8+DQo8dGFi
bGUgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGFsaWduPSJjZW50
ZXIiPjx0cj48dGQgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0ibW9uYWNvLCBNUyBTYW5zIFNl
cmlmIiBzaXplPSIxIj48Yj4mbmJzcDtUYWJsZSAzOiBHdWlkYW5jZSBvbiBob3cgdG8gaGFuZGxl
IGJhc2U2NHVybCBlbmNvZGVkIHZhbHVlcyB3aXRob3V0IHBhZGRpbmcuJm5ic3A7PC9iPjwvZm9u
dD48YnIgLz48L3RkPjwvdHI+PC90YWJsZT48aHIgY2xhc3M9Imluc2VydCIgLz4NCg0KPGEgbmFt
ZT0iYW5jaG9yMTIiPjwvYT48YnIgLz48aHIgLz4NCjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl
bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0
Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv
YT48L3RkPjwvdHI+PC90YWJsZT4NCjxhIG5hbWU9InJmYy5zZWN0aW9uLjYiPjwvYT48aDM+Ni4m
bmJzcDsNCkdlbmVyYWwgcnVsZXMgZm9yIGNyZWF0aW5nIGFuZCB2YWxpZGF0aW5nIGEgSlNPTiBU
b2tlbjwvaDM+DQoNCjxwPlRvIGNyZWF0ZSBhIEpTT04gVG9rZW4gb25lIE1VU1QgZm9sbG93IHRo
ZXNlIHN0ZXBzOiA8L3A+DQo8b2wgY2xhc3M9InRleHQiPg0KPGxpPkNyZWF0ZSBhIEpTT04gb2Jq
ZWN0IGNvbnRhaW5pbmcgdGhlIGRlc2lyZWQgY2xhaW1zLg0KPC9saT4NCjxsaT5UcmFuc2xhdGUg
dGhlIEpTT04gb2JqZWN0J3MgVW5pY29kZSBjb2RlIHBvaW50cyBpbnRvIFVURi04IGFzDQogICAg
ICAgICAgZGVmaW5lZCBpbiA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzM2MjknPlJGQyAzNjI5
PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xhc3M9J2luZm8nPlllcmdlYXUsIEYuLCAmbGRxdW87VVRG
LTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIElTTyAxMDY0NiwmcmRxdW87IE5vdmVtYmVy
Jm5ic3A7MjAwMy48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkMzNjI5XS4NCjwvbGk+DQo8
bGk+YmFzZTY0dXJsIGVuY29kZSB0aGUgSlNPTiBvYmplY3QgYXMgZGVmaW5lZCBpbiB0aGlzDQog
ICAgICAgICAgc3BlY2lmaWNhdGlvbi4gVGhpcyBjcmVhdGVzIHRoZSBKU09OIENsYWltIFNlZ21l
bnQuDQo8L2xpPg0KPGxpPkNyZWF0ZSB0aGUgSlNPTiBDcnlwdG8gc2VnbWVudCBhcyBkZWZpbmVk
IGZvciB0aGUgcGFydGljdWxhcg0KICAgICAgICAgIGFsZ29yaXRobSBiZWluZyB1c2VkLg0KPC9s
aT4NCjxsaT5Db21iaW5lIHRoZSBKU09OIENyeXB0byBzZWdtZW50IGFuZCB0aGVuIHRoZSBKU09O
IFRva2VuIHNlZ21lbnQsDQogICAgICAgICAgc2VwYXJhdGVkIGJ5IGEgcGVyaW9kIGNoYXJhY3Rl
ciB0byBjcmVhdGUgYSBKU09OIFRva2VuLg0KPC9saT4NCjwvb2w+DQoNCjxwPldoZW4gdmFsaWRh
dGluZyBhIEpTT04gVG9rZW4gdGhlIGZvbGxvd2luZyBzdGVwcyBNVVNUIGJlIHRha2VuLiBJZg0K
ICAgICAgYW55IG9mIHRoZSBsaXN0ZWQgc3RlcHMgZmFpbHMgdGhlbiB0aGUgdG9rZW4gTVVTVCBi
ZSByZWplY3RlZCBmb3INCiAgICAgIHByb2Nlc3NpbmcuDQo8L3A+DQo8cD48L3A+DQo8b2wgY2xh
c3M9InRleHQiPg0KPGxpPlRoZSBKU09OIFRva2VuIE1VU1QgY29udGFpbiBleGFjdGx5IG9uZSBw
ZXJpb2QgY2hhcmFjdGVyLg0KPC9saT4NCjxsaT5UaGUgSlNPTiBUb2tlbiBNVVNUIGJlIHNwbGl0
IG9uIHRoZSBwZXJpb2QgY2hhcmFjdGVyIHJlc3VsdGluZyBpbg0KICAgICAgICAgIHR3byBub24t
ZW1wdHkgc2VnbWVudHMuDQo8L2xpPg0KPGxpPlRoZSBKU09OIENsYWltIFNlZ21lbnQgKHRoZSBz
ZWNvbmQgb2YgdGhlIHR3bykgTVVTVCBiZQ0KICAgICAgICAgIHN1Y2Nlc3NmdWxseSBiYXNlNjR1
cmwgZGVjb2RlZCBmb2xsb3dpbmcgdGhlIHJlc3RyaWN0aW9uIGdpdmVuIGluDQogICAgICAgICAg
dGhpcyBzcGVjIHRoYXQgbm8gcGFkZGluZyBjaGFyYWN0ZXJzIG1heSBoYXZlIGJlZW4gdXNlZC4N
CjwvbGk+DQo8bGk+VGhlIERlY29kZWQgSlNPTiBDbGFpbSBTZWdtZW50IE1VU1QgYmUgY29tcGxl
dGVseSB2YWxpZCBKU09ODQogICAgICAgICAgc3ludGF4Lg0KPC9saT4NCjxsaT5UaGUgSlNPTiBD
bGFpbSBTZWdtZW50IE1VU1QgYmUgdmFsaWRhdGVkIHRvIG9ubHkgaW5jbHVkZSBjbGFpbXMNCiAg
ICAgICAgICB3aG9zZSBzeW50YXggYW5kIHNlbWFudGljcyBhcmUgYm90aCB1bmRlcnN0b29kIGFu
ZCBzdXBwb3J0ZWQuDQo8L2xpPg0KPGxpPlRoZSBKU09OIENyeXB0byBTZWdtZW50IE1VU1QgYmUg
c3VjY2Vzc2Z1bGx5IHZhbGlkYXRlZCBhZ2FpbnN0DQogICAgICAgICAgdGhlIEpTT04gQ2xhaW0g
U2VnbWVudCBpbiB0aGUgbWFubmVyIGRlZmluZWQgZm9yIHRoZSB0eXBlIG9mDQogICAgICAgICAg
YWxnb3JpdGhtIGJlaW5nIHVzZWQuDQo8L2xpPg0KPC9vbD4NCg0KPHA+UHJvY2Vzc2luZyBhIEpT
T04gVG9rZW4gaW5ldml0YWJseSByZXF1aXJlcyBjb21wYXJpbmcga25vd24gc3RyaW5ncw0KICAg
ICAgdG8gdmFsdWVzIGluIHRoZSB0b2tlbi4gRm9yIGV4YW1wbGUsIGluIGNoZWNraW5nIHdoYXQg
dGhlIGFsZ29yaXRobSBpcw0KICAgICAgKGFzc3VtaW5nIHRoZSBhbGdvcml0aG0gY2xhaW0gaXMg
dXNlZCkgdGhlIFVuaWNvZGUgc3RyaW5nIGVuY29kaW5nDQogICAgICAnYWxnb3JpdGhtJyB3aWxs
IGJlIGNoZWNrZWQgYWdhaW5zdCB0aGUgbWVtYmVyIG5hbWVzIGluIHRoZSBEZWNvZGVkIEpTT04N
CiAgICAgIENsYWltIFNlZ21lbnQgdG8gc2VlIGlmIHRoZXJlIGlzIGEgbWF0Y2hpbmcgY2xhaW0g
bmFtZS4gQSBzaW1pbGFyDQogICAgICBwcm9jZXNzIG9jY3VycyB3aGVuIGRldGVybWluaW5nIGlm
IHRoZSB2YWx1ZSBvZiB0aGUgYWxnb3JpdGhtIGNsYWltDQogICAgICByZXByZXNlbnRzIGEgc3Vw
cG9ydGVkIGFsZ29yaXRobS4gQ29tcGFyaW5nIFVuaWNvZGUgc3RyaW5ncyBob3dldmVyIGhhcw0K
ICAgICAgc2lnbmZpZ2FudCBzZWN1cml0eSBpbXBsaWNhdGlvbnMgd2hpY2ggYXJlIGZ1cnRoZXIg
ZXhwbG9yZWQgaW4gdGhlDQogICAgICBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0K
PC9wPg0KPHA+Q29tcGFyaXNvbnMgYmV0d2VlbiBKU09OIHN0cmluZ3MgYW5kIG90aGVyIFVuaWNv
ZGUgc3RyaW5ncyBNVVNUIGJlDQogICAgICBwZXJmb3JtZWQgYXMgc3BlY2lmaWVkIGJlbG93Og0K
PC9wPg0KPHA+PC9wPg0KPG9sIGNsYXNzPSJ0ZXh0Ij4NCjxsaT5SZW1vdmUgYW55IEpTT04gYXBw
bGllZCBlc2NhcGluZyB0byBwcm9kdWNlIGFuIGFycmF5IG9mIFVuaWNvZGUNCiAgICAgICAgICBj
b2RlIHBvaW50cw0KPC9saT4NCjxsaT48YSBjbGFzcz0naW5mbycgaHJlZj0nI1VTQTE1Jz5Vbmlj
b2RlIE5vcm1hbGl6YXRpb248c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+RGF2aXMs
IE0uLCBXaGlzdGxlciwgSy4sIGFuZCBNLiBEJlV1bWw7cnN0LCAmbGRxdW87VW5pY29kZSBOb3Jt
YWxpemF0aW9uIEZvcm1zLCZyZHF1bzsgMDkmbmJzcDsyMDA5Ljwvc3Bhbj48c3Bhbj4pPC9zcGFu
PjwvYT4gW1VTQTE1XSBNVVNUIE5PVCBiZQ0KICAgICAgICAgIGFwcGxpZWQgYXQgYW55IHBvaW50
IHRvIGVpdGhlciB0aGUgSlNPTiBzdHJpbmcgb3IgdG8gdGhlIHN0cmluZyBpdA0KICAgICAgICAg
IGlzIHRvIGJlIGNvbXBhcmVkIGFnYWluc3QuDQo8L2xpPg0KPGxpPkNvbXBhcmlzb25zIGJldHdl
ZW4gdGhlIHR3byBzdHJpbmdzIE1VU1QgYmUgcGVyZm9ybWVkIGFzIGENCiAgICAgICAgICBVbmlj
b2RlIGNvZGUgcG9pbnQgdG8gY29kZSBwb2ludCBjb21wYXJpc29uLg0KPC9saT4NCjwvb2w+DQoN
CjxwPg0KPC9wPg0KPGEgbmFtZT0iYW5jaG9yMTMiPjwvYT48YnIgLz48aHIgLz4NCjx0YWJsZSBz
dW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRP
Q2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2Mi
PiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4NCjxhIG5hbWU9InJmYy5zZWN0
aW9uLjciPjwvYT48aDM+Ny4mbmJzcDsNClByb3RlY3RpbmcgYSBKU09OIFRva2VuIHdpdGggSE1B
QyBTSEEtMjU2PC9oMz4NCg0KPHA+SGFzaCBiYXNlZCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENv
ZGVzIChITUFDcykgZW5hYmxlIG9uZSB0byB1c2UgYQ0KICAgICAgc2VjcmV0IHBsdXMgYSBjcnlw
dG9ncmFwaGljIGhhc2ggZnVuY3Rpb24gdG8gZ2VuZXJhdGUgYSBNZXNzYWdlDQogICAgICBBdXRo
ZW50aWNhdGlvbiBDb2RlIChNQUMpIHRoYXQgY2FuIGJlIHVzZWQgdG8gZGVtb25zdHJhdGUgbm90
IG9ubHkgdGhhdA0KICAgICAgdGhlIE1BQyBtYXRjaGVzIHRoZSBoYXNoZWQgY29udGVudCwgaW4g
dGhpcyBjYXNlIHRoZSBKU09OIENsYWltIFNlZ21lbnQsDQogICAgICBidXQgY2FuIG9ubHkgZGVt
b25zdHJhdGUgdGhhdCB3aG9tIGV2ZXIgZ2VuZXJhdGVkIHRoZSBNQUMgd2FzIGluDQogICAgICBw
b3NzZXNzaW9uIG9mIHRoZSBzZWNyZXQuIFVubGlrZSBkaWdpdGFsIHNpZ25hdHVyZXMsIEhNQUNz
IGNhbiBvbmx5DQogICAgICBwcm92aWRlIHZhbGlkYXRpb24gYnV0IG5vdCByZXB1ZGlhdGlvbiBz
aW5jZSBib3RoIHRoZSBzZW5kZXIgYW5kDQogICAgICByZWNlaXZlciBvZiB0aGUgSE1BQyBtdXN0
IGJlIGluIHBvc3Nlc3Npb24gb2YgdGhlIHNlY3JldCBhbmQgc28gZWl0aGVyDQogICAgICBjb3Vs
ZCBoYXZlIGdlbmVyYXRlZCB0aGUgSE1BQy4NCjwvcD4NCjxwPlRoZSBhbGdvcml0aG0gZm9yIGlt
cGxlbWVudGluZyBhbmQgdmFsaWRhdGluZyBITUFDcyBpcyBwcm92aWRlZCBpbg0KICAgICAgPGEg
Y2xhc3M9J2luZm8nIGhyZWY9JyNSRkMyMTA0Jz5SRkMgMjEwNDxzcGFuPiAoPC9zcGFuPjxzcGFu
IGNsYXNzPSdpbmZvJz5LcmF3Y3p5aywgSC4sIEJlbGxhcmUsIE0uLCBhbmQgUi4gQ2FuZXR0aSwg
JmxkcXVvO0hNQUM6IEtleWVkLUhhc2hpbmcgZm9yIE1lc3NhZ2UgQXV0aGVudGljYXRpb24sJnJk
cXVvOyBGZWJydWFyeSZuYnNwOzE5OTcuPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbUkZDMjEw
NF0uIEFsdGhvdWdoIGFueSBITUFDIGNhbiBiZSB1c2VkDQogICAgICB3aXRoIEpTT04gVG9rZW5z
IHRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSB1c2Ugb2YgdGhlIFNIQS0yNTYNCiAgICAgIGNyeXB0
b2dyYXBoaWMgaGFzaCBmdW5jdGlvbiBhcyBkZWZpbmVkIGluIDxhIGNsYXNzPSdpbmZvJyBocmVm
PScjRklQUy4xODAtMyc+RklQUw0KICAgICAgMTgwLTM8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFz
cz0naW5mbyc+TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQgICAgICAgICAgICAg
VGVjaG5vbG9neSwgJmxkcXVvO1NlY3VyZSBIYXNoIFN0YW5kYXJkIChTSFMpLCZyZHF1bzsgT2N0
b2JlciZuYnNwOzIwMDguPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPiBbRklQUy4xODAmIzgyMDk7
M10uIFRoZSByZXNlcnZlZCBhbGdvcml0aG0gY2xhaW0gdmFsdWUgSG1hY1NoYTI1NiBpcyB1c2Vk
IGluDQogICAgICB0aGUgSlNPTiBDbGFpbSBTZWdtZW50IHRvIGluZGljYXRlIHRoYXQgdGhlIEpT
T04gQ3J5cHRvIFNlZ21lbnQgY29udGFpbnMNCiAgICAgIGEgSE1BQyBTSEEtMjU2IEhNQUMuDQo8
L3A+DQo8cD5UaGUgSE1BQyBTSEEtMjU2IE1BQyBpcyBnZW5lcmF0ZWQgYXMgZm9sbG93czogPC9w
Pg0KPG9sIGNsYXNzPSJ0ZXh0Ij4NCjxsaT5UYWtlIHRoZSBKU09OIENsYWltIFNlZ21lbnQgYW5k
IGV4ZWN1dGUgdGhlIEhNQUMgU0hBLTI1Ng0KICAgICAgICAgIGFsZ29yaXRobSBvbiBpdCB1c2lu
ZyB0aGUgZGVzaXJlZCBrZXkgdG8gcHJvZHVjZSBhIEhNQUMuDQo8L2xpPg0KPGxpPmJhc2U2NHVy
bCBlbmNvZGUgdGhlIEhNQUMgYXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KPC9saT4NCjwv
b2w+PHA+IFRoZSBvdXRwdXQgb2YgdGhlIHByZXZpb3VzIHRoZW4gYmVjb21lcyB0aGUgSlNPTiBD
cnlwdG8NCiAgICAgIFNlZ21lbnQgZm9yIHRoYXQgSlNPTiBUb2tlbi4NCjwvcD4NCjxwPlRoZSBI
TUFDIFNIQS0yNTYgTUFDIG9uIGEgSlNPTiB0b2tlbiBpcyB2YWxpZGF0ZWQgZm9yIGEgcGFydGlj
dWxhcg0KICAgICAga2V5IGFzIGRlZmluZWQgYmVsb3cuIDwvcD4NCjxvbCBjbGFzcz0idGV4dCI+
DQo8bGk+VGFrZSB0aGUgSlNPTiBDbGFpbSBTZWdtZW50IGFuZCBjYWxjdWxhdGUgYSBITUFDIFNI
QS0yNTYgTUFDIG9uDQogICAgICAgICAgaXQgdXNpbmcgdGhlIGtleSB0byBiZSB0ZXN0ZWQuDQo8
L2xpPg0KPGxpPmJhc2U2NHVybCBlbmNvZGUgdGhlIHByZXZpb3VzbHkgZ2VuZXJhdGVkIEhNQUMg
YXMgZGVmaW5lZCBpbiB0aGlzDQogICAgICAgICAgZG9jdW1lbnQuDQo8L2xpPg0KPGxpPklmIHRo
ZSBKU09OIENyeXB0byBTZWdtZW50IGFuZCB0aGUgcHJldmlvdXNseSBjYWxjdWxhdGVkIHZhbHVl
DQogICAgICAgICAgZXhhY3RseSBtYXRjaCBpbiBhIGNoYXJhY3RlciBieSBjaGFyYWN0ZXIsIGNh
c2Ugc2Vuc2l0aXZlDQogICAgICAgICAgY29tcGFyaXNvbiwgdGhlbiBvbmUgaGFzIGNvbmZpcm1h
dGlvbiB0aGF0IHRoZSBrZXkgYmVpbmcgdGVzdGVkIHdhcw0KICAgICAgICAgIHVzZWQgdG8gZ2Vu
ZXJhdGUgdGhlIEhNQUMgb24gdGhlIEpTT04gVG9rZW4gYW5kIHRoYXQgdGhlIGNvbnRlbnRzIG9m
DQogICAgICAgICAgdGhlIEpTT04gQ2xhaW0gU2VnbWVudCBoYXZlIG5vdCBiZSB0YW1wZXJlZCB3
aXRoLg0KPC9saT4NCjwvb2w+DQoNCjxhIG5hbWU9ImFuY2hvcjE0Ij48L2E+PGJyIC8+PGhyIC8+
DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIi
IGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBo
cmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1l
PSJyZmMuc2VjdGlvbi44Ij48L2E+PGgzPjguJm5ic3A7DQpQcm90ZWN0aW5nIGEgSlNPTiBUb2tl
biB3aXRoIFJTQSBkaWdpdGFsIHNpZ25hdHVyZXM8L2gzPg0KDQo8cD5UQkQuIEkgaGF2ZSBzb21l
IGhvbWV3b3JrIHRvIGRvIGJlZm9yZSBJIHdpbGwgZmVlbCBjb21mb3J0YWJsZSB0aGF0IEkNCiAg
ICAgIGNhbiBwcm9wZXJseSBzcGVjaWZ5IHRoaXMgYmVoYXZpb3IuDQo8L3A+DQo8YSBuYW1lPSJE
ZWZpbmluZ0VDRFNBIj48L2E+PGJyIC8+PGhyIC8+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBj
ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdo
dCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8
L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMuc2VjdGlvbi45Ij48L2E+PGgzPjku
Jm5ic3A7DQpQcm90ZWN0aW5nIGEgSlNPTiBUb2tlbiB3aXRoIEVDRFNBPC9oMz4NCg0KPHA+VGhl
IEVsbGlwdGljIEN1cnZlIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobSAoRUNEU0EpIGlzIGRl
ZmluZWQgYnkNCiAgICAgIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjRklQUy4xODYtMyc+RklQUyAx
ODYtMzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNsYXNzPSdpbmZvJz5OYXRpb25hbCBJbnN0aXR1dGUg
b2YgU3RhbmRhcmRzIGFuZCAgICAgICAgICAgICBUZWNobm9sb2d5LCAmbGRxdW87RGlnaXRhbCBT
aWduYXR1cmUgU3RhbmRhcmQgKERTUyksJnJkcXVvOyBKdW5lJm5ic3A7MjAwOS48L3NwYW4+PHNw
YW4+KTwvc3Bhbj48L2E+IFtGSVBTLjE4NiYjODIwOTszXS4gRUNEU0EgcHJvdmlkZXMgZm9yIHRo
ZSB1c2UNCiAgICAgIG9mIEVsbGlwdGljIEN1cnZlIGNyeXB0b2dyYXBoeSB3aGljaCBpcyBhYmxl
IHRvIHByb3ZpZGUgZXF1aXZhbGVudA0KICAgICAgc2VjdXJpdHkgdG8gUlNBIGNyeXB0b2dyYXBo
eSBidXQgdXNpbmcgc2hvcnRlciBrZXkgbGVuZ3RocyBhbmQgd2l0aA0KICAgICAgZ3JlYXRlciBw
cm9jZXNzaW5nIHNwZWVkLiBUaGlzIG1lYW5zIHRoYXQgRUNEU0Egc2lnbmF0dXJlcyB3aWxsIGJl
DQogICAgICBzdWJzdGFudGlhbGx5IHNtYWxsZXIgaW4gdGVybXMgb2YgbGVuZ3RoIHRoYW4gZXF1
aXZhbGVudGx5IHN0cm9uZyBSU0ENCiAgICAgIERpZ2l0YWwgU2lnbmF0dXJlcy4NCjwvcD4NCjxw
PlRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIHRoZSB1c2Ugb2YgRUNEU0Egd2l0aCB0aGUgUC0y
NTYgY3VydmUgYW5kDQogICAgICB0aGUgU0hBLTI1NiBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rp
b24uIFRoZSBQLTI1NiBjdXJ2ZSBpcyBhbHNvIGRlZmluZWQNCiAgICAgIGluIEZJUFMgMTg2LTMu
IFRoZSBhbGdvcml0aG0gY2xhaW0gdmFsdWUgRWNkc2FQMjU2U2hhMjU2IGlzIHJldmVyc2VkIHRv
DQogICAgICBpZGVudGlmeSBhIEpTT04gVG9rZW4gc2lnbmVkIHdpdGggRUNEU0EgUC0yNTYgU0hB
LTI1Ni4NCjwvcD4NCjxwPkEgSlNPTiBUb2tlbiBpcyBzaWduZWQgd2l0aCBhbiBFQ0RTQSBQLTI1
NiBTSEEtMjU2IHNpZ25hdHVyZSBhcw0KICAgICAgZm9sbG93czogPC9wPg0KPG9sIGNsYXNzPSJ0
ZXh0Ij4NCjxsaT5UYWtlIHRoZSBKU09OIENsYWltIFNlZ21lbnQgYW5kIGdlbmVyYXRlIGEgZGln
aXRhbCBzaWduYXR1cmUgZm9yDQogICAgICAgICAgaXQgdXNpbmcgRUNEU0EgUC0yNTYgU0hBLTI1
NiB3aXRoIHRoZSBkZXNpcmVkIHByaXZhdGUga2V5LiBUaGUNCiAgICAgICAgICBvdXRwdXQgd2ls
bCBiZSB0d28gdW5zaWduZWQgaW50ZWdlcnMgY2FsbGVkLCBieSBjb252ZW50aW9uIFIgYW5kDQog
ICAgICAgICAgUy4NCjwvbGk+DQo8bGk+VHVybiBSIGFuZCBTIGludG8gYnl0ZSBhcnJheXMgaW4g
YmlnIGVuZGlhbiBvcmRlci4gRWFjaCBhcnJheQ0KICAgICAgICAgIHdpbGwgYmUgMzIgYnl0ZXMg
bG9uZw0KPC9saT4NCjxsaT5Db25jYXRlbmF0ZSB0aGUgdHdvIGJ5dGUgYXJyYXlzIGluIHRoZSBv
cmRlciBSIGFuZCB0aGVuIFMuDQo8L2xpPg0KPGxpPmJhc2U2NHVybCB0aGUgNjQgYnl0ZSBhcnJh
eSBhcyBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4NCjwvbGk+DQo8L29sPjxwPiBUaGUg
b3V0cHV0IGlzIHRoZW4gdGhlIEpTT04gQ3J5cHRvIFNlZ21lbnQgZm9yIHRoZSBKU09ODQogICAg
ICBUb2tlbi4NCjwvcD4NCjxwPkEgSlNPTiBUb2tlbiBpcyB0ZXN0ZWQgdG8gc2VlIGlmIGl0IHdh
cyBzaWduZWQgd2l0aCBFQ0RTQSBQLTI1Ng0KICAgICAgU0hBLTI1NiB1c2luZyBhIGdpdmVuIHB1
YmxpYyBrZXkgYXMgZm9sbG93czogPC9wPg0KPG9sIGNsYXNzPSJ0ZXh0Ij4NCjxsaT5UYWtlIHRo
ZSBKU09OIENyeXB0byBTZWdtZW50IGFuZCBiYXNlNjR1cmwgZGVjb2RlIGl0LiBJZiBkZWNvZGlu
Zw0KICAgICAgICAgIGZhaWxzIHRoZW4gdGhlIHRlc3QgTVVTVCBmYWlsLg0KPC9saT4NCjxsaT5U
aGUgb3V0cHV0IG9mIHRoZSBiYXNlNjR1cmwgZGVjb2RpbmcgTVVTVCBiZSBhIDY0IGJ5dGUgYXJy
YXkuDQo8L2xpPg0KPGxpPlNwbGl0IHRoZSA2NCBieXRlIGFycmF5IGludG8gdHdvIDMyIGJ5dGUg
YXJyYXlzLiBUaGUgZmlyc3QgYXJyYXkNCiAgICAgICAgICB3aWxsIGJlIFIgYW5kIHRoZSBzZWNv
bmQgUy4gUGxlYXNlIHJlbWVtYmVyIHRoYXQgdGhlIGJ5dGUgYXJyYXlzIGFyZQ0KICAgICAgICAg
IGluIGJpZyBlbmRpYW4gYnl0ZSBvcmRlciwgcGxlYXNlIGNoZWNrIHdpdGggdGhlIEVDRFNBIHZh
bGlkYXRvciBpbg0KICAgICAgICAgIHVzZSB0byBzZWUgd2hhdCBieXRlIG9yZGVyIGl0IHJlcXVp
cmVkLg0KPC9saT4NCjxsaT5TdWJtaXQgdGhlIEpTT04gQ2xhaW0gU2VnbWVudCwgUiwgUyBhbmQg
dGhlIHB1YmxpYyBrZXkgdGhhdCBpcw0KICAgICAgICAgIGJlaW5nIHRlc3RlZCB0byB0aGUgRUNE
U0EgUC0yNTYgU0hBLTI1NiB2YWxpZGF0b3IuDQo8L2xpPg0KPC9vbD48cD4gVGhlIEVDRFNBIHZh
bGlkYXRvciB3aWxsIHRoZW4gc3BlY2lmeSBpZiB0aGUgZGlnaXRhbCBzaWduYXR1cmUNCiAgICAg
IGlzIHZhbGlkIGdpdmVuIHRoZSBpbnB1dHMuIFBsZWFzZSBub3RlIHRoYXQgRUNEU0EgZGlnaXRh
bCBzaWduYXR1cmUNCiAgICAgIGNvbnRhaW4gYSB2YWx1ZSByZWZlcnJlZCB0byBhcyBLIHdoaWNo
IGlzIGEgcmFuZG9tIG51bWJlciBnZW5lcmF0ZWQgZm9yDQogICAgICBlYWNoIGRpZ2l0YWwgc2ln
bmF0dXJlIGluc3RhbmNlLiBUaGlzIG1lYW5zIHRoYXQgdHdvIEVDRFNBIGRpZ2l0YWwNCiAgICAg
IHNpZ25hdHVyZXMgdXNpbmcgZXhhY3RseSB0aGUgc2FtZSBpbnB1dCBwYXJhbWV0ZXJzIHdpbGwg
c3RpbGwgb3V0cHV0DQogICAgICBkaWZmZXJlbnQgc2lnbmF0dXJlcyBiZWNhdXNlIHRoZWlyIEsg
dmFsdWVzIHdpbGwgYmUgZGlmZmVyZW50LiBUaGUNCiAgICAgIGNvbnNlcXVlbmNlIG9mIEsgaXMg
dGhhdCBvbmUgdmFsaWRhdGVzIGEgRUNEU0Egc2lnbmF0dXJlIGJ5IHN1Ym1pdHRpbmcNCiAgICAg
IHRoZSBwcmV2aW91c2x5IHNwZWNpZmllZCBpbnB1dHMgdG8gYSBFQ0RTQSB2YWxpZGF0b3IuIE9u
ZSBjYW5ub3QsIGFzDQogICAgICB3aXRoIEhNQUNzLCBjaGVjayB0aGUgc2lnbmF0dXJlIGRpcmVj
dGx5IG9uZXNlbGYuDQo8L3A+DQo8YSBuYW1lPSJJQU5BIj48L2E+PGJyIC8+PGhyIC8+DQo8dGFi
bGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNz
PSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIj
dG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMu
c2VjdGlvbi4xMCI+PC9hPjxoMz4xMC4mbmJzcDsNCklBTkEgQ29uc2lkZXJhdGlvbnM8L2gzPg0K
DQo8cD5UaGlzIHNwZWNpZmljYXRpb24gY2FsbHMgZm9yOiA8L3A+DQo8dWwgY2xhc3M9InRleHQi
Pg0KPGxpPkEgbmV3IElBTkEgcmVnaXN0cnkgZW50aXRsZWQgIkpTT04gVG9rZW4gQ2xhaW1zIiBm
b3IgY2xhaW0gbmFtZXMNCiAgICAgICAgICB1c2VkIGluIGEgZGVjb2RlZCBKU09OIENsYWltIFNl
Z21lbnQuIEluY2x1c2lvbiBpbiB0aGUgcmVnaXN0cnkgaXMNCiAgICAgICAgICBSRkMgUmVxdWly
ZWQgaW4gdGhlIDxhIGNsYXNzPSdpbmZvJyBocmVmPScjUkZDNTIyNic+UkZDIDUyMjY8c3Bhbj4g
KDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+TmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwg
JmxkcXVvO0d1aWRlbGluZXMgZm9yIFdyaXRpbmcgYW4gSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0
aW9uIGluIFJGQ3MsJnJkcXVvOyBNYXkmbmJzcDsyMDA4Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwv
YT4gW1JGQzUyMjZdIHNlbnNlLg0KICAgICAgICAgIFRoZSByZWdpc3RyeSB3aWxsIGp1c3QgcmVj
b3JkIHRoZSBjbGFpbSBuYW1lIGFuZCBhIHBvaW50ZXIgdG8gdGhlDQogICAgICAgICAgUkZDIHRo
YXQgZGVmaW5lcyBpdC4gVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgaW5jbHVzaW9uIG9mIHRo
ZQ0KICAgICAgICAgIGNsYWltIG5hbWVzIGRlZmluZWQgaW4gPGEgY2xhc3M9J2luZm8nIGhyZWY9
JyNDbGFpbVRhYmxlJz5UYWJsZSZuYnNwOzE8c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5m
byc+QSBsaXN0IG9mIGNsYWltIGRlZmluaXRpb25zPC9zcGFuPjxzcGFuPik8L3NwYW4+PC9hPi4N
CjwvbGk+DQo8bGk+QSBuZXcgSUFOQSByZWdpc3RyeSBlbnRpdGxlZCAiSlNPTiBUb2tlbiBBbGdv
cml0aG0gVmFsdWVzIiBmb3INCiAgICAgICAgICB2YWx1ZXMgdXNlZCB3aXRoIHRoZSBhbGdvcml0
aG0gY2xhaW0gdXNlZCBpbiBhIGRlY29kZWQgSlNPTiBDbGFpbQ0KICAgICAgICAgIFNlZ21lbnQu
IEluY2x1c2lvbiBpbiB0aGUgcmVnaXN0cnkgaXMgUkZDIFJlcXVpcmVkIGluIHRoZSA8YSBjbGFz
cz0naW5mbycgaHJlZj0nI1JGQzUyMjYnPlJGQyA1MjI2PHNwYW4+ICg8L3NwYW4+PHNwYW4gY2xh
c3M9J2luZm8nPk5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJhbmQsICZsZHF1bztHdWlkZWxpbmVz
IGZvciBXcml0aW5nIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzLCZyZHF1
bzsgTWF5Jm5ic3A7MjAwOC48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+IFtSRkM1MjI2XSBzZW5z
ZS4gVGhlIHJlZ2lzdHJ5IHdpbGwganVzdA0KICAgICAgICAgIHJlY29yZCB0aGUgYWxnb3JpdGht
IHZhbHVlIGFuZCBhIHBvaW50ZXIgdG8gdGhlIFJGQyB0aGF0IGRlZmluZXMgaXQuDQogICAgICAg
ICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgaW5jbHVzaW9uIG9mIHRoZSBhbGdvcml0aG0g
dmFsdWVzDQogICAgICAgICAgSG1heFNoYTI1NiBhbmQgRWNkc2FQMjU2U2hhMjU2Lg0KPC9saT4N
CjwvdWw+DQoNCjxwPkVESVRPUidTIE5PVEU6IE5lZWQgdG8gaW5jbHVkZSBhbiBpZGVudGlmaWVy
IGZvciBSU0EuIEFsc28gSQ0KICAgICAgZXhwbGljaXRseSBkaWRuJ3QgYWxsb3cgZm9yIGFkLWhv
YyByZWdpc3RyYXRpb25zIGJlY2F1c2UgSSBmaWd1cmUgdGhhdA0KICAgICAgSUFOQSBoYXMgZW5v
dWdoIHRvIGRvIGJ1dCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBhIGNlbnRyYWwgcmVnaXN0
cnkNCiAgICAgIG9mIHZhbHVlcywgZXZlbiBhZC1ob2Mgb25lcy4gV2Ugc2hvdWxkIGNoZWNrIHdp
dGggSUFOQSB0byBzZWUgd2hhdCB0aGV5DQogICAgICB0aGluay4NCjwvcD4NCjxhIG5hbWU9IlNl
Y3VyaXR5Ij48L2E+PGJyIC8+PGhyIC8+DQo8dGFibGUgc3VtbWFyeT0ibGF5b3V0IiBjZWxscGFk
ZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0NidWciIGFsaWduPSJyaWdodCI+PHRy
Pjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4mbmJzcDtUT0MmbmJzcDs8L2E+PC90
ZD48L3RyPjwvdGFibGU+DQo8YSBuYW1lPSJyZmMuc2VjdGlvbi4xMSI+PC9hPjxoMz4xMS4mbmJz
cDsNClNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC9oMz4NCg0KPHA+RURJVE9SJ1MgTk9URTogTG90
cyBvZiB3b3JrIHRvIGRvIGhlcmUuIEkgbmVlZCB0byByZW1lbWJlciB0byBsb29rDQogICAgICBp
bnRvIGFueSBpc3N1ZXMgcmVsYXRpbmcgdG8gc2VjdXJpdHkgYW5kIEpTT04gcGFyc2luZy4gT25l
IHdvbmRlcnMganVzdA0KICAgICAgaG93IHNlY3VyZSBtb3N0IEpTT04gcGFyc2luZyBsaWJyYXJp
ZXMgYXJlLiBXZXJlIHRoZXkgZXZlciBoYXJkZW5lZCBmb3INCiAgICAgIHNlY3VyaXR5IHNjZW5h
cmlvcz8gSWYgbm90LCB3aGF0IGtpbmQgb2YgaG9sZXMgZG9lcyB0aGF0IG9wZW4gdXA/IEFsc28N
CiAgICAgIG5lZWQgdG8gd2FsayB0aHJvdWdoIHRoZSBKU09OIHN0YW5kYXJkIGFuZCBzZWUgd2hh
dCBraW5kIG9mIGlzc3VlcyB3ZQ0KICAgICAgaGF2ZSBlc3BlY2lhbGx5IGFyb3VuZCBjb21wYXJp
c29uIG9mIG5hbWVzLCBhbHJlYWR5IGZvdW5kIGFuIGlzc3VlIHdpdGgNCiAgICAgIGVzY2FwaW5n
IHN0cmluZ3MgKG5lZWRlZCB0byBkZWZpbmUgdGhhdCBjb21wYXJpc29ucyBvZiBzdHJpbmdzIG11
c3QNCiAgICAgIG9jY3VyIGFmdGVyIHRoZXkgYXJlIHVuZXNjYXBlZCkuIE5lZWQgdG8gYWxzbyBw
dXQgaW4gdGV4dCBhYm91dDoNCiAgICAgIEltcG9ydGFuY2Ugb2Yga2VlcGluZyBzZWNyZXRzIHNl
Y3JldC4gUm90YXRpbmcga2V5cy4gU3RyZW5ndGhzIGFuZA0KICAgICAgd2Vha25lc3NlcyBvZiB0
aGUgZGlmZmVyZW50IGFsZ29yaXRobXMuIENhc2Ugc2Vuc2l0aXZpdHkgYW5kIG1vcmUNCiAgICAg
IGdlbmVyYWxseSBVbmljb2RlIGNvbXBhcmlzb24gaXNzdWVzIHRoYXQgY2FuIGNhdXNlIHNlY3Vy
aXR5IGhvbGVzLA0KICAgICAgZXNwZWNpYWxseSBpbiBjbGFpbSBuYW1lcyBhbmQgZXhwbGFpbiB3
aHkgVW5pY29kZSBOb3JtYWxpemF0aW9uIGlzIHN1Y2gNCiAgICAgIGEgcHJvYmxlbSBmb3IgYXNz
ZXJ0aW9ucy4NCjwvcD4NCjxwPk5lZWQgdG8gcHV0IGluIHRleHQgYWJvdXQgd2h5IHN0cmljdCBK
U09OIHZhbGlkYXRpb24gaXMgbmVjZXNzYXJ5Lg0KICAgICAgQmFzaWNhbGx5IHRoYXQgaWYgbWFs
Zm9ybWVkIEpTT04gaXMgcmVjZWl2ZWQgdGhlbiB0aGUgaW50ZW50IG9mIHRoZQ0KICAgICAgc2Vu
ZGVyIGlzIGltcG9zc2libGUgdG8gcmVsaWFibHkgZGlzY2VybmUuIFdoaWxlIGluIG5vbi1zZWN1
cml0eQ0KICAgICAgY29udGV4dHMgaXQncyBvLmsuIHRvIGJlIGdlbmVyb3VzIGluIHdoYXQgb25l
IGFjY2VwdHMgaW4gc2VjdXJpdHkNCiAgICAgIGNvbnRleHRzIHRoaXMgY2FuIGxlYWQgdG8gc2Vy
aW91cyBzZWN1cml0eSBob2xlcy4gRm9yIGV4YW1wbGUsIG1hbGZvcm1lZA0KICAgICAgSlNPTiBt
aWdodCBpbmRpY2F0ZSB0aGF0IHNvbWVvbmUgaGFzIG1hbmFnZWQgdG8gZmluZCBhIHNlY3VyaXR5
IGhvbGUgaW4NCiAgICAgIHRoZSBpc3N1ZXIncyBjb2RlIGFuZCBpcyBsZXZlcmFnaW5nIGl0IHRv
IGdldCB0aGUgaXNzdWVyIHRvIGlzc3VlICdiYWQnDQogICAgICB0b2tlbnMgd2hvc2UgY29udGVu
dCB0aGUgYXR0YWNrIGNhbiBjb250cm9sLg0KPC9wPg0KPGEgbmFtZT0iYW5jaG9yMTUiPjwvYT48
YnIgLz48aHIgLz4NCjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxs
c3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJU
T0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJs
ZT4NCjxhIG5hbWU9InJmYy5zZWN0aW9uLjExLjEiPjwvYT48aDM+MTEuMS4mbmJzcDsNClVuaWNv
ZGUgY29tcGFyaXNvbiBzZWN1cml0eSBpc3N1ZXM8L2gzPg0KDQo8cD4NCjwvcD4NCjxhIG5hbWU9
IkFja25vd2xlZGdlbWVudHMiPjwvYT48YnIgLz48aHIgLz4NCjx0YWJsZSBzdW1tYXJ5PSJsYXlv
dXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249
InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZu
YnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4NCjxhIG5hbWU9InJmYy5zZWN0aW9uLjEyIj48L2E+
PGgzPjEyLiZuYnNwOw0KQWNrbm93bGVkZ2VtZW50czwvaDM+DQoNCjxwPg0KPC9wPg0KPGEgbmFt
ZT0iYW5jaG9yMTYiPjwvYT48YnIgLz48aHIgLz4NCjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNl
bGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0
Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwv
YT48L3RkPjwvdHI+PC90YWJsZT4NCjxhIG5hbWU9InJmYy5zZWN0aW9uLjEzIj48L2E+PGgzPjEz
LiZuYnNwOw0KQXBwZW5kaXggLSBOb24tTm9ybWF0aXZlIC0gUmVsYXRpb25zaGlwIG9mIEpTT04g
VG9rZW5zIHRvIFNBTUwgQXNzZXJ0aW9uczwvaDM+DQoNCjxwPjxhIGNsYXNzPSdpbmZvJyBocmVm
PScjT0FTSVMuc2FtbC1jb3JlLTIuMC1vcyc+U0FNTCAyLjA8c3Bhbj4gKDwvc3Bhbj48c3BhbiBj
bGFzcz0naW5mbyc+Q2FudG9yLCBTLiwgS2VtcCwgSi4sIFBoaWxwb3R0LCBSLiwgYW5kIEUuIE1h
bGVyLCAmbGRxdW87QXNzZXJ0aW9ucyBhbmQgUHJvdG9jb2wgZm9yIHRoZSBPQVNJUyBTZWN1cml0
eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdlICAgICAgICAgICAgIChTQU1MKSBWMi4wLCZyZHF1
bzsgTWFyY2gmbmJzcDsyMDA1Ljwvc3Bhbj48c3Bhbj4pPC9zcGFuPjwvYT4gW09BU0lTLnNhbWwm
IzgyMDk7Y29yZSYjODIwOTsyLjAmIzgyMDk7b3NdIHByb3ZpZGVzIGENCiAgICAgIHN0YW5kYXJk
IGZvciBjcmVhdGluZyBhc3NlcnRpb25zIHdpdGggbXVjaCBncmVhdGVyIGV4cHJlc3Npdml0eSBh
bmQNCiAgICAgIHNlY3VyaXR5IG9wdGlvbnMgdGhhbiBzdXBwb3J0ZWQgYnkgSlNPTiBUb2tlbnMu
IEhvd2V2ZXIgdGhlIGNvc3Qgb2YgdGhpcw0KICAgICAgZmxleGliaWxpdHkgYW5kIGV4cHJlc3Np
dmVuZXNzIGlzIHNpemUuIEluIGFkZGl0aW9uIFNBTUwncyB1c2Ugb2YgPGEgY2xhc3M9J2luZm8n
IGhyZWY9JyNXM0MuQ1IteG1sMTEtMjAwMjEwMTUnPlhNTDxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs
YXNzPSdpbmZvJz5Db3dhbiwgSi4sICZsZHF1bztFeHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSAo
WE1MKSAxLjEsJnJkcXVvOyBPY3RvYmVyJm5ic3A7MjAwMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48
L2E+IFtXM0MuQ1ImIzgyMDk7eG1sMTEmIzgyMDk7MjAwMjEwMTVdIGFuZCA8YSBjbGFzcz0naW5m
bycgaHJlZj0nI1JGQzMyNzUnPlhNTA0KICAgICAgRFNJRzxzcGFuPiAoPC9zcGFuPjxzcGFuIGNs
YXNzPSdpbmZvJz5FYXN0bGFrZSwgRC4sIFJlYWdsZSwgSi4sIGFuZCBELiBTb2xvLCAmbGRxdW87
KEV4dGVuc2libGUgTWFya3VwIExhbmd1YWdlKSBYTUwtU2lnbmF0dXJlIFN5bnRheCBhbmQgUHJv
Y2Vzc2luZywmcmRxdW87IE1hcmNoJm5ic3A7MjAwMi48L3NwYW4+PHNwYW4+KTwvc3Bhbj48L2E+
IFtSRkMzMjc1XSBvbmx5IGNvbnRyaWJ1dGVzIHRvIHRoZSBzaXplIG9mIFNBTUwgYXNzZXJ0aW9u
cy4NCjwvcD4NCjxwPkpTT04gVG9rZW5zIGFyZSBpbnRlbmRlZCB0byBwcm92aWRlIGEgc2ltcGxp
ZmllZCBhc3NlcnRpb24gZm9ybWF0DQogICAgICB0aGF0IGlzIHNtYWxsIGVub3VnaCB0byBmaXQg
aW50byBIVFRQIGhlYWRlcnMgYW5kIHF1ZXJ5IGFyZ3VtZW50cyBpbg0KICAgICAgVVJJcy4gSXQg
ZG9lcyB0aGlzIGJ5IHN1cHBvcnRpbmcgYSBtdWNoIHNpbXBsZXIgYXNzZXJ0aW9uIG1vZGVsIHRo
YW4NCiAgICAgIFNBTUwgYW5kIHVzaW5nIHRoZSA8YSBjbGFzcz0naW5mbycgaHJlZj0nI1JGQzQ2
MjcnPkpTT048c3Bhbj4gKDwvc3Bhbj48c3BhbiBjbGFzcz0naW5mbyc+Q3JvY2tmb3JkLCBELiwg
JmxkcXVvO1RoZSBhcHBsaWNhdGlvbi9qc29uIE1lZGlhIFR5cGUgZm9yIEphdmFTY3JpcHQgT2Jq
ZWN0IE5vdGF0aW9uIChKU09OKSwmcmRxdW87IEp1bHkmbmJzcDsyMDA2Ljwvc3Bhbj48c3Bhbj4p
PC9zcGFuPjwvYT4gW1JGQzQ2MjddIG9iamVjdCBlbmNvZGluZw0KICAgICAgc3ludGF4LiBJdCBh
bHNvIHN1cHBvcnRzIHNlY3VyaW5nIGFzc2VydGlvbnMgdXNpbmcgSGFzaC1iYXNlZCBNZXNzYWdl
DQogICAgICBBdXRoZW50aWNhdGlvbiBDb2RlcyAoSE1BQ3MpIGFuZCBkaWdpdGFsIHNpZ25hdHVy
ZXMgdXNpbmcgYSBzbWFsbGVyIChhbmQNCiAgICAgIGxlc3MgZmxleGlibGUpIGZvcm1hdCB0aGFu
IFhNTCBEU0lHLg0KPC9wPg0KPHA+VGhlcmVmb3JlIHdoaWxlIEpTT04gVG9rZW5zIGNhbiBkbyBz
b21lIG9mIHRoZSB0aGluZ3MgU0FNTCBhc3NlcnRpb25zDQogICAgICBkbywgSlNPTiBUb2tlbnMg
YXJlIG5vdCBpbnRlbmRlZCBhcyBhIGZ1bGwgcmVwbGFjZW1lbnQgZm9yIFNBTUwuIEJ1dA0KICAg
ICAgcmF0aGVyIGEgY29tcHJvbWlzZSBhc3NlcnRpb24gZm9ybWF0IHRvIGJlIHVzZWQgd2hlbiBz
cGFjZSBpcyBhdCBhDQogICAgICBwcmVtaXVtLg0KPC9wPg0KPGEgbmFtZT0icmZjLnJlZmVyZW5j
ZXMiPjwvYT48YnIgLz48aHIgLz4NCjx0YWJsZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5n
PSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRk
IGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwv
dHI+PC90YWJsZT4NCjxhIG5hbWU9InJmYy5zZWN0aW9uLjE0Ij48L2E+PGgzPjE0LiZuYnNwOw0K
UmVmZXJlbmNlczwvaDM+DQoNCjxhIG5hbWU9InJmYy5yZWZlcmVuY2VzMSI+PC9hPjxiciAvPjxo
ciAvPg0KPHRhYmxlIHN1bW1hcnk9ImxheW91dCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5n
PSIyIiBjbGFzcz0iVE9DYnVnIiBhbGlnbj0icmlnaHQiPjx0cj48dGQgY2xhc3M9IlRPQ2J1ZyI+
PGEgaHJlZj0iI3RvYyI+Jm5ic3A7VE9DJm5ic3A7PC9hPjwvdGQ+PC90cj48L3RhYmxlPg0KPGgz
PjE0LjEuJm5ic3A7Tm9ybWF0aXZlIFJlZmVyZW5jZXM8L2gzPg0KPHRhYmxlIHdpZHRoPSI5OSUi
IGJvcmRlcj0iMCI+DQo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxh
IG5hbWU9IkZJUFMuMTgwLTMiPltGSVBTLjE4MC0zXTwvYT48L3RkPg0KPHRkIGNsYXNzPSJhdXRo
b3ItdGV4dCI+TmF0aW9uYWwgSW5zdGl0dXRlIG9mIFN0YW5kYXJkcyBhbmQNCiAgICAgICAgICAg
IFRlY2hub2xvZ3ksICZsZHF1bztTZWN1cmUgSGFzaCBTdGFuZGFyZCAoU0hTKSwmcmRxdW87IEZJ
UFMmbmJzcDtQVUIgMTgwLTMsIE9jdG9iZXImbmJzcDsyMDA4LjwvdGQ+PC90cj4NCjx0cj48dGQg
Y2xhc3M9ImF1dGhvci10ZXh0IiB2YWxpZ249InRvcCI+PGEgbmFtZT0iRklQUy4xODYtMyI+W0ZJ
UFMuMTg2LTNdPC9hPjwvdGQ+DQo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij5OYXRpb25hbCBJbnN0
aXR1dGUgb2YgU3RhbmRhcmRzIGFuZA0KICAgICAgICAgICAgVGVjaG5vbG9neSwgJmxkcXVvO0Rp
Z2l0YWwgU2lnbmF0dXJlIFN0YW5kYXJkIChEU1MpLCZyZHF1bzsgRklQUyZuYnNwO1BVQiAxODYt
MywgSnVuZSZuYnNwOzIwMDkuPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQi
IHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkMyMTA0Ij5bUkZDMjEwNF08L2E+PC90ZD4NCjx0ZCBj
bGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpodWdvQHdhdHNvbi5pYm0uY29tIj5L
cmF3Y3p5aywgSC48L2E+LCA8YSBocmVmPSJtYWlsdG86bWloaXJAY3MudWNzZC5lZHUiPkJlbGxh
cmUsIE0uPC9hPiwgYW5kIDxhIGhyZWY9Im1haWx0bzpjYW5ldHRpQHdhdHNvbi5pYm0uY29tIj5S
LiBDYW5ldHRpPC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s
L3JmYzIxMDQiPkhNQUM6IEtleWVkLUhhc2hpbmcgZm9yIE1lc3NhZ2UgQXV0aGVudGljYXRpb248
L2E+LCZyZHF1bzsgUkZDJm5ic3A7MjEwNCwgRmVicnVhcnkmbmJzcDsxOTk3ICg8YSBocmVmPSJo
dHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMTA0LnR4dCI+VFhUPC9hPikuPC90ZD48
L3RyPg0KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJS
RkMyMTE5Ij5bUkZDMjExOV08L2E+PC90ZD4NCjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPjxhIGhy
ZWY9Im1haWx0bzpzb2JAaGFydmFyZC5lZHUiPkJyYWRuZXIsIFMuPC9hPiwgJmxkcXVvOzxhIGhy
ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIxMTkiPktleSB3b3JkcyBmb3IgdXNl
IGluIFJGQ3MgdG8gSW5kaWNhdGUgUmVxdWlyZW1lbnQgTGV2ZWxzPC9hPiwmcmRxdW87IEJDUCZu
YnNwOzE0LCBSRkMmbmJzcDsyMTE5LCBNYXJjaCZuYnNwOzE5OTcgKDxhIGhyZWY9Imh0dHA6Ly93
d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzIxMTkudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRw
Oi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMjExOS5odG1sIj5IVE1MPC9h
PiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMjEx
OS54bWwiPlhNTDwvYT4pLjwvdGQ+PC90cj4NCjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2
YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDMzMzOSI+W1JGQzMzMzldPC9hPjwvdGQ+DQo8dGQgY2xh
c3M9ImF1dGhvci10ZXh0Ij48YSBocmVmPSJtYWlsdG86R0tAQUNNLk9SRyI+S2x5bmUsIEcuLCBF
ZC48L2E+IGFuZCA8YSBocmVmPSJtYWlsdG86Y2hyaXMubmV3bWFuQHN1bi5jb20iPkMuIE5ld21h
bjwvYT4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMzM5
Ij5EYXRlIGFuZCBUaW1lIG9uIHRoZSBJbnRlcm5ldDogVGltZXN0YW1wczwvYT4sJnJkcXVvOyBS
RkMmbmJzcDszMzM5LCBKdWx5Jm5ic3A7MjAwMiAoPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRp
dG9yLm9yZy9yZmMvcmZjMzMzOS50eHQiPlRYVDwvYT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVz
b3VyY2Uub3JnL3B1YmxpYy9yZmMvaHRtbC9yZmMzMzM5Lmh0bWwiPkhUTUw8L2E+LCA8YSBocmVm
PSJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL3htbC9yZmMzMzM5LnhtbCI+WE1M
PC9hPikuPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9w
Ij48YSBuYW1lPSJSRkMzNjI5Ij5bUkZDMzYyOV08L2E+PC90ZD4NCjx0ZCBjbGFzcz0iYXV0aG9y
LXRleHQiPlllcmdlYXUsIEYuLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvcmZjMzYyOSI+VVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIElTTyAxMDY0
NjwvYT4sJnJkcXVvOyBTVEQmbmJzcDs2MywgUkZDJm5ic3A7MzYyOSwgTm92ZW1iZXImbmJzcDsy
MDAzICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzNjI5LnR4dCI+
VFhUPC9hPikuPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0i
dG9wIj48YSBuYW1lPSJSRkMzOTg2Ij5bUkZDMzk4Nl08L2E+PC90ZD4NCjx0ZCBjbGFzcz0iYXV0
aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzp0aW1ibEB3My5vcmciPkJlcm5lcnMtTGVlLCBULjwv
YT4sIDxhIGhyZWY9Im1haWx0bzpmaWVsZGluZ0BnYml2LmNvbSI+RmllbGRpbmcsIFIuPC9hPiwg
YW5kIDxhIGhyZWY9Im1haWx0bzpMTU1AYWNtLm9yZyI+TC4gTWFzaW50ZXI8L2E+LCAmbGRxdW87
PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzk4NiI+VW5pZm9ybSBSZXNv
dXJjZSBJZGVudGlmaWVyIChVUkkpOiBHZW5lcmljIFN5bnRheDwvYT4sJnJkcXVvOyBTVEQmbmJz
cDs2NiwgUkZDJm5ic3A7Mzk4NiwgSmFudWFyeSZuYnNwOzIwMDUgKDxhIGhyZWY9Imh0dHA6Ly93
d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzM5ODYudHh0Ij5UWFQ8L2E+LCA8YSBocmVmPSJodHRw
Oi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMzk4Ni5odG1sIj5IVE1MPC9h
PiwgPGEgaHJlZj0iaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy94bWwvcmZjMzk4
Ni54bWwiPlhNTDwvYT4pLjwvdGQ+PC90cj4NCjx0cj48dGQgY2xhc3M9ImF1dGhvci10ZXh0IiB2
YWxpZ249InRvcCI+PGEgbmFtZT0iUkZDNDYyNyI+W1JGQzQ2MjddPC9hPjwvdGQ+DQo8dGQgY2xh
c3M9ImF1dGhvci10ZXh0Ij5Dcm9ja2ZvcmQsIEQuLCAmbGRxdW87PGEgaHJlZj0iaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvcmZjNDYyNyI+VGhlIGFwcGxpY2F0aW9uL2pzb24gTWVkaWEgVHlw
ZSBmb3IgSmF2YVNjcmlwdCBPYmplY3QgTm90YXRpb24gKEpTT04pPC9hPiwmcmRxdW87IFJGQyZu
YnNwOzQ2MjcsIEp1bHkmbmJzcDsyMDA2ICg8YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iu
b3JnL3JmYy9yZmM0NjI3LnR4dCI+VFhUPC9hPikuPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0i
YXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJSRkM0NjQ4Ij5bUkZDNDY0OF08L2E+
PC90ZD4NCjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkpvc2Vmc3NvbiwgUy4sICZsZHF1bzs8YSBo
cmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjQ4Ij5UaGUgQmFzZTE2LCBCYXNl
MzIsIGFuZCBCYXNlNjQgRGF0YSBFbmNvZGluZ3M8L2E+LCZyZHF1bzsgUkZDJm5ic3A7NDY0OCwg
T2N0b2JlciZuYnNwOzIwMDYgKDxhIGhyZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZj
L3JmYzQ2NDgudHh0Ij5UWFQ8L2E+KS48L3RkPjwvdHI+DQo8dHI+PHRkIGNsYXNzPSJhdXRob3It
dGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzUyMjYiPltSRkM1MjI2XTwvYT48L3RkPg0K
PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+TmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgJmxk
cXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzUyMjYiPkd1aWRlbGlu
ZXMgZm9yIFdyaXRpbmcgYW4gSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGluIFJGQ3M8L2E+
LCZyZHF1bzsgQkNQJm5ic3A7MjYsIFJGQyZuYnNwOzUyMjYsIE1heSZuYnNwOzIwMDggKDxhIGhy
ZWY9Imh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzUyMjYudHh0Ij5UWFQ8L2E+KS48
L3RkPjwvdHI+DQo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5h
bWU9IlVTQTE1Ij5bVVNBMTVdPC9hPjwvdGQ+DQo8dGQgY2xhc3M9ImF1dGhvci10ZXh0Ij48YSBo
cmVmPSJtYWlsdG86bWFya2RhdmlzQGdvb2dsZS5jb20iPkRhdmlzLCBNLjwvYT4sIDxhIGhyZWY9
Im1haWx0bzprZW5AdW5pY29kZS5vcmciPldoaXN0bGVyLCBLLjwvYT4sIGFuZCBNLiBEJlV1bWw7
cnN0LCAmbGRxdW87VW5pY29kZSBOb3JtYWxpemF0aW9uIEZvcm1zLCZyZHF1bzsgVW5pY29kZSBT
dGFuZGFyZCBBbm5leCZuYnNwOzE1LCAwOSZuYnNwOzIwMDkuPC90ZD48L3RyPg0KPC90YWJsZT4N
Cg0KPGEgbmFtZT0icmZjLnJlZmVyZW5jZXMyIj48L2E+PGJyIC8+PGhyIC8+DQo8dGFibGUgc3Vt
bWFyeT0ibGF5b3V0IiBjZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjIiIGNsYXNzPSJUT0Ni
dWciIGFsaWduPSJyaWdodCI+PHRyPjx0ZCBjbGFzcz0iVE9DYnVnIj48YSBocmVmPSIjdG9jIj4m
bmJzcDtUT0MmbmJzcDs8L2E+PC90ZD48L3RyPjwvdGFibGU+DQo8aDM+MTQuMi4mbmJzcDtJbmZv
cm1hdGl2ZSBSZWZlcmVuY2VzPC9oMz4NCjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiPg0K
PHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48YSBuYW1lPSJPQVNJUy5z
YW1sLWNvcmUtMi4wLW9zIj5bT0FTSVMuc2FtbC1jb3JlLTIuMC1vc108L2E+PC90ZD4NCjx0ZCBj
bGFzcz0iYXV0aG9yLXRleHQiPjxhIGhyZWY9Im1haWx0bzpjYW50b3IuMkBvc3UuZWR1Ij5DYW50
b3IsIFMuPC9hPiwgPGEgaHJlZj0ibWFpbHRvOkpvaG4uS2VtcEBub2tpYS5jb20iPktlbXAsIEou
PC9hPiwgPGEgaHJlZj0ibWFpbHRvOnJwaGlscG90dEByc2FzZWN1cml0eS5jb20iPlBoaWxwb3R0
LCBSLjwvYT4sIGFuZCA8YSBocmVmPSJtYWlsdG86ZXZlLm1hbGVyQHN1bi5jb20iPkUuIE1hbGVy
PC9hPiwgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly9kb2NzLm9hc2lzLW9wZW4ub3JnL3NlY3VyaXR5
L3NhbWwvdjIuMC9zYW1sLWNvcmUtMi4wLW9zLnBkZiI+QXNzZXJ0aW9ucyBhbmQgUHJvdG9jb2wg
Zm9yIHRoZSBPQVNJUyBTZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdlDQogICAgICAg
ICAgICAoU0FNTCkgVjIuMDwvYT4sJnJkcXVvOyBPQVNJUyBTdGFuZGFyZCZuYnNwO3NhbWwtY29y
ZS0yLjAtb3MsIE1hcmNoJm5ic3A7MjAwNS48L3RkPjwvdHI+DQo8dHI+PHRkIGNsYXNzPSJhdXRo
b3ItdGV4dCIgdmFsaWduPSJ0b3AiPjxhIG5hbWU9IlJGQzMyNzUiPltSRkMzMjc1XTwvYT48L3Rk
Pg0KPHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+RWFzdGxha2UsIEQuLCBSZWFnbGUsIEouLCBhbmQg
RC4gU29sbywgJmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzMy
NzUiPihFeHRlbnNpYmxlIE1hcmt1cCBMYW5ndWFnZSkgWE1MLVNpZ25hdHVyZSBTeW50YXggYW5k
IFByb2Nlc3Npbmc8L2E+LCZyZHF1bzsgUkZDJm5ic3A7MzI3NSwgTWFyY2gmbmJzcDsyMDAyICg8
YSBocmVmPSJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzMjc1LnR4dCI+VFhUPC9h
PikuPC90ZD48L3RyPg0KPHRyPjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiIHZhbGlnbj0idG9wIj48
YSBuYW1lPSJSRkM0MTIyIj5bUkZDNDEyMl08L2E+PC90ZD4NCjx0ZCBjbGFzcz0iYXV0aG9yLXRl
eHQiPjxhIGhyZWY9Im1haWx0bzpwYXVsbGVAbWljcm9zb2Z0LmNvbSI+TGVhY2gsIFAuPC9hPiwg
PGEgaHJlZj0ibWFpbHRvOm1pY2hhZWxAcmVmYWN0b3JlZC1uZXR3b3Jrcy5jb20iPk1lYWxsaW5n
LCBNLjwvYT4sIGFuZCA8YSBocmVmPSJtYWlsdG86cnNhbHpAZGF0YXBvd2VyLmNvbSI+Ui4gU2Fs
ejwvYT4sICZsZHF1bzs8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MTIy
Ij5BIFVuaXZlcnNhbGx5IFVuaXF1ZSBJRGVudGlmaWVyIChVVUlEKSBVUk4gTmFtZXNwYWNlPC9h
PiwmcmRxdW87IFJGQyZuYnNwOzQxMjIsIEp1bHkmbmJzcDsyMDA1ICg8YSBocmVmPSJodHRwOi8v
d3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM0MTIyLnR4dCI+VFhUPC9hPiwgPGEgaHJlZj0iaHR0
cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzQxMjIuaHRtbCI+SFRNTDwv
YT4sIDxhIGhyZWY9Imh0dHA6Ly94bWwucmVzb3VyY2Uub3JnL3B1YmxpYy9yZmMveG1sL3JmYzQx
MjIueG1sIj5YTUw8L2E+KS48L3RkPjwvdHI+DQo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCIg
dmFsaWduPSJ0b3AiPjxhIG5hbWU9IlczQy5DUi14bWwxMS0yMDAyMTAxNSI+W1czQy5DUi14bWwx
MS0yMDAyMTAxNV08L2E+PC90ZD4NCjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkNvd2FuLCBKLiwg
JmxkcXVvOzxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDIvQ1IteG1sMTEtMjAwMjEw
MTUiPkV4dGVuc2libGUgTWFya3VwIExhbmd1YWdlIChYTUwpIDEuMTwvYT4sJnJkcXVvOyBXM0Mg
Q1ImbmJzcDtDUi14bWwxMS0yMDAyMTAxNSwgT2N0b2JlciZuYnNwOzIwMDIuPC90ZD48L3RyPg0K
PC90YWJsZT4NCg0KPGEgbmFtZT0icmZjLmF1dGhvcnMiPjwvYT48YnIgLz48aHIgLz4NCjx0YWJs
ZSBzdW1tYXJ5PSJsYXlvdXQiIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMiIgY2xhc3M9
IlRPQ2J1ZyIgYWxpZ249InJpZ2h0Ij48dHI+PHRkIGNsYXNzPSJUT0NidWciPjxhIGhyZWY9IiN0
b2MiPiZuYnNwO1RPQyZuYnNwOzwvYT48L3RkPjwvdHI+PC90YWJsZT4NCjxoMz5BdXRob3IncyBB
ZGRyZXNzPC9oMz4NCjx0YWJsZSB3aWR0aD0iOTklIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIw
IiBjZWxsc3BhY2luZz0iMCI+DQo8dHI+PHRkIGNsYXNzPSJhdXRob3ItdGV4dCI+Jm5ic3A7PC90
ZD4NCjx0ZCBjbGFzcz0iYXV0aG9yLXRleHQiPkF1dGhvciBOYW1lPC90ZD48L3RyPg0KPC90YWJs
ZT4NCjwvYm9keT48L2h0bWw+DQo=

--_005_7C01E631FF4B654FA1E783F1C0265F8C62D263BBTK5EX14MBXC111r_
Content-Type: text/xml; name="jsontokens.xml"
Content-Description: jsontokens.xml
Content-Disposition: attachment; filename="jsontokens.xml"; size=32535;
	creation-date="Thu, 26 Aug 2010 19:21:37 GMT";
	modification-date="Thu, 26 Aug 2010 05:36:01 GMT"
Content-Transfer-Encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVMtQVNDSUkiPz4KPCEtLSBlZGl0ZWQgd2l0
aCBYTUxTcHkgdjIwMTAgcmVsLiAzIHNwMSAoeDY0KSAoaHR0cDovL3d3dy5hbHRvdmEuY29tKSBi
eSBZYXJvbiBZLiBHb2xhbmQgKE1pY3Jvc29mdCkgLS0+CjwhRE9DVFlQRSByZmMgU1lTVEVNICJy
ZmMyNjI5LmR0ZCIgWwo8IUVOVElUWSByZmMyMTE5IFBVQkxJQyAiIiAiaHR0cDovL3htbC5yZXNv
dXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4yMTE5LnhtbCI+CjwhRU5U
SVRZIE9BU0lTLnNhbWwtY29yZS0yLjAtb3MgUFVCTElDICIiICJodHRwOi8veG1sLnJlc291cmNl
Lm9yZy9wdWJsaWMvcmZjL2JpYnhtbDIvcmVmZXJlbmNlLk9BU0lTLnNhbWwtY29yZS0yLjAtb3Mu
eG1sIj4KPCFFTlRJVFkgVzNDLkNSLXhtbDExLTIwMDIxMDE1IFBVQkxJQyAiIiAiaHR0cDovL3ht
bC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9iaWJ4bWw0L3JlZmVyZW5jZS5XM0MuQ1IteG1sMTEt
MjAwMjEwMTUueG1sIj4KPCFFTlRJVFkgUkZDMjEwNCBQVUJMSUMgIiIgImh0dHA6Ly94bWwucmVz
b3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMjEwNC54bWwiPgo8IUVO
VElUWSBSRkMzMjc1IFBVQkxJQyAiIiAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm
Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4zMjc1LnhtbCI+CjwhRU5USVRZIFJGQzMzMzkgUFVCTElD
ICIiICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu
UkZDLjMzMzkueG1sIj4KPCFFTlRJVFkgUkZDMzYyOSBQVUJMSUMgIiIgImh0dHA6Ly94bWwucmVz
b3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuMzYyOS54bWwiPgo8IUVO
VElUWSBSRkMzOTg2IFBVQkxJQyAiIiAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm
Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy4zOTg2LnhtbCI+CjwhRU5USVRZIFJGQzQxMjIgUFVCTElD
ICIiICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu
UkZDLjQxMjIueG1sIj4KPCFFTlRJVFkgUkZDNDYyNyBQVUJMSUMgIiIgImh0dHA6Ly94bWwucmVz
b3VyY2Uub3JnL3B1YmxpYy9yZmMvYmlieG1sL3JlZmVyZW5jZS5SRkMuNDYyNy54bWwiPgo8IUVO
VElUWSBSRkM0NjQ4IFBVQkxJQyAiIiAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3Jm
Yy9iaWJ4bWwvcmVmZXJlbmNlLlJGQy40NjQ4LnhtbCI+CjwhRU5USVRZIFJGQzUyMjYgUFVCTElD
ICIiICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2JpYnhtbC9yZWZlcmVuY2Uu
UkZDLjUyMjYueG1sIj4KXT4KPD9yZmMgdG9jPSJ5ZXMiPz4KPD9yZmMgdG9jb21wYWN0PSJ5ZXMi
Pz4KPD9yZmMgdG9jZGVwdGg9IjMiPz4KPD9yZmMgdG9jaW5kZW50PSJ5ZXMiPz4KPD9yZmMgc3lt
cmVmcz0ieWVzIj8+Cjw/cmZjIHNvcnRyZWZzPSJ5ZXMiPz4KPD9yZmMgY29tbWVudHM9InllcyI/
Pgo8P3JmYyBpbmxpbmU9InllcyI/Pgo8P3JmYyBjb21wYWN0PSJ5ZXMiPz4KPD9yZmMgc3ViY29t
cGFjdD0ibm8iPz4KPHJmYyBjYXRlZ29yeT0iZXhwIiBkb2NOYW1lPSJkcmFmdC1zb21lb25lLWpz
b24tdG9rZW5zLWZvcm1hdC0wMCIKICAgICBpcHI9InRydXN0MjAwOTAyIj4KICA8ZnJvbnQ+CiAg
ICA8dGl0bGU+SlNPTiBUb2tlbnM8L3RpdGxlPgoKICAgIDxhdXRob3IgZnVsbG5hbWU9IkF1dGhv
ciBOYW1lIiBpbml0aWFscz0iQS4iIHN1cm5hbWU9Ik5hbWUiPgogICAgICA8b3JnYW5pemF0aW9u
Pjwvb3JnYW5pemF0aW9uPgogICAgPC9hdXRob3I+CgogICAgPGRhdGUgZGF5PSIyNCIgbW9udGg9
IkF1Z3VzdCIgeWVhcj0iMjAxMCIgLz4KCiAgICA8YXJlYT5BcHBsaWNhdGlvbnM8L2FyZWE+Cgog
ICAgPGtleXdvcmQ+UkZDPC9rZXl3b3JkPgoKICAgIDxrZXl3b3JkPlJlcXVlc3QgZm9yIENvbW1l
bnRzPC9rZXl3b3JkPgoKICAgIDxrZXl3b3JkPkktRDwva2V5d29yZD4KCiAgICA8a2V5d29yZD5J
bnRlcm5ldC1EcmFmdDwva2V5d29yZD4KCiAgICA8a2V5d29yZD5Bc3NlcnRpb248L2tleXdvcmQ+
CgogICAgPGtleXdvcmQ+U2ltcGxlIFdlYiBUb2tlbnM8L2tleXdvcmQ+CgogICAgPGtleXdvcmQ+
U1dUPC9rZXl3b3JkPgoKICAgIDxrZXl3b3JkPkpTT04gVG9rZW5zPC9rZXl3b3JkPgoKICAgIDxr
ZXl3b3JkPkpTT048L2tleXdvcmQ+CgogICAgPGFic3RyYWN0PgogICAgICA8dD5KU09OIFRva2Vu
cyBkZWZpbmUgYW4gYXNzZXJ0aW9uIGZvcm1hdCB0aGF0IGNhbiBtb3ZlIGNsYWltcyBiZXR3ZWVu
CiAgICAgIHR3byBwYXJ0aWVzLiBUaGUgY2xhaW1zIGluIGEgSlNPTiBUb2tlbiBhc3NlcnRpb24g
YXJlIGVuY29kZWQgYXMgYSBKU09OCiAgICAgIG9iamVjdCB3aGljaCBpcyB0aGVuIEhNQUMnZCBv
ciBkaWdpdGFsbHkgc2lnbmVkLjwvdD4KICAgIDwvYWJzdHJhY3Q+CgogICAgPG5vdGUgdGl0bGU9
IlJlcXVpcmVtZW50cyBMYW5ndWFnZSI+CiAgICAgIDx0PlRoZSBrZXkgd29yZHMgIk1VU1QiLCAi
TVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgICAgIlNIT1VM
RCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGlu
IHRoaXMKICAgICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBp
biA8eHJlZgogICAgICB0YXJnZXQ9IlJGQzIxMTkiPlJGQyAyMTE5PC94cmVmPi48L3Q+CiAgICA8
L25vdGU+CiAgPC9mcm9udD4KCiAgPG1pZGRsZT4KICAgIDxzZWN0aW9uIHRpdGxlPSJJbnRyb2R1
Y3Rpb24iPgogICAgICA8dD5KU09OIFRva2VucyBwcm92aWRlIGEgc2ltcGxpZmllZCBhc3NlcnRp
b24gZm9ybWF0IGludGVuZGVkIGZvciBzcGFjZQogICAgICBjb25zdHJhaW5lZCBlbnZpcm9ubWVu
dHMgc3VjaCBhcyBIVFRQIEF1dGhvcml6YXRpb24gaGVhZGVycyBhbmQgVVJJCiAgICAgIHF1ZXJ5
IHBhcmFtZXRlcnMuIEpTT04gVG9rZW5zIGVuY29kZSB0aGUgYXNzZXJ0aW9uIHRvIGJlIHRyYW5z
bWl0dGVkIGFzCiAgICAgIGEgSlNPTiBvYmplY3QgKGFzIGRlZmluZWQgaW4gPHhyZWYgdGFyZ2V0
PSJSRkM0NjI3Ij5SRkMgNDYyNzwveHJlZj4pCiAgICAgIHdoaWNoIGlzIHRoZW4gZWl0aGVyIEhN
QUMnZCBvciBkaWdpdGFsbHkgc2lnbmVkLjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlv
biB0aXRsZT0iVGVybWlub2xvZ3kiPgogICAgICA8dD48bGlzdCBzdHlsZT0iaGFuZ2luZyI+CiAg
ICAgICAgICA8dCBoYW5nVGV4dD0iSlNPTiBUb2tlbiBTZWdtZW50Ij5PbmUgb2YgdGhlIHR3byBw
YXJ0cyB0aGF0IG1ha2UgdXAgYQogICAgICAgICAgSlNPTiBUb2tlbi48L3Q+CgogICAgICAgICAg
PHQgaGFuZ1RleHQ9IkpTT04gQ3J5cHRvIFNlZ21lbnQiPlRoZSBmaXJzdCBKU09OIFRva2VuIFNl
Z21lbnQgdGhhdAogICAgICAgICAgY29udGFpbnMgY3J5cHRvZ3JhcGhpYyBtYXRlcmlhbCBzdWNo
IGFzIGEgSE1BQyBvciBzaWduYXR1cmUgdGhhdAogICAgICAgICAgc2VjdXJlcyB0aGUgdG9rZW4n
cyBjb250ZW50cy48L3Q+CgogICAgICAgICAgPHQgaGFuZ1RleHQ9IkpTT04gQ2xhaW0gU2VnbWVu
dCI+VGhlIHNlY29uZCBKU09OIFRva2VuIFNlZ21lbnQgdGhhdAogICAgICAgICAgY29udGFpbnMg
YSBKU09OIG9iamVjdCB0aGF0IGVuY29kZXMgdGhlIGNsYWltcyBiZWluZyBtYWRlIGJ5IHRoZQog
ICAgICAgICAgSlNPTiBUb2tlbiBhbmQgaGFzIGJlZW4gYmFzZTY0dXJsIGVuY29kZWQuPC90PgoK
ICAgICAgICAgIDx0IGhhbmdUZXh0PSJKU09OIFRva2VuIj5BIHN0cmluZyBjb25zaXN0aW5nIG9m
IHR3byBKU09OIFRva2VuCiAgICAgICAgICBTZWdtZW50cywgZmlyc3QgdGhlIEpTT04gQ3J5cHRv
IFNlZ21lbnQsIHRoZW4gdGhlIEpTT04gQ2xhaW0KICAgICAgICAgIFNlZ21lbnQsIHNlcGFyYXRl
ZCBieSBhIHBlcmlvZCBjaGFyYWN0ZXIuPC90PgoKICAgICAgICAgIDx0IGhhbmdUZXh0PSJEZWNv
ZGVkIEpTT04gQ2xhaW0gU2VnbWVudCI+QSBKU09OIENsYWltIFNlZ21lbnQgdGhhdAogICAgICAg
ICAgaGFzIGJlZW4gYmFzZTY0dXJsIGRlY29kZWQgYmFjayBpbnRvIGEgSlNPTiBvYmplY3QuPC90
PgoKICAgICAgICAgIDx0IGhhbmdUZXh0PSJNZW1iZXIiPkEgSlNPTiB0ZXJtIHJlZmVycmluZyB0
byB0aGUgY29udGVudHMgb2YgYSBKU09OCiAgICAgICAgICBvYmplY3QuPC90PgogICAgICAgIDwv
bGlzdD48L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9IkV4YW1wbGUiPgog
ICAgICA8c2VjdGlvbiB0aXRsZT0iSlNPTiBUb2tlbiB1c2luZyBIbWFjU2hhMjU2Ij4KCQkgIDxz
ZWN0aW9uIHRpdGxlPSJFbmNvZGluZyI+CiAgICAgICAgPHQ+VGhlIGRlY29kZWQgSlNPTiBDbGFp
bSBTZWdtZW50IHdlIHdpbGwgdXNlIGluIHRoaXMgZXhhbXBsZSBpczo8L3Q+CiAgICAgICAgPGZp
Z3VyZSBhbmNob3I9IlNhbXBsZURlY29kZWQiCiAgICAgICAgICAgICAgICB0aXRsZT0iU2FtcGxl
IGRlY29kZWQgSlNPTiBDbGFpbSBTZWdtZW50Ij4KICAgICAgICAgIDxhcnR3b3JrPjwhW0NEQVRB
W3siaXNzdWVyIjoiam9lIiwKICJhbGdvcml0aG0iOiJIbWFjU2hhMjU2IiwKICJub3RfYWZ0ZXIi
OiIxMjgyODg1MjQ1IiwKICJodHRwOi8vZXhhbXBsZS5jb20vaXNfcm9vdCI6dHJ1ZX1dXT48L2Fy
dHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+Tm90ZSB0aGF0IHdoaXRlIHNwYWNl
IGlzIGV4cGxpY2l0bHkgYWxsb3dlZCBpbiBKU09OIG9iamVjdHMuIFRoZSBmb2xsb3dpbmcgaXMg
YSBieXRlIGFycmF5IGNvbnRhaW5pbmcgdGhlIFVURi04IGNoYXJhY3RlcnMgdGhhdCBtYWtlIHVw
IHRoZSBkZWNvZGVkIEpTT04gQ2xhaW1zIFNlZ21lbnQ6IFsxMjMsIDM0LCAxMDUsIDExNSwgMTE1
LCAxMTcsIDEwMSwgMTE0LCAzNCwgNTgsIDM0LAogICAgMTA2LCAxMTEsIDEwMSwgMzQsIDQ0LCAx
MCwgMzIsIDM0LCA5NywgMTA4LCAxMDMsCiAgICAxMTEsIDExNCwgMTA1LCAxMTYsIDEwNCwgMTA5
LCAzNCwgNTgsIDM0LCA3MiwgMTA5LAogICAgOTcsIDk5LCA4MywgMTA0LCA5NywgNTAsIDUzLCA1
NCwgMzQsIDQ0LCAxMCwgMzIsCiAgICAzNCwgMTEwLCAxMTEsIDExNiwgOTUsIDk3LCAxMDIsIDEx
NiwgMTAxLCAxMTQsIDM0LCA1OCwgMzQsIDQ5LCA1MCwgNTYsIDUwLCA1NiwKICAgIDU2LCA1Mywg
NTAsIDUyLCA1MywgMzQsIDQ0LCAxMCwgMzIsIDM0LCAxMDQsIDExNiwKICAgIDExNiwgMTEyLCA1
OCwgNDcsIDQ3LCAxMDEsIDEyMCwgOTcsIDEwOSwgMTEyLCAxMDgsCiAgICAxMDEsIDQ2LCA5OSwg
MTExLCAxMDksIDQ3LCAxMDUsIDExNSwgOTUsIDExNCwgMTExLAogICAgMTExLCAxMTYsIDM0LCA1
OCwgMTE2LCAxMTQsIDExNywgMTAxLCAxMjVdPC90PgogICAgPHQ+VGhlIHByZXZpb3VzIGlzIHRo
ZW4gYmFzZTY0dXJsIGVuY29kZWQgYW5kIGhhcyBpdHMgcGFkZGluZyBjaGFyYWN0ZXJzIHJlbW92
ZWQuIFRoaXMgd2lsbCB0aGVuIG91dHB1dCB0aGUgc3RyaW5nOiAiZXlKcGMzTjFaWElpT2lKcWIy
VWlMQW9nSW1Gc1oyOXlhWFJvYlNJNklraHRZV05UYUdFeU5UWWlMQW9nSW01dmRGOWhablJsY2lJ
NklqRXlPREk0T0RVeU5EVWlMQW9nSW1oMGRIQTZMeTlsZUdGdGNHeGxMbU52YlM5cGMxOXliMjkw
SWpwMGNuVmxmUSIuIFRoaXMgc3RyaW5nIGlzIHRoZSBKU09OIENsYWltIFNlZ21lbnQuPC90Pgog
ICAgICAgIDx0PkhNQUNzIGFyZSBnZW5lcmF0ZWQgdXNpbmcga2V5cy4gSW4gdGhpcyBjYXNlIHdl
IHdpbGwgdXNlIHRoZSBmb2xsb3dpbmcga2V5IHdoaWNoIGlzIHJlcHJlc2VudGVkIGFzIGEgYnl0
ZSBhcnJheTogWzIzMywgMzcsIDU3LCA5OSwgNzIsIDI5LCAxOTYsIDIyMCwgOTAsIDEwNywgMjMw
LAogICAgMTkwLCAyNDEsIDE0NSwgMjQzLCAxMiwgMTE0LCAxNTQsIDE4LCA5NCwgNTksIDU2LAog
ICAgMTM0LCA5MywgMjA4LCAxMTUsIDIzMiwgMTcyLCA4OCwgMjA4LCAyNCwgMTk1LCAxNzQsCiAg
ICAxOTcsIDE0OCwgOTYsIDEzOSwgMjA2LCA5MCwgMjQ3LCAxNzMsIDE5OCwgMTkwLCAxNjIsCiAg
ICAxMCwgODMsIDg0LCAyMTcsIDIwNiwgMTAyLCAxNTQsIDIyLCAxODksIDg5LCAzOSwKICAgIDE1
NywgMTUyLCAxOTUsIDI0NiwgMjQ5LCAxMzIsIDE2MiwgMCwgMjMzXS48L3Q+CiAgICA8dD5BbHRl
cm5hdGl2ZWx5IHNpbmNlIGl0IG1heSBiZSBlYXNpZXIgdG8gcHJvY2VzcyBoZXJlIGlzIHRoZSBz
YW1lIGtleSBhcyBhIGJhc2U2NHVybCBlbmNvZGVkIHZhbHVlIHdpdGggcGFkZGluZyByZW1vdmVk
OiAiNlNVNVkwZ2R4TnhhYS1hLThaSHpESEthRWw0N09JWmQwSFBvckZqUUdNT3V4WlJnaTg1YTk2
M0d2cUlLVTFUWnptYWFGcjFaSjUyWXdfYjVoS0lBNlEiLjwvdD4KICAgIDx0Pk5vdyB3ZSBjYW4g
c3VibWl0IHRoZSBKU09OIENsYWltIFNlZ21lbnQgYWxvbmcgd2l0aCB0aGUga2V5IHRvIGEgU0hB
IDI1NiBiYXNlZCBITUFDIHdoaWNoIHdpbGwgb3V0cHV0IHRoZSBmb2xsb3dpbmcgYnl0ZSBhcnJh
eTogWzEyNiwgMTA1LCAxODIsIDEyOSwgMjcsIDIwMSwgMTY1LCAxNDcsIDkxLCAyMzcsIDI0LAog
ICAgMjI5LCA3NiwgNTcsIDUyLCAyMzgsIDE5MiwgMzQsIDkzLCAyMjksIDk3LCAxNTksIDEsCiAg
ICAwLCA0OCwgNTEsIDE4NSwgMTU0LCAxNjMsIDIyNywgMTM0LCAyMjVdLjwvdD4KICAgIDx0PlRo
aXMgYnl0ZSBhcnJheSBpcyB0aGVuIGJhc2U2NHVybCBlbmNvZGVkIHdpdGggcGFkZGluZyByZW1v
dmVkIHByb2R1Y2luZyB0aGUgc3RyaW5nOiAiZm1tMmdSdkpwWk5iN1JqbFREazA3c0FpWGVWaG53
RUFNRE81bXFQamh1RSIuIFRoaXMgc3RyaW5nIGlzIHRoZSBKU09OIENyeXB0byBTZWdtZW50Ljwv
dD4KICAgIDx0PlRoZXJlZm9yZSB0aGUgSlNPTiBUb2tlbiB3b3VsZCBiZTogImZtbTJnUnZKcFpO
YjdSamxURGswN3NBaVhlVmhud0VBTURPNW1xUGpodUUuZXlKcGMzTjFaWElpT2lKcWIyVWlMQW9n
SW1Gc1oyOXlhWFJvYlNJNklraHRZV05UYUdFeU5UWWlMQW9nSW01dmRGOWhablJsY2lJNklqRXlP
REk0T0RVeU5EVWlMQW9nSW1oMGRIQTZMeTlsZUdGdGNHeGxMbU52YlM5cGMxOXliMjkwSWpwMGNu
VmxmUSIuPC90Pgo8L3NlY3Rpb24+CjxzZWN0aW9uIHRpdGxlPSJEZWNvZGluZyI+Cgk8dD5EZWNv
ZGluZyB0aGUgSlNPTiBDbGFpbSBTZWdtZW50IGZpcnN0IHJlcXVpcmVzIHJlbW92aW5nIHRoZSBi
YXNlNjR1cmwgZW5jb2Rpbmcgd2l0aCBubyBwYWRkaW5nLiBQZXIgPHhyZWYgdGFyZ2V0PSJiYXNl
NjR1cmxsb2dpYyI+PC94cmVmPiB3ZSBuZWVkIHRvIGNhbGN1bGF0ZSB0aGUgbGVuZ3RoIG9mIHRo
ZSBKU09OIENsYWltIFNlZ21lbnQgc3RyaW5nIHdoaWNoIGlzIDE0MiBjaGFyYWN0ZXJzIGFuZCBk
aXZpZGVkIHRoYXQgbnVtYmVyIGJ5IDQgYW5kIGdldCB0aGUgcmVtYWluZGVyIHdoaWNoIGlzIDIu
IFBlciA8eHJlZiB0YXJnZXQ9IlBhZGRpbmdIYW5kbGluZyI+PC94cmVmPiB3ZSBub3cga25vdyB3
ZSBuZWVkIHRvIGFkZCB0d28gcGFkZGluZyBieXRlcy4gV2l0aCB0aGF0IGRhdGEgd2UgY2FuIGJh
c2U2NHVybCBkZWNvZGUgdGhlIEpTT04gQ2xhaW0gU2VnbWVudCBzdHJpbmcgYW5kIHR1cm4gaXQg
aW50byB0aGUgcHJldmlvdXNseSBwcm92aWRlZCBVVEYtOCBieXRlIGFycmF5IHdoaWNoIHdlIGNh
biB0aGVuIHRyYW5zbGF0ZSBpbnRvIHRoZSBEZWNvZGVkIEpTT04gQ2xhaW0gU2VnbWVudCBzdHJp
bmcuIEF0IHRoYXQgcG9pbnQgd2UgY2FuIHZhbGlkYXRlIHRoYXQgdGhlIHJlc3VsdGluZyBzdHJp
bmcgaXMgY29tcGxldGVseSBsZWdhbCBKU09OIGFuZCB2YWxpZGF0ZSB0aGUgdmFyaW91cyBjbGFp
bXMgYW5kIGFsZ29yaXRobS48L3Q+Cgk8dD5Ob3cgd2UganVzdCByZXBlYXQgdGhlIHByZXZpb3Vz
IHByb2Nlc3Mgb2YgdXNpbmcgdGhlIGV4cGVjdGVkIGtleSBhbmQgdGhlIEpTT04gQ2xhaW0gU2Vn
bWVudCBhcyBpbnB1dCB0byBhIFNIQSAyNTYgSE1BQyBmdW5jdGlvbiBhbmQgdGhlbiB0YWtpbmcg
dGhlIG91dHB1dCwgYmFzZTY0dXJsIGVuY29kaW5nIGl0IHdpdGhvdXQgcGFkZGluZyBhbmQgc2Vl
aW5nIGlmIGl0IGlzIGNoYXJhY3RlciBmb3IgY2hhcmFjdGVyIGVxdWFsIHRvIEpTT04gQ3J5cHRv
IFNlZ21lbnQgaW4gdGhlIEpTT04gVG9rZW4uPC90PgoJPC9zZWN0aW9uPgoJPC9zZWN0aW9uPgoJ
ICA8c2VjdGlvbiB0aXRsZT0iSlNPTiBUb2tlbiB1c2luZyBFQ0RTQSBQMjU2IFNIQTI1NiI+CgkJ
ICA8c2VjdGlvbiB0aXRsZT0iRW5jb2RpbmciPgoJICAgICAgICA8dD5UaGUgZGVjb2RlZCBKU09O
IENsYWltIFNlZ21lbnQgd2Ugd2lsbCB1c2UgaW4gdGhpcyBleGFtcGxlIGlzOjwvdD4KICAgICAg
ICA8ZmlndXJlIGFuY2hvcj0iU2FtcGxlRGVjb2RlZEVjZHNhIgogICAgICAgICAgICAgICAgdGl0
bGU9IlNhbXBsZSBkZWNvZGVkIEpTT04gQ2xhaW0gU2VnbWVudCI+CiAgICAgICAgICA8YXJ0d29y
az48IVtDREFUQVt7Imlzc3VlciI6ImpvZSIsCiAiYWxnb3JpdGhtIjoiRWNkc2FQMjU2U2hhMjU2
IiwKICJub3RfYWZ0ZXIiOiIxMjgyODg1MjQ1IiwKICJodHRwOi8vZXhhbXBsZS5jb20vaXNfcm9v
dCI6dHJ1ZX1dXT48L2FydHdvcms+CiAgICAgICAgPC9maWd1cmU+CiAgICAgICAgPHQ+VGhlIG9u
bHkgZGlmZmVyZW5jZSB3aXRoIHRoZSBwcmV2aW91cyBkZWNvZGVkIEpTT04gQ2xhaW0gU2VnbWVu
dCBpcyB0aGUgYWxnb3JpdGhtLiBIb3dldmVyIHRoZSByZXN0IG9mIHRoZSBwcm9jZXNzIG9mIGdl
bmVyYXRpbmcgdGhlIEpTT04gQ2xhaW0gU2VnbWVudCBpcyB0aGUgc2FtZS4gVGhlIGZpbmFsIGJh
c2U2NHVybCB3aXRob3V0IHBhZGRpbmcgb3V0cHV0IGlzICJleUpwYzNOMVpYSWlPaUpxYjJVaUxB
b2dJbUZzWjI5eWFYUm9iU0k2SWtodFlXTlRhR0V5TlRZaUxBb2dJbTV2ZEY5aFpuUmxjaUk2SWpF
eU9ESTRPRFV5TkRVaUxBb2dJbWgwZEhBNkx5OWxlR0Z0Y0d4bExtTnZiUzlwYzE5eWIyOTBJanAw
Y25WbGZRIi48L3Q+CiAgICAgICAgPHQ+VGhlIHZhbHVlcyBvZiB0aGUgRUNEU0Ega2V5IHVzZWQg
aW4gdGhpcyBleGFtcGxlLCBwcmVzZW50ZWQgYXMgYmFzZTY0dXJsIGVuY29kZWQgdmFsdWVzIHdp
dGhvdXQgcGFkZGluZyBvZiBiaWcgZW5kaWFuIGJ5dGUgYXJyYXlzIGVuY29kaW5nIHVuc2lnbmVk
IGludGVnZXJzIGFyZTo8L3Q+CiAgICAgICAgPHRleHR0YWJsZSB0aXRsZT0iRUNEU0EgRXhhbXBs
ZSBrZXkgdmFsdWVzIj4KCQkJCQkJCQkJPHR0Y29sIGFsaWduPSJsZWZ0Ij5QYXJhbWV0ZXIgTmFt
ZTwvdHRjb2w+CgkJCQkJCQkJCTx0dGNvbCBhbGlnbj0ibGVmdCI+VmFsdWU8L3R0Y29sPgoJCQkJ
CQkJCQkKCQkJCQkJCQkJPGM+eDwvYz4KCQkJCQkJCQkJPGM+MkppLWRCZFY0NUFyem1zV0lkc0xL
MU05TzgyLTBUQnFfOVpZRnphazYxYzwvYz4KCQkJCQkJCQkJCgkJCQkJCQkJCTxjPnk8L2M+CgkJ
CQkJCQkJCTxjPm9DcjJiRmNjVFRDTEhSZ0g1TzRsMWxxSmpnbHpnRm5EbkhvYTlSektIN008L2M+
CgkJCQkJCQkJCQoJCQkJCQkJCQk8Yz5kPC9jPgoJCQkJCQkJCQk8Yz5nWUlqeDdwa2NHSnlPcnJm
eW1LZS1aYUk3bnBUdTRZZ0JVVm9GU2U4V2pvPC9jPgoJCTwvdGV4dHRhYmxlPgoJCTx0PlRoZSBF
Q0RTQSBrZXkgKHRoZSBwdWJsaWMgcGFydCwgeCBhbmQgeSwgcGx1cyB0aGUgcHJpdmF0ZSBwYXJ0
IGQpIGFyZSB0aGVuIHBhc3NlZCB0byBhIEVDRFNBIHNpZ25pbmcgZnVuY3Rpb24gd2hpY2ggYWxz
byB0YWtlcyB0aGUgY3VydmUgdHlwZSwgUDI1NiwgdGhlIGhhc2ggdHlwZSwgU0hBIDI1NiBhbmQg
dGhlIEpTT04gQ2xhaW0gU2VnbWVudCBhcyBpbnB1dHMuIEl0IHdpbGwgb3V0cHV0IHR3byB1bnNp
Z25lZCBpbnRlZ2VycyBSIGFuZCBTLiBJbiB0aGlzIGV4YW1wbGUgdGhlIFIgYW5kIFMgdmFsdWVz
LCBnaXZlbiBhcyBieXRlIGFycmF5cyBpbiBiaWcgZW5kaWFuIG9yZGVyIGFyZTo8L3Q+CgkJPHRl
eHR0YWJsZSB0aXRsZT0iUiBhbmQgUyB2YWx1ZXMgYXMgYmlnIGVuZGlhbiBieXRlIGFycmF5cyI+
CgkJCTx0dGNvbCBhbGlnbj0ibGVmdCI+UGFyYW1ldGVyIE5hbWU8L3R0Y29sPgoJCQk8dHRjb2wg
YWxpZ249ImxlZnQiPlZhbHVlPC90dGNvbD4KCQkJCgkJCTxjPlI8L2M+CgkJCTxjPls0MywgNzYs
IDIyNiwgNTcsIDIwNSwgMTk3LCAxMjYsIDc3LCA0MiwgMjAyLCAyNDYsCiAgICA1NSwgNzgsIDIw
OSwgMjUzLCAxNjUsIDE2OSwgMTE3LCAzLCAxODYsIDIxOSwgMTI1LAogICAgNjMsIDIxNSwgOTMs
IDIwOSwgMTI3LCAxMTcsIDIzOCwgMjI1LCAyNiwgMjQ5XTwvYz4KICAgIAoJCQk8Yz5TPC9jPgoJ
CQk8Yz5bMjMzLCAzMiwgMTI4LCA5LCA5LCAxOTIsIDYwLCAxODEsIDU4LCAyNDQsIDczLCA0NiwK
ICAgIDEwNSwgMTkwLCAyMDAsIDIwMiwgMjA4LCAxMjksIDE1NSwgMTczLCAyNDksIDEzOSwKICAg
IDIxNiwgMTA5LCAyNDUsIDgxLCAyMzIsIDExOSwgMjAyLCA1NywgNCwgMTM4XTwvYz4KCQk8L3Rl
eHR0YWJsZT4KCQk8dD5XZSB0aGVuIGNvbmNhdGVuYXRlIHRoZSBTIGFycmF5IHRvIHRoZSBlbmQg
b2YgdGhlIFIgYXJyYXkgYW5kIGJhc2U2NHVybCBlbmNvZGUgdGhlIHJlc3VsdCB3aXRob3V0IHBh
ZGRpbmcgcHJvZHVjaW5nIHRoZSBKU09OIENyeXB0byBTZWdtZW50IHN0cmluZyAiSzB6aU9jM0Zm
azBxeXZZM1R0SDlwYWwxQTdyYmZUX1hYZEZfZGU3aEd2bnBJSUFKQ2NBOHRUcjBTUzVwdnNqSzBJ
R2JyZm1MMkczMVVlaDN5amtFaWciLjwvdD4KCQk8dD5UaGUgSlNPTiBUb2tlbiB3b3VsZCB0aGVy
ZWZvcmUgYmUgdGhlIHN0cmluZyAiSzB6aU9jM0ZmazBxeXZZM1R0SDlwYWwxQTdyYmZUX1hYZEZf
ZGU3aEd2bnBJSUFKQ2NBOHRUcjBTUzVwdnNqSzBJR2JyZm1MMkczMVVlaDN5amtFaWcuZXlKcGMz
TjFaWElpT2lKcWIyVWlMQW9nSW1Gc1oyOXlhWFJvYlNJNklraHRZV05UYUdFeU5UWWlMQW9nSW01
dmRGOWhablJsY2lJNklqRXlPREk0T0RVeU5EVWlMQW9nSW1oMGRIQTZMeTlsZUdGdGNHeGxMbU52
YlM5cGMxOXliMjkwSWpwMGNuVmxmUSIuPC90PgoJCSAgPC9zZWN0aW9uPgoJCTxzZWN0aW9uIHRp
dGxlPSJEZWNvZGluZyI+CgkJCQk8dD5EZWNvZGluZyB0aGUgSlNPTiBUb2tlbiBmcm9tIHRoaXMg
ZXhhbXBsZSByZXF1aXJlcyBwcm9jZXNzaW5nIHRoZSBKU09OIENsYWltIFNlZ21lbnQgZXhhY3Rs
eSBhcyBoYW5kbGVkIGluIHRoZSBwcmV2aW91cyBleGFtcGxlLiBWYWxpZGF0aW5nIHRoZSBKU09O
IENyeXB0byBTZWdtZW50IGlzIGEgbGl0dGxlIGRpZmZlcmVuY2UuIFdlIG11c3QgYmFzZTY0dXJs
IGRlY29kZSB0aGUgSlNPTiBDcnlwdG8gU2VnbWVudCBhcyBpbiB0aGUgcHJldmlvdXMgZXhhbXBs
ZSBidXQgd2UgdGhlbiBuZWVkIHRvIHNwbGl0IHRoZSA2NCBtZW1iZXIgYnl0ZSBhcnJheSB0aGF0
IG11c3QgcmVzdWx0IGludG8gdHdvIDMyIGJ5dGUgYXJyYXlzLCB0aGUgZmlyc3QgUiBhbmQgdGhl
IHNlY29uZCBTLiBXZSB0aGVuIGhhdmUgdG8gcGFzcyB4LCB5LCBSLCBTIGFuZCB0aGUgSlNPTiBD
bGFpbSBTZWdtZW50IHRvIGFuIEVDRFNBIHNpZ25hdHVyZSB2ZXJpZmllciB0aGF0IGhhcyBiZWVu
IGNvbmZpZ3VyZWQgdG8gdXNlIHRoZSBQMjU2IGN1cnZlIHdpdGggdGhlIFNIQSAyNTYgaGFzaCBm
dW5jdGlvbi4gQXMgZXhwbGFpbmVkIGluIDx4cmVmIHRhcmdldD0iRGVmaW5pbmdFQ0RTQSI+PC94
cmVmPiB0aGUgdXNlIG9mIHRoZSBrIHZhbHVlIGluIEVDRFNBIG1lYW5zIHRoYXQgd2UgY2Fubm90
IHZhbGlkYXRlIHRoZSBjb3JyZWN0bmVzcyBvZiB0aGUgc2lnbmF0dXJlIGluIHRoZSBzYW1lIHdh
eSB3ZSB2YWxpZGF0ZWQgdGhlIGNvcnJlY3RuZXNzIG9mIHRoZSBITUFDPiBXZSBoYXZlIHRvIGRl
cGVuZCBvbiBhbiBFQ0RTQSB2YWxpZGF0b3IgdG8gdmFsaWRhdGUgdGhlIHNpZ25hdHVyZSBmb3Ig
dXMuPC90PgoJCTwvc2VjdGlvbj4KIDwvc2VjdGlvbj4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2Vj
dGlvbiB0aXRsZT0iQ2xhaW1zIHRoYXQgY2FuIGJlIG1hZGUgaW4gYSBKU09OIFRva2VuIj4KICAg
ICAgPHQ+VGhlIG1lbWJlcnMgb2YgdGhlIEpTT04gb2JqZWN0IGNvbnRhaW4gdGhlIGNsYWltcyBt
YWRlIGJ5IHRoZSBKU09OCiAgICAgIFRva2VuLiBUaGUgZm9sbG93aW5nIGxpc3RzIHNvbWUgcHJl
LWRlZmluZWQgY2xhaW1zLiBOb3RlIGhvd2V2ZXIgd2hhdAogICAgICBjbGFpbXMgYSBKU09OIFRv
a2VuIG11c3QgY29udGFpbiB0byBiZSBjb25zaWRlcmVkIHZhbGlkIGRlcGVuZHMgb24gdGhlCiAg
ICAgIGNvbnRleHQgaW4gd2hpY2ggdGhlIEpTT04gVG9rZW4gaXMgdXNlZCBhbmQgaXMgb3V0c2lk
ZSB0aGUgc2NvcGUgb2YgdGhpcwogICAgICBzcGVjaWZpY2F0aW9uLiBOb25lIG9mIHRoZSBjbGFp
bXMgZGVmaW5lZCBpbiB0aGUgdGFibGUgYmVsb3cgYXJlCiAgICAgIGludGVuZGVkIHRvIGJlIG1h
bmRhdG9yeSBidXQgcmF0aGVyIGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIGEgY2F0YWxvZyBvZgog
ICAgICB1c2VmdWwgY2xhaW1zLjwvdD4KCiAgICAgIDx0ZXh0dGFibGUgYW5jaG9yPSJDbGFpbVRh
YmxlIiB0aXRsZT0iQSBsaXN0IG9mIGNsYWltIGRlZmluaXRpb25zIj4KICAgICAgICA8dHRjb2wg
YWxpZ249ImxlZnQiPkNsYWltIE5hbWU8L3R0Y29sPgoKICAgICAgICA8dHRjb2wgYWxpZ249Imxl
ZnQiPkpTT04gVmFsdWUgVHlwZTwvdHRjb2w+CgogICAgICAgIDx0dGNvbCBhbGlnbj0ibGVmdCI+
Q2xhaW0gU3ludGF4PC90dGNvbD4KCiAgICAgICAgPHR0Y29sIGFsaWduPSJsZWZ0Ij5DbGFpbSBT
ZW1hbnRpY3M8L3R0Y29sPgoKICAgICAgICA8Yz5pc3N1ZXI8L2M+CgogICAgICAgIDxjPnN0cmlu
ZzwvYz4KCiAgICAgICAgPGM+U3RyaW5nQW5kVVJJPC9jPgoKICAgICAgICA8Yz5JZGVudGlmaWVz
IHRoZSBwcmluY2lwYWwgd2hvIGlzc3VlZCB0aGUgSlNPTiBUb2tlbi48L2M+CgogICAgICAgIDxj
PmFsZ29yaXRobTwvYz4KCiAgICAgICAgPGM+c3RyaW5nPC9jPgoKICAgICAgICA8Yz5TdHJpbmdB
bmRVUkk8L2M+CgogICAgICAgIDxjPklkZW50aWZpZXMgdGhlIGNyeXB0b2dyYXBoaWMgYWxnb3Jp
dGhtIGJlaW5nIHVzZWQgdG8gc2VjdXJlIHRoZQogICAgICAgIEpTT04gVG9rZW4uPC9jPgoKICAg
ICAgICA8Yz5ub3RfYWZ0ZXI8L2M+CgogICAgICAgIDxjPmludGVnZXI8L2M+CgogICAgICAgIDxj
PkludERhdGU8L2M+CgogICAgICAgIDxjPklkZW50aWZpZXMgdGhlIHRpbWUgb24gb3IgYWZ0ZXIg
d2hpY2ggdGhlIHRva2VuIE1VU1QgTk9UIGJlCiAgICAgICAgYWNjZXB0ZWQgZm9yIHByb2Nlc3Np
bmcuPC9jPgogICAgICA8L3RleHR0YWJsZT4KCiAgICAgIDx0PlRoZSBjbGFpbSBzeW50YXhlcyBy
ZWZlcnJlZCB0byBhYm92ZSBhcmUgZGVmaW5lZCBiZWxvdzo8L3Q+CgogICAgICA8dGV4dHRhYmxl
IGFuY2hvcj0iQ2xhaW1TeW50YXhEZWZpbml0aW9uIgogICAgICAgICAgICAgICAgIHRpdGxlPSJB
IGxpc3Qgb2Ygc3ludGF4IHR5cGVzIHVzZWQgaW4gY2xhaW0gZGVmaW5pdGlvbnMiPgogICAgICAg
IDx0dGNvbCBhbGlnbj0ibGVmdCI+Q2xhaW0gU3ludGF4IE5hbWU8L3R0Y29sPgoKICAgICAgICA8
dHRjb2wgYWxpZ249ImxlZnQiPkNsYWltIFN5bnRheCBEZWZpbml0aW9uPC90dGNvbD4KCiAgICAg
ICAgPGM+U3RyaW5nQW5kVVJJPC9jPgoKICAgICAgICA8Yz5Bbnkgc3RyaW5nIHZhbHVlIE1BWSBi
ZSB1c2VkIGJ1dCBhIHZhbHVlIGNvbnRhaW5pbmcgYSAiOiIgY2hhcmFjdGVyCiAgICAgICAgTVVT
VCBiZSBhIFVSSSBhcyBkZWZpbmVkIGluIDx4cmVmIHRhcmdldD0iUkZDMzk4NiI+UkZDCiAgICAg
ICAgMzk4NjwveHJlZj4uPC9jPgoKICAgICAgICA8Yz5JbnREYXRlPC9jPgoKICAgICAgICA8Yz5U
aGUgbnVtYmVyIG9mIHNlY29uZHMgZnJvbSAxOTcwLTAxLTAxVDA6MDowWiBhcyBtZWFzdXJlZCBp
biBVVEMKICAgICAgICB1bnRpbCB0aGUgZGVzaXJlZCBkYXRlL3RpbWUuIFNlZSA8eHJlZiB0YXJn
ZXQ9IlJGQzMzMzkiPlJGQwogICAgICAgIDMzMzk8L3hyZWY+IGZvciBkZXRhaWxzIHJlZ2FyZGlu
ZyBkYXRlL3RpbWVzIGluIGdlbmVyYWwgYW5kIFVUQyBpbgogICAgICAgIHBhcnRpY3VsYXIuPC9j
PgogICAgICA8L3RleHR0YWJsZT4KCiAgICAgIDx0PjxsaXN0IHN0eWxlPSJudW1iZXJzIj4KICAg
ICAgICAgIDx0PlRoZSBwcm9jZXNzaW5nIG9mIHRoZSBpc3N1ZXIgY2xhaW0gaXMgZ2VuZXJhbGx5
IGFwcGxpY2F0aW9uCiAgICAgICAgICBzcGVjaWZpYy48L3Q+CgogICAgICAgICAgPHQ+VGhlIHBy
b2Nlc3Npbmcgb2YgdGhlIGFsZ29yaXRobSBjbGFpbSByZXF1aXJlcyB0aGF0LCBpZiBwcmVzZW50
LAogICAgICAgICAgdGhlIHZhbHVlIG9mIHRoZSBhbGdvcml0aG0gY2xhaW0gTVVTVCBiZSBvbmUg
dGhhdCBpcyBib3RoIHN1cHBvcnRlZAogICAgICAgICAgYW5kIGZvciB3aGljaCB0aGVyZSBleGlz
dHMgYSBrZXkgYXNzb2NpYXRlZCB3aXRoIHRoZSBpc3N1ZXIgb2YgdGhlCiAgICAgICAgICBKU09O
IFRva2VuLiBOb3RlIGhvd2V2ZXIgdGhhdCBpZiB0aGUgaXNzdWVyIGNsYWltIGlzIG5vdCBpbmNs
dWRlZAogICAgICAgICAgdGhlbiB0aGUgbWFubmVyIGluIHdoaWNoIHRoZSBpc3N1ZXIgaXMgZGV0
ZXJtaW5lZCBpcyBhcHBsaWNhdGlvbgogICAgICAgICAgc3BlY2lmaWMuPC90PgoKICAgICAgICAg
IDx0PlRoZSBwcm9jZXNzaW5nIG9mIHRoZSBub3RfYWZ0ZXIgY2xhaW0gcmVxdWlyZXMgdGhhdCB0
aGUgY3VycmVudAogICAgICAgICAgZGF0ZS90aW1lIE1VU1QgYmUgYmVmb3JlIHRoZSBkYXRlL3Rp
bWUgbGlzdGVkIGluIHRoZSBub3RfYWZ0ZXIgY2xhaW0KICAgICAgICAgIGlmIHByZXNlbnQuIElt
cGxlbWVudGVycyBNQVkgcHJvdmlkZSBmb3Igc29tZSBzbWFsbCBsZWV3YXksIHVzdWFsbHkKICAg
ICAgICAgIG5vIG1vcmUgdGhhbiBhIGZldyBtaW51dGVzLCB0byBhY2NvdW50IGZvciBjbG9jayBz
a2V3LjwvdD4KICAgICAgICA8L2xpc3Q+RURJVE9SJ1MgTk9URTogRWRpdCB0aGUgcHJldmlvdXMg
dGV4dCBpbiBzbyBpdCdzIG1vcmUKICAgICAgbmF0dXJhbC48L3Q+CgogICAgICA8c2VjdGlvbiB0
aXRsZT0iR2VuZXJhdGluZyB1bmlxdWUgbmFtZXMgYW5kIHZhbHVlcyI+CiAgICAgICAgPHQ+Qm90
aCBjbGFpbSBuYW1lcyBhcyB3ZWxsIGFzIGFsZ29yaXRobSB2YWx1ZXMgY2FuIGJlIGRlZmluZWQg
YXQgd2lsbAogICAgICAgIGJ5IHRob3NlIHVzaW5nIEpTT04gVG9rZW5zLiBIb3dldmVyLCBpbiBv
cmRlciB0byBwcmV2ZW50IGNvbGxpc2lvbnMsCiAgICAgICAgYW55IG5ldyBjbGFpbSBuYW1lIG9y
IGFsZ29yaXRobSB2YWx1ZSBNVVNUIGVpdGhlciBiZSBkZWZpbmVkIGluIGFuIFJGQwogICAgICAg
IHB1Ymxpc2hlZCB2aWEgdGhlIElFVEYgb3IgTVVTVCBiZSBkZWZpbmVkIGFzIGEgVVJJIHRoYXQg
Y29udGFpbnMgYQogICAgICAgIGNvbGxpc2lvbiByZXNpc3RhbnQgbmFtZXNwYWNlLiBFeGFtcGxl
cyBvZiBjb2xsaXNpb24gcmVzaXN0YW50CiAgICAgICAgbmFtZXNwYWNlcyBpbmNsdWRlOiA8bGlz
dCBzdHlsZT0ic3ltYm9scyI+CiAgICAgICAgICAgIDx0PkRvbWFpbiBOYW1lcyw8L3Q+CgogICAg
ICAgICAgICA8dD5PYmplY3QgSWRlbnRpZmllcnMgKE9JRHMpIGFzIGRlZmluZWQgaW4gdGhlIElU
VS1UIFggNjYwIGFuZCBYCiAgICAgICAgICAgIDY3MCBSZWNvbW1lbmRhdGlvbiBzZXJpZXMgb3I8
L3Q+CgogICAgICAgICAgICA8dD5Vbml2ZXJzYWxseSBVbmlxdWUgSURlbnRpZmllciAoVVVJRCkg
YXMgZGVmaW5lZCBpbiA8eHJlZgogICAgICAgICAgICB0YXJnZXQ9IlJGQzQxMjIiPlJGQyA0MTIy
PC94cmVmPi48L3Q+CiAgICAgICAgICA8L2xpc3Q+IEluIGVhY2ggY2FzZSB0aGUgZGVmaW5lciBv
ZiB0aGUgbmFtZSBvciB2YWx1ZSBNVVNUIHRha2UKICAgICAgICByZWFzb25hYmxlIHByZWNhdXRp
b25zIHRvIG1ha2Ugc3VyZSB0aGV5IGFyZSBpbiBjb250cm9sIG9mIHRoZSBwYXJ0IG9mCiAgICAg
ICAgdGhlIG5hbWVzcGFjZSB0aGV5IHVzZSB0byBkZWZpbmUgdGhlIG5hbWUgb3IgdmFsdWUuPC90
PgogICAgICA8L3NlY3Rpb24+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9ImJh
c2U2NHVybCBlbmNvZGluZyBhcyB1c2VkIGJ5IEpTT04gVG9rZW5zIiBhbmNob3I9ImJhc2U2NHVy
bGxvZ2ljIj4KICAgICAgPHQ+SlNPTiBUb2tlbnMgbWFrZSB1c2Ugb2YgdGhlIGJhc2U2NHVybCBl
bmNvZGluZyBhcyBkZWZpbmVkIGluIDx4cmVmCiAgICAgIHRhcmdldD0iUkZDNDY0OCI+UkZDIDQ2
NDg8L3hyZWY+LiBIb3dldmVyIGFzIGFsbG93ZWQgYnkgc2VjdGlvbiAzLjIgb2YKICAgICAgUkZD
IDQ2NDggdGhpcyBzcGVjaWZpY2F0aW9uIG1hbmRhdGVzIHRoYXQgYmFzZTY0dXJsIGVuY29kaW5n
IHdoZW4gdXNlZAogICAgICB3aXRoIEpTT04gVG9rZW5zIE1VU1QgTk9UIHVzZSBwYWRkaW5nLiBU
aGUgcmVhc29uIGZvciB0aGlzIHJlc3RyaWN0aW9uCiAgICAgIGlzIHRoYXQgdGhlIHBhZGRpbmcg
Y2hhcmFjdGVyIGlzIG5vdCBVUkwgc2FmZS48L3Q+CgogICAgICA8dD5UbyBwcm9jZXNzIGEgYmFz
ZTY0dXJsIHZhbHVlIGluIGEgSlNPTiBUb2tlbiBvbmUgbXVzdCBmaXJzdCBjYWxjdWxhdGUKICAg
ICAgdGhlIHNpemUgb2YgdGhlIGJhc2U2NHVybCB2YWx1ZSBhbmQgdGhlbiBkaXZpZGUgdGhhdCBz
aXplIGJ5IGZvdXIgdXNpbmcKICAgICAgbW9kdWxhciBhcml0aG1ldGljLiBMb29rIHVwIHRoZSBy
ZW1haW5kZXIgb2YgdGhlIG1vZHVsYXIgZGl2aXNpb24gaW4gdGhlCiAgICAgIHRhYmxlIGJlbG93
LjwvdD4KCiAgICAgIDx0ZXh0dGFibGUgYW5jaG9yPSJQYWRkaW5nSGFuZGxpbmciCiAgICAgICAg
ICAgICAgICAgdGl0bGU9Ikd1aWRhbmNlIG9uIGhvdyB0byBoYW5kbGUgYmFzZTY0dXJsIGVuY29k
ZWQgdmFsdWVzIHdpdGhvdXQgcGFkZGluZy4iPgogICAgICAgIDx0dGNvbCBhbGlnbj0ibGVmdCI+
UmVtYWluZGVyPC90dGNvbD4KCiAgICAgICAgPHR0Y29sIGFsaWduPSJsZWZ0Ij5BY3Rpb24gdG8g
dGFrZTwvdHRjb2w+CgogICAgICAgIDxjPjA8L2M+CgogICAgICAgIDxjPk5vIHBhZGRpbmcgaXMg
bmVlZGVkLjwvYz4KCiAgICAgICAgPGM+MTwvYz4KCiAgICAgICAgPGM+VGhlIGJhc2U2NHVybCBl
bmNvZGVkIHZhbHVlIGlzIG1hbGZvcm1lZCBhbmQgTVVTVCBiZSByZWplY3RlZCBmb3IKICAgICAg
ICBwcm9jZXNzaW5nLjwvYz4KCiAgICAgICAgPGM+MjwvYz4KCiAgICAgICAgPGM+VHdvIHBhZGRp
bmcgY2hhcmFjdGVycyBhcmUgbmVlZGVkLjwvYz4KCiAgICAgICAgPGM+MzwvYz4KCiAgICAgICAg
PGM+T25lIHBhZGRpbmcgY2hhcmFjdGVyIGlzIG5lZWRlZC48L2M+CiAgICAgIDwvdGV4dHRhYmxl
PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJHZW5lcmFsIHJ1bGVzIGZvciBj
cmVhdGluZyBhbmQgdmFsaWRhdGluZyBhIEpTT04gVG9rZW4iPgogICAgICA8dD5UbyBjcmVhdGUg
YSBKU09OIFRva2VuIG9uZSBNVVNUIGZvbGxvdyB0aGVzZSBzdGVwczogPGxpc3QKICAgICAgICAg
IHN0eWxlPSJudW1iZXJzIj4KICAgICAgICAgIDx0PkNyZWF0ZSBhIEpTT04gb2JqZWN0IGNvbnRh
aW5pbmcgdGhlIGRlc2lyZWQgY2xhaW1zLjwvdD4KCiAgICAgICAgICA8dD5UcmFuc2xhdGUgdGhl
IEpTT04gb2JqZWN0J3MgVW5pY29kZSBjb2RlIHBvaW50cyBpbnRvIFVURi04IGFzCiAgICAgICAg
ICBkZWZpbmVkIGluIDx4cmVmIHRhcmdldD0iUkZDMzYyOSI+UkZDIDM2Mjk8L3hyZWY+LjwvdD4K
CiAgICAgICAgICA8dD5iYXNlNjR1cmwgZW5jb2RlIHRoZSBKU09OIG9iamVjdCBhcyBkZWZpbmVk
IGluIHRoaXMKICAgICAgICAgIHNwZWNpZmljYXRpb24uIFRoaXMgY3JlYXRlcyB0aGUgSlNPTiBD
bGFpbSBTZWdtZW50LjwvdD4KCiAgICAgICAgICA8dD5DcmVhdGUgdGhlIEpTT04gQ3J5cHRvIHNl
Z21lbnQgYXMgZGVmaW5lZCBmb3IgdGhlIHBhcnRpY3VsYXIKICAgICAgICAgIGFsZ29yaXRobSBi
ZWluZyB1c2VkLjwvdD4KCiAgICAgICAgICA8dD5Db21iaW5lIHRoZSBKU09OIENyeXB0byBzZWdt
ZW50IGFuZCB0aGVuIHRoZSBKU09OIFRva2VuIHNlZ21lbnQsCiAgICAgICAgICBzZXBhcmF0ZWQg
YnkgYSBwZXJpb2QgY2hhcmFjdGVyIHRvIGNyZWF0ZSBhIEpTT04gVG9rZW4uPC90PgogICAgICAg
IDwvbGlzdD48L3Q+CgogICAgICA8dD5XaGVuIHZhbGlkYXRpbmcgYSBKU09OIFRva2VuIHRoZSBm
b2xsb3dpbmcgc3RlcHMgTVVTVCBiZSB0YWtlbi4gSWYKICAgICAgYW55IG9mIHRoZSBsaXN0ZWQg
c3RlcHMgZmFpbHMgdGhlbiB0aGUgdG9rZW4gTVVTVCBiZSByZWplY3RlZCBmb3IKICAgICAgcHJv
Y2Vzc2luZy48L3Q+CgogICAgICA8dD48bGlzdCBzdHlsZT0ibnVtYmVycyI+CiAgICAgICAgICA8
dD5UaGUgSlNPTiBUb2tlbiBNVVNUIGNvbnRhaW4gZXhhY3RseSBvbmUgcGVyaW9kIGNoYXJhY3Rl
ci48L3Q+CgogICAgICAgICAgPHQ+VGhlIEpTT04gVG9rZW4gTVVTVCBiZSBzcGxpdCBvbiB0aGUg
cGVyaW9kIGNoYXJhY3RlciByZXN1bHRpbmcgaW4KICAgICAgICAgIHR3byBub24tZW1wdHkgc2Vn
bWVudHMuPC90PgoKICAgICAgICAgIDx0PlRoZSBKU09OIENsYWltIFNlZ21lbnQgKHRoZSBzZWNv
bmQgb2YgdGhlIHR3bykgTVVTVCBiZQogICAgICAgICAgc3VjY2Vzc2Z1bGx5IGJhc2U2NHVybCBk
ZWNvZGVkIGZvbGxvd2luZyB0aGUgcmVzdHJpY3Rpb24gZ2l2ZW4gaW4KICAgICAgICAgIHRoaXMg
c3BlYyB0aGF0IG5vIHBhZGRpbmcgY2hhcmFjdGVycyBtYXkgaGF2ZSBiZWVuIHVzZWQuPC90PgoK
ICAgICAgICAgIDx0PlRoZSBEZWNvZGVkIEpTT04gQ2xhaW0gU2VnbWVudCBNVVNUIGJlIGNvbXBs
ZXRlbHkgdmFsaWQgSlNPTgogICAgICAgICAgc3ludGF4LjwvdD4KCiAgICAgICAgICA8dD5UaGUg
SlNPTiBDbGFpbSBTZWdtZW50IE1VU1QgYmUgdmFsaWRhdGVkIHRvIG9ubHkgaW5jbHVkZSBjbGFp
bXMKICAgICAgICAgIHdob3NlIHN5bnRheCBhbmQgc2VtYW50aWNzIGFyZSBib3RoIHVuZGVyc3Rv
b2QgYW5kIHN1cHBvcnRlZC48L3Q+CgogICAgICAgICAgPHQ+VGhlIEpTT04gQ3J5cHRvIFNlZ21l
bnQgTVVTVCBiZSBzdWNjZXNzZnVsbHkgdmFsaWRhdGVkIGFnYWluc3QKICAgICAgICAgIHRoZSBK
U09OIENsYWltIFNlZ21lbnQgaW4gdGhlIG1hbm5lciBkZWZpbmVkIGZvciB0aGUgdHlwZSBvZgog
ICAgICAgICAgYWxnb3JpdGhtIGJlaW5nIHVzZWQuPC90PgogICAgICAgIDwvbGlzdD48L3Q+Cgog
ICAgICA8dD5Qcm9jZXNzaW5nIGEgSlNPTiBUb2tlbiBpbmV2aXRhYmx5IHJlcXVpcmVzIGNvbXBh
cmluZyBrbm93biBzdHJpbmdzCiAgICAgIHRvIHZhbHVlcyBpbiB0aGUgdG9rZW4uIEZvciBleGFt
cGxlLCBpbiBjaGVja2luZyB3aGF0IHRoZSBhbGdvcml0aG0gaXMKICAgICAgKGFzc3VtaW5nIHRo
ZSBhbGdvcml0aG0gY2xhaW0gaXMgdXNlZCkgdGhlIFVuaWNvZGUgc3RyaW5nIGVuY29kaW5nCiAg
ICAgICdhbGdvcml0aG0nIHdpbGwgYmUgY2hlY2tlZCBhZ2FpbnN0IHRoZSBtZW1iZXIgbmFtZXMg
aW4gdGhlIERlY29kZWQgSlNPTgogICAgICBDbGFpbSBTZWdtZW50IHRvIHNlZSBpZiB0aGVyZSBp
cyBhIG1hdGNoaW5nIGNsYWltIG5hbWUuIEEgc2ltaWxhcgogICAgICBwcm9jZXNzIG9jY3VycyB3
aGVuIGRldGVybWluaW5nIGlmIHRoZSB2YWx1ZSBvZiB0aGUgYWxnb3JpdGhtIGNsYWltCiAgICAg
IHJlcHJlc2VudHMgYSBzdXBwb3J0ZWQgYWxnb3JpdGhtLiBDb21wYXJpbmcgVW5pY29kZSBzdHJp
bmdzIGhvd2V2ZXIgaGFzCiAgICAgIHNpZ25maWdhbnQgc2VjdXJpdHkgaW1wbGljYXRpb25zIHdo
aWNoIGFyZSBmdXJ0aGVyIGV4cGxvcmVkIGluIHRoZQogICAgICBzZWN1cml0eSBjb25zaWRlcmF0
aW9ucyBzZWN0aW9uLjwvdD4KCiAgICAgIDx0PkNvbXBhcmlzb25zIGJldHdlZW4gSlNPTiBzdHJp
bmdzIGFuZCBvdGhlciBVbmljb2RlIHN0cmluZ3MgTVVTVCBiZQogICAgICBwZXJmb3JtZWQgYXMg
c3BlY2lmaWVkIGJlbG93OjwvdD4KCiAgICAgIDx0PjxsaXN0IHN0eWxlPSJudW1iZXJzIj4KICAg
ICAgICAgIDx0PlJlbW92ZSBhbnkgSlNPTiBhcHBsaWVkIGVzY2FwaW5nIHRvIHByb2R1Y2UgYW4g
YXJyYXkgb2YgVW5pY29kZQogICAgICAgICAgY29kZSBwb2ludHM8L3Q+CgogICAgICAgICAgPHQ+
PHhyZWYgdGFyZ2V0PSJVU0ExNSI+VW5pY29kZSBOb3JtYWxpemF0aW9uPC94cmVmPiBNVVNUIE5P
VCBiZQogICAgICAgICAgYXBwbGllZCBhdCBhbnkgcG9pbnQgdG8gZWl0aGVyIHRoZSBKU09OIHN0
cmluZyBvciB0byB0aGUgc3RyaW5nIGl0CiAgICAgICAgICBpcyB0byBiZSBjb21wYXJlZCBhZ2Fp
bnN0LjwvdD4KCiAgICAgICAgICA8dD5Db21wYXJpc29ucyBiZXR3ZWVuIHRoZSB0d28gc3RyaW5n
cyBNVVNUIGJlIHBlcmZvcm1lZCBhcyBhCiAgICAgICAgICBVbmljb2RlIGNvZGUgcG9pbnQgdG8g
Y29kZSBwb2ludCBjb21wYXJpc29uLjwvdD4KICAgICAgICA8L2xpc3Q+PC90PgoKICAgICAgPHQ+
PC90PgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIHRpdGxlPSJQcm90ZWN0aW5nIGEgSlNP
TiBUb2tlbiB3aXRoIEhNQUMgU0hBLTI1NiI+CiAgICAgIDx0Pkhhc2ggYmFzZWQgTWVzc2FnZSBB
dXRoZW50aWNhdGlvbiBDb2RlcyAoSE1BQ3MpIGVuYWJsZSBvbmUgdG8gdXNlIGEKICAgICAgc2Vj
cmV0IHBsdXMgYSBjcnlwdG9ncmFwaGljIGhhc2ggZnVuY3Rpb24gdG8gZ2VuZXJhdGUgYSBNZXNz
YWdlCiAgICAgIEF1dGhlbnRpY2F0aW9uIENvZGUgKE1BQykgdGhhdCBjYW4gYmUgdXNlZCB0byBk
ZW1vbnN0cmF0ZSBub3Qgb25seSB0aGF0CiAgICAgIHRoZSBNQUMgbWF0Y2hlcyB0aGUgaGFzaGVk
IGNvbnRlbnQsIGluIHRoaXMgY2FzZSB0aGUgSlNPTiBDbGFpbSBTZWdtZW50LAogICAgICBidXQg
Y2FuIG9ubHkgZGVtb25zdHJhdGUgdGhhdCB3aG9tIGV2ZXIgZ2VuZXJhdGVkIHRoZSBNQUMgd2Fz
IGluCiAgICAgIHBvc3Nlc3Npb24gb2YgdGhlIHNlY3JldC4gVW5saWtlIGRpZ2l0YWwgc2lnbmF0
dXJlcywgSE1BQ3MgY2FuIG9ubHkKICAgICAgcHJvdmlkZSB2YWxpZGF0aW9uIGJ1dCBub3QgcmVw
dWRpYXRpb24gc2luY2UgYm90aCB0aGUgc2VuZGVyIGFuZAogICAgICByZWNlaXZlciBvZiB0aGUg
SE1BQyBtdXN0IGJlIGluIHBvc3Nlc3Npb24gb2YgdGhlIHNlY3JldCBhbmQgc28gZWl0aGVyCiAg
ICAgIGNvdWxkIGhhdmUgZ2VuZXJhdGVkIHRoZSBITUFDLjwvdD4KCiAgICAgIDx0PlRoZSBhbGdv
cml0aG0gZm9yIGltcGxlbWVudGluZyBhbmQgdmFsaWRhdGluZyBITUFDcyBpcyBwcm92aWRlZCBp
bgogICAgICA8eHJlZiB0YXJnZXQ9IlJGQzIxMDQiPlJGQyAyMTA0PC94cmVmPi4gQWx0aG91Z2gg
YW55IEhNQUMgY2FuIGJlIHVzZWQKICAgICAgd2l0aCBKU09OIFRva2VucyB0aGlzIHNlY3Rpb24g
ZGVmaW5lcyB0aGUgdXNlIG9mIHRoZSBTSEEtMjU2CiAgICAgIGNyeXB0b2dyYXBoaWMgaGFzaCBm
dW5jdGlvbiBhcyBkZWZpbmVkIGluIDx4cmVmIHRhcmdldD0iRklQUy4xODAtMyI+RklQUwogICAg
ICAxODAtMzwveHJlZj4uIFRoZSByZXNlcnZlZCBhbGdvcml0aG0gY2xhaW0gdmFsdWUgSG1hY1No
YTI1NiBpcyB1c2VkIGluCiAgICAgIHRoZSBKU09OIENsYWltIFNlZ21lbnQgdG8gaW5kaWNhdGUg
dGhhdCB0aGUgSlNPTiBDcnlwdG8gU2VnbWVudCBjb250YWlucwogICAgICBhIEhNQUMgU0hBLTI1
NiBITUFDLjwvdD4KCiAgICAgIDx0PlRoZSBITUFDIFNIQS0yNTYgTUFDIGlzIGdlbmVyYXRlZCBh
cyBmb2xsb3dzOiA8bGlzdCBzdHlsZT0ibnVtYmVycyI+CiAgICAgICAgICA8dD5UYWtlIHRoZSBK
U09OIENsYWltIFNlZ21lbnQgYW5kIGV4ZWN1dGUgdGhlIEhNQUMgU0hBLTI1NgogICAgICAgICAg
YWxnb3JpdGhtIG9uIGl0IHVzaW5nIHRoZSBkZXNpcmVkIGtleSB0byBwcm9kdWNlIGEgSE1BQy48
L3Q+CgogICAgICAgICAgPHQ+YmFzZTY0dXJsIGVuY29kZSB0aGUgSE1BQyBhcyBkZWZpbmVkIGlu
IHRoaXMgZG9jdW1lbnQuPC90PgogICAgICAgIDwvbGlzdD4gVGhlIG91dHB1dCBvZiB0aGUgcHJl
dmlvdXMgdGhlbiBiZWNvbWVzIHRoZSBKU09OIENyeXB0bwogICAgICBTZWdtZW50IGZvciB0aGF0
IEpTT04gVG9rZW4uPC90PgoKICAgICAgPHQ+VGhlIEhNQUMgU0hBLTI1NiBNQUMgb24gYSBKU09O
IHRva2VuIGlzIHZhbGlkYXRlZCBmb3IgYSBwYXJ0aWN1bGFyCiAgICAgIGtleSBhcyBkZWZpbmVk
IGJlbG93LiA8bGlzdCBzdHlsZT0ibnVtYmVycyI+CiAgICAgICAgICA8dD5UYWtlIHRoZSBKU09O
IENsYWltIFNlZ21lbnQgYW5kIGNhbGN1bGF0ZSBhIEhNQUMgU0hBLTI1NiBNQUMgb24KICAgICAg
ICAgIGl0IHVzaW5nIHRoZSBrZXkgdG8gYmUgdGVzdGVkLjwvdD4KCiAgICAgICAgICA8dD5iYXNl
NjR1cmwgZW5jb2RlIHRoZSBwcmV2aW91c2x5IGdlbmVyYXRlZCBITUFDIGFzIGRlZmluZWQgaW4g
dGhpcwogICAgICAgICAgZG9jdW1lbnQuPC90PgoKICAgICAgICAgIDx0PklmIHRoZSBKU09OIENy
eXB0byBTZWdtZW50IGFuZCB0aGUgcHJldmlvdXNseSBjYWxjdWxhdGVkIHZhbHVlCiAgICAgICAg
ICBleGFjdGx5IG1hdGNoIGluIGEgY2hhcmFjdGVyIGJ5IGNoYXJhY3RlciwgY2FzZSBzZW5zaXRp
dmUKICAgICAgICAgIGNvbXBhcmlzb24sIHRoZW4gb25lIGhhcyBjb25maXJtYXRpb24gdGhhdCB0
aGUga2V5IGJlaW5nIHRlc3RlZCB3YXMKICAgICAgICAgIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIEhN
QUMgb24gdGhlIEpTT04gVG9rZW4gYW5kIHRoYXQgdGhlIGNvbnRlbnRzIG9mCiAgICAgICAgICB0
aGUgSlNPTiBDbGFpbSBTZWdtZW50IGhhdmUgbm90IGJlIHRhbXBlcmVkIHdpdGguPC90PgogICAg
ICAgIDwvbGlzdD48L3Q+CiAgICA8L3NlY3Rpb24+CgogICAgPHNlY3Rpb24gdGl0bGU9IlByb3Rl
Y3RpbmcgYSBKU09OIFRva2VuIHdpdGggUlNBIGRpZ2l0YWwgc2lnbmF0dXJlcyI+CiAgICAgIDx0
PlRCRC4gSSBoYXZlIHNvbWUgaG9tZXdvcmsgdG8gZG8gYmVmb3JlIEkgd2lsbCBmZWVsIGNvbWZv
cnRhYmxlIHRoYXQgSQogICAgICBjYW4gcHJvcGVybHkgc3BlY2lmeSB0aGlzIGJlaGF2aW9yLjwv
dD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiB0aXRsZT0iUHJvdGVjdGluZyBhIEpTT04g
VG9rZW4gd2l0aCBFQ0RTQSIgYW5jaG9yPSJEZWZpbmluZ0VDRFNBIj4KICAgICAgPHQ+VGhlIEVs
bGlwdGljIEN1cnZlIERpZ2l0YWwgU2lnbmF0dXJlIEFsZ29yaXRobSAoRUNEU0EpIGlzIGRlZmlu
ZWQgYnkKICAgICAgPHhyZWYgdGFyZ2V0PSJGSVBTLjE4Ni0zIj5GSVBTIDE4Ni0zPC94cmVmPi4g
RUNEU0EgcHJvdmlkZXMgZm9yIHRoZSB1c2UKICAgICAgb2YgRWxsaXB0aWMgQ3VydmUgY3J5cHRv
Z3JhcGh5IHdoaWNoIGlzIGFibGUgdG8gcHJvdmlkZSBlcXVpdmFsZW50CiAgICAgIHNlY3VyaXR5
IHRvIFJTQSBjcnlwdG9ncmFwaHkgYnV0IHVzaW5nIHNob3J0ZXIga2V5IGxlbmd0aHMgYW5kIHdp
dGgKICAgICAgZ3JlYXRlciBwcm9jZXNzaW5nIHNwZWVkLiBUaGlzIG1lYW5zIHRoYXQgRUNEU0Eg
c2lnbmF0dXJlcyB3aWxsIGJlCiAgICAgIHN1YnN0YW50aWFsbHkgc21hbGxlciBpbiB0ZXJtcyBv
ZiBsZW5ndGggdGhhbiBlcXVpdmFsZW50bHkgc3Ryb25nIFJTQQogICAgICBEaWdpdGFsIFNpZ25h
dHVyZXMuPC90PgoKICAgICAgPHQ+VGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgdGhlIHVzZSBv
ZiBFQ0RTQSB3aXRoIHRoZSBQLTI1NiBjdXJ2ZSBhbmQKICAgICAgdGhlIFNIQS0yNTYgY3J5cHRv
Z3JhcGhpYyBoYXNoIGZ1bmN0aW9uLiBUaGUgUC0yNTYgY3VydmUgaXMgYWxzbyBkZWZpbmVkCiAg
ICAgIGluIEZJUFMgMTg2LTMuIFRoZSBhbGdvcml0aG0gY2xhaW0gdmFsdWUgRWNkc2FQMjU2U2hh
MjU2IGlzIHJldmVyc2VkIHRvCiAgICAgIGlkZW50aWZ5IGEgSlNPTiBUb2tlbiBzaWduZWQgd2l0
aCBFQ0RTQSBQLTI1NiBTSEEtMjU2LjwvdD4KCiAgICAgIDx0PkEgSlNPTiBUb2tlbiBpcyBzaWdu
ZWQgd2l0aCBhbiBFQ0RTQSBQLTI1NiBTSEEtMjU2IHNpZ25hdHVyZSBhcwogICAgICBmb2xsb3dz
OiA8bGlzdCBzdHlsZT0ibnVtYmVycyI+CiAgICAgICAgICA8dD5UYWtlIHRoZSBKU09OIENsYWlt
IFNlZ21lbnQgYW5kIGdlbmVyYXRlIGEgZGlnaXRhbCBzaWduYXR1cmUgZm9yCiAgICAgICAgICBp
dCB1c2luZyBFQ0RTQSBQLTI1NiBTSEEtMjU2IHdpdGggdGhlIGRlc2lyZWQgcHJpdmF0ZSBrZXku
IFRoZQogICAgICAgICAgb3V0cHV0IHdpbGwgYmUgdHdvIHVuc2lnbmVkIGludGVnZXJzIGNhbGxl
ZCwgYnkgY29udmVudGlvbiBSIGFuZAogICAgICAgICAgUy48L3Q+CgogICAgICAgICAgPHQ+VHVy
biBSIGFuZCBTIGludG8gYnl0ZSBhcnJheXMgaW4gYmlnIGVuZGlhbiBvcmRlci4gRWFjaCBhcnJh
eQogICAgICAgICAgd2lsbCBiZSAzMiBieXRlcyBsb25nPC90PgoKICAgICAgICAgIDx0PkNvbmNh
dGVuYXRlIHRoZSB0d28gYnl0ZSBhcnJheXMgaW4gdGhlIG9yZGVyIFIgYW5kIHRoZW4gUy48L3Q+
CgogICAgICAgICAgPHQ+YmFzZTY0dXJsIHRoZSA2NCBieXRlIGFycmF5IGFzIGRlZmluZWQgaW4g
dGhpcyBzcGVjaWZpY2F0aW9uLjwvdD4KICAgICAgICA8L2xpc3Q+IFRoZSBvdXRwdXQgaXMgdGhl
biB0aGUgSlNPTiBDcnlwdG8gU2VnbWVudCBmb3IgdGhlIEpTT04KICAgICAgVG9rZW4uPC90PgoK
ICAgICAgPHQ+QSBKU09OIFRva2VuIGlzIHRlc3RlZCB0byBzZWUgaWYgaXQgd2FzIHNpZ25lZCB3
aXRoIEVDRFNBIFAtMjU2CiAgICAgIFNIQS0yNTYgdXNpbmcgYSBnaXZlbiBwdWJsaWMga2V5IGFz
IGZvbGxvd3M6IDxsaXN0IHN0eWxlPSJudW1iZXJzIj4KICAgICAgICAgIDx0PlRha2UgdGhlIEpT
T04gQ3J5cHRvIFNlZ21lbnQgYW5kIGJhc2U2NHVybCBkZWNvZGUgaXQuIElmIGRlY29kaW5nCiAg
ICAgICAgICBmYWlscyB0aGVuIHRoZSB0ZXN0IE1VU1QgZmFpbC48L3Q+CgogICAgICAgICAgPHQ+
VGhlIG91dHB1dCBvZiB0aGUgYmFzZTY0dXJsIGRlY29kaW5nIE1VU1QgYmUgYSA2NCBieXRlIGFy
cmF5LjwvdD4KCiAgICAgICAgICA8dD5TcGxpdCB0aGUgNjQgYnl0ZSBhcnJheSBpbnRvIHR3byAz
MiBieXRlIGFycmF5cy4gVGhlIGZpcnN0IGFycmF5CiAgICAgICAgICB3aWxsIGJlIFIgYW5kIHRo
ZSBzZWNvbmQgUy4gUGxlYXNlIHJlbWVtYmVyIHRoYXQgdGhlIGJ5dGUgYXJyYXlzIGFyZQogICAg
ICAgICAgaW4gYmlnIGVuZGlhbiBieXRlIG9yZGVyLCBwbGVhc2UgY2hlY2sgd2l0aCB0aGUgRUNE
U0EgdmFsaWRhdG9yIGluCiAgICAgICAgICB1c2UgdG8gc2VlIHdoYXQgYnl0ZSBvcmRlciBpdCBy
ZXF1aXJlZC48L3Q+CgogICAgICAgICAgPHQ+U3VibWl0IHRoZSBKU09OIENsYWltIFNlZ21lbnQs
IFIsIFMgYW5kIHRoZSBwdWJsaWMga2V5IHRoYXQgaXMKICAgICAgICAgIGJlaW5nIHRlc3RlZCB0
byB0aGUgRUNEU0EgUC0yNTYgU0hBLTI1NiB2YWxpZGF0b3IuPC90PgogICAgICAgIDwvbGlzdD4g
VGhlIEVDRFNBIHZhbGlkYXRvciB3aWxsIHRoZW4gc3BlY2lmeSBpZiB0aGUgZGlnaXRhbCBzaWdu
YXR1cmUKICAgICAgaXMgdmFsaWQgZ2l2ZW4gdGhlIGlucHV0cy4gUGxlYXNlIG5vdGUgdGhhdCBF
Q0RTQSBkaWdpdGFsIHNpZ25hdHVyZQogICAgICBjb250YWluIGEgdmFsdWUgcmVmZXJyZWQgdG8g
YXMgSyB3aGljaCBpcyBhIHJhbmRvbSBudW1iZXIgZ2VuZXJhdGVkIGZvcgogICAgICBlYWNoIGRp
Z2l0YWwgc2lnbmF0dXJlIGluc3RhbmNlLiBUaGlzIG1lYW5zIHRoYXQgdHdvIEVDRFNBIGRpZ2l0
YWwKICAgICAgc2lnbmF0dXJlcyB1c2luZyBleGFjdGx5IHRoZSBzYW1lIGlucHV0IHBhcmFtZXRl
cnMgd2lsbCBzdGlsbCBvdXRwdXQKICAgICAgZGlmZmVyZW50IHNpZ25hdHVyZXMgYmVjYXVzZSB0
aGVpciBLIHZhbHVlcyB3aWxsIGJlIGRpZmZlcmVudC4gVGhlCiAgICAgIGNvbnNlcXVlbmNlIG9m
IEsgaXMgdGhhdCBvbmUgdmFsaWRhdGVzIGEgRUNEU0Egc2lnbmF0dXJlIGJ5IHN1Ym1pdHRpbmcK
ICAgICAgdGhlIHByZXZpb3VzbHkgc3BlY2lmaWVkIGlucHV0cyB0byBhIEVDRFNBIHZhbGlkYXRv
ci4gT25lIGNhbm5vdCwgYXMKICAgICAgd2l0aCBITUFDcywgY2hlY2sgdGhlIHNpZ25hdHVyZSBk
aXJlY3RseSBvbmVzZWxmLjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNob3I9
IklBTkEiIHRpdGxlPSJJQU5BIENvbnNpZGVyYXRpb25zIj4KICAgICAgPHQ+VGhpcyBzcGVjaWZp
Y2F0aW9uIGNhbGxzIGZvcjogPGxpc3Qgc3R5bGU9InN5bWJvbHMiPgogICAgICAgICAgPHQ+QSBu
ZXcgSUFOQSByZWdpc3RyeSBlbnRpdGxlZCAiSlNPTiBUb2tlbiBDbGFpbXMiIGZvciBjbGFpbSBu
YW1lcwogICAgICAgICAgdXNlZCBpbiBhIGRlY29kZWQgSlNPTiBDbGFpbSBTZWdtZW50LiBJbmNs
dXNpb24gaW4gdGhlIHJlZ2lzdHJ5IGlzCiAgICAgICAgICBSRkMgUmVxdWlyZWQgaW4gdGhlIDx4
cmVmIHRhcmdldD0iUkZDNTIyNiI+UkZDIDUyMjY8L3hyZWY+IHNlbnNlLgogICAgICAgICAgVGhl
IHJlZ2lzdHJ5IHdpbGwganVzdCByZWNvcmQgdGhlIGNsYWltIG5hbWUgYW5kIGEgcG9pbnRlciB0
byB0aGUKICAgICAgICAgIFJGQyB0aGF0IGRlZmluZXMgaXQuIFRoaXMgc3BlY2lmaWNhdGlvbiBk
ZWZpbmVzIGluY2x1c2lvbiBvZiB0aGUKICAgICAgICAgIGNsYWltIG5hbWVzIGRlZmluZWQgaW4g
PHhyZWYgdGFyZ2V0PSJDbGFpbVRhYmxlIj48L3hyZWY+LjwvdD4KCiAgICAgICAgICA8dD5BIG5l
dyBJQU5BIHJlZ2lzdHJ5IGVudGl0bGVkICJKU09OIFRva2VuIEFsZ29yaXRobSBWYWx1ZXMiIGZv
cgogICAgICAgICAgdmFsdWVzIHVzZWQgd2l0aCB0aGUgYWxnb3JpdGhtIGNsYWltIHVzZWQgaW4g
YSBkZWNvZGVkIEpTT04gQ2xhaW0KICAgICAgICAgIFNlZ21lbnQuIEluY2x1c2lvbiBpbiB0aGUg
cmVnaXN0cnkgaXMgUkZDIFJlcXVpcmVkIGluIHRoZSA8eHJlZgogICAgICAgICAgdGFyZ2V0PSJS
RkM1MjI2Ij5SRkMgNTIyNjwveHJlZj4gc2Vuc2UuIFRoZSByZWdpc3RyeSB3aWxsIGp1c3QKICAg
ICAgICAgIHJlY29yZCB0aGUgYWxnb3JpdGhtIHZhbHVlIGFuZCBhIHBvaW50ZXIgdG8gdGhlIFJG
QyB0aGF0IGRlZmluZXMgaXQuCiAgICAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBp
bmNsdXNpb24gb2YgdGhlIGFsZ29yaXRobSB2YWx1ZXMKICAgICAgICAgIEhtYXhTaGEyNTYgYW5k
IEVjZHNhUDI1NlNoYTI1Ni48L3Q+CiAgICAgICAgPC9saXN0PjwvdD4KCiAgICAgIDx0PkVESVRP
UidTIE5PVEU6IE5lZWQgdG8gaW5jbHVkZSBhbiBpZGVudGlmaWVyIGZvciBSU0EuIEFsc28gSQog
ICAgICBleHBsaWNpdGx5IGRpZG4ndCBhbGxvdyBmb3IgYWQtaG9jIHJlZ2lzdHJhdGlvbnMgYmVj
YXVzZSBJIGZpZ3VyZSB0aGF0CiAgICAgIElBTkEgaGFzIGVub3VnaCB0byBkbyBidXQgaXQgd291
bGQgYmUgdXNlZnVsIHRvIGhhdmUgYSBjZW50cmFsIHJlZ2lzdHJ5CiAgICAgIG9mIHZhbHVlcywg
ZXZlbiBhZC1ob2Mgb25lcy4gV2Ugc2hvdWxkIGNoZWNrIHdpdGggSUFOQSB0byBzZWUgd2hhdCB0
aGV5CiAgICAgIHRoaW5rLjwvdD4KICAgIDwvc2VjdGlvbj4KCiAgICA8c2VjdGlvbiBhbmNob3I9
IlNlY3VyaXR5IiB0aXRsZT0iU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMiPgogICAgICA8dD5FRElU
T1InUyBOT1RFOiBMb3RzIG9mIHdvcmsgdG8gZG8gaGVyZS4gSSBuZWVkIHRvIHJlbWVtYmVyIHRv
IGxvb2sKICAgICAgaW50byBhbnkgaXNzdWVzIHJlbGF0aW5nIHRvIHNlY3VyaXR5IGFuZCBKU09O
IHBhcnNpbmcuIE9uZSB3b25kZXJzIGp1c3QKICAgICAgaG93IHNlY3VyZSBtb3N0IEpTT04gcGFy
c2luZyBsaWJyYXJpZXMgYXJlLiBXZXJlIHRoZXkgZXZlciBoYXJkZW5lZCBmb3IKICAgICAgc2Vj
dXJpdHkgc2NlbmFyaW9zPyBJZiBub3QsIHdoYXQga2luZCBvZiBob2xlcyBkb2VzIHRoYXQgb3Bl
biB1cD8gQWxzbwogICAgICBuZWVkIHRvIHdhbGsgdGhyb3VnaCB0aGUgSlNPTiBzdGFuZGFyZCBh
bmQgc2VlIHdoYXQga2luZCBvZiBpc3N1ZXMgd2UKICAgICAgaGF2ZSBlc3BlY2lhbGx5IGFyb3Vu
ZCBjb21wYXJpc29uIG9mIG5hbWVzLCBhbHJlYWR5IGZvdW5kIGFuIGlzc3VlIHdpdGgKICAgICAg
ZXNjYXBpbmcgc3RyaW5ncyAobmVlZGVkIHRvIGRlZmluZSB0aGF0IGNvbXBhcmlzb25zIG9mIHN0
cmluZ3MgbXVzdAogICAgICBvY2N1ciBhZnRlciB0aGV5IGFyZSB1bmVzY2FwZWQpLiBOZWVkIHRv
IGFsc28gcHV0IGluIHRleHQgYWJvdXQ6CiAgICAgIEltcG9ydGFuY2Ugb2Yga2VlcGluZyBzZWNy
ZXRzIHNlY3JldC4gUm90YXRpbmcga2V5cy4gU3RyZW5ndGhzIGFuZAogICAgICB3ZWFrbmVzc2Vz
IG9mIHRoZSBkaWZmZXJlbnQgYWxnb3JpdGhtcy4gQ2FzZSBzZW5zaXRpdml0eSBhbmQgbW9yZQog
ICAgICBnZW5lcmFsbHkgVW5pY29kZSBjb21wYXJpc29uIGlzc3VlcyB0aGF0IGNhbiBjYXVzZSBz
ZWN1cml0eSBob2xlcywKICAgICAgZXNwZWNpYWxseSBpbiBjbGFpbSBuYW1lcyBhbmQgZXhwbGFp
biB3aHkgVW5pY29kZSBOb3JtYWxpemF0aW9uIGlzIHN1Y2gKICAgICAgYSBwcm9ibGVtIGZvciBh
c3NlcnRpb25zLjwvdD4KCiAgICAgIDx0Pk5lZWQgdG8gcHV0IGluIHRleHQgYWJvdXQgd2h5IHN0
cmljdCBKU09OIHZhbGlkYXRpb24gaXMgbmVjZXNzYXJ5LgogICAgICBCYXNpY2FsbHkgdGhhdCBp
ZiBtYWxmb3JtZWQgSlNPTiBpcyByZWNlaXZlZCB0aGVuIHRoZSBpbnRlbnQgb2YgdGhlCiAgICAg
IHNlbmRlciBpcyBpbXBvc3NpYmxlIHRvIHJlbGlhYmx5IGRpc2Nlcm5lLiBXaGlsZSBpbiBub24t
c2VjdXJpdHkKICAgICAgY29udGV4dHMgaXQncyBvLmsuIHRvIGJlIGdlbmVyb3VzIGluIHdoYXQg
b25lIGFjY2VwdHMgaW4gc2VjdXJpdHkKICAgICAgY29udGV4dHMgdGhpcyBjYW4gbGVhZCB0byBz
ZXJpb3VzIHNlY3VyaXR5IGhvbGVzLiBGb3IgZXhhbXBsZSwgbWFsZm9ybWVkCiAgICAgIEpTT04g
bWlnaHQgaW5kaWNhdGUgdGhhdCBzb21lb25lIGhhcyBtYW5hZ2VkIHRvIGZpbmQgYSBzZWN1cml0
eSBob2xlIGluCiAgICAgIHRoZSBpc3N1ZXIncyBjb2RlIGFuZCBpcyBsZXZlcmFnaW5nIGl0IHRv
IGdldCB0aGUgaXNzdWVyIHRvIGlzc3VlICdiYWQnCiAgICAgIHRva2VucyB3aG9zZSBjb250ZW50
IHRoZSBhdHRhY2sgY2FuIGNvbnRyb2wuPC90PgoKICAgICAgPHNlY3Rpb24gdGl0bGU9IlVuaWNv
ZGUgY29tcGFyaXNvbiBzZWN1cml0eSBpc3N1ZXMiPgogICAgICAgIDx0PjwvdD4KICAgICAgPC9z
ZWN0aW9uPgogICAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hvcj0iQWNrbm93bGVkZ2Vt
ZW50cyIgdGl0bGU9IkFja25vd2xlZGdlbWVudHMiPgogICAgICA8dD48L3Q+CiAgICA8L3NlY3Rp
b24+CgogICAgPHNlY3Rpb24gdGl0bGU9IkFwcGVuZGl4IC0gTm9uLU5vcm1hdGl2ZSAtIFJlbGF0
aW9uc2hpcCBvZiBKU09OIFRva2VucyB0byBTQU1MIEFzc2VydGlvbnMiPgogICAgICA8dD48eHJl
ZiB0YXJnZXQ9Ik9BU0lTLnNhbWwtY29yZS0yLjAtb3MiPlNBTUwgMi4wPC94cmVmPiBwcm92aWRl
cyBhCiAgICAgIHN0YW5kYXJkIGZvciBjcmVhdGluZyBhc3NlcnRpb25zIHdpdGggbXVjaCBncmVh
dGVyIGV4cHJlc3Npdml0eSBhbmQKICAgICAgc2VjdXJpdHkgb3B0aW9ucyB0aGFuIHN1cHBvcnRl
ZCBieSBKU09OIFRva2Vucy4gSG93ZXZlciB0aGUgY29zdCBvZiB0aGlzCiAgICAgIGZsZXhpYmls
aXR5IGFuZCBleHByZXNzaXZlbmVzcyBpcyBzaXplLiBJbiBhZGRpdGlvbiBTQU1MJ3MgdXNlIG9m
IDx4cmVmCiAgICAgIHRhcmdldD0iVzNDLkNSLXhtbDExLTIwMDIxMDE1Ij5YTUw8L3hyZWY+IGFu
ZCA8eHJlZiB0YXJnZXQ9IlJGQzMyNzUiPlhNTAogICAgICBEU0lHPC94cmVmPiBvbmx5IGNvbnRy
aWJ1dGVzIHRvIHRoZSBzaXplIG9mIFNBTUwgYXNzZXJ0aW9ucy48L3Q+CgogICAgICA8dD5KU09O
IFRva2VucyBhcmUgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIHNpbXBsaWZpZWQgYXNzZXJ0aW9uIGZv
cm1hdAogICAgICB0aGF0IGlzIHNtYWxsIGVub3VnaCB0byBmaXQgaW50byBIVFRQIGhlYWRlcnMg
YW5kIHF1ZXJ5IGFyZ3VtZW50cyBpbgogICAgICBVUklzLiBJdCBkb2VzIHRoaXMgYnkgc3VwcG9y
dGluZyBhIG11Y2ggc2ltcGxlciBhc3NlcnRpb24gbW9kZWwgdGhhbgogICAgICBTQU1MIGFuZCB1
c2luZyB0aGUgPHhyZWYgdGFyZ2V0PSJSRkM0NjI3Ij5KU09OPC94cmVmPiBvYmplY3QgZW5jb2Rp
bmcKICAgICAgc3ludGF4LiBJdCBhbHNvIHN1cHBvcnRzIHNlY3VyaW5nIGFzc2VydGlvbnMgdXNp
bmcgSGFzaC1iYXNlZCBNZXNzYWdlCiAgICAgIEF1dGhlbnRpY2F0aW9uIENvZGVzIChITUFDcykg
YW5kIGRpZ2l0YWwgc2lnbmF0dXJlcyB1c2luZyBhIHNtYWxsZXIgKGFuZAogICAgICBsZXNzIGZs
ZXhpYmxlKSBmb3JtYXQgdGhhbiBYTUwgRFNJRy48L3Q+CgogICAgICA8dD5UaGVyZWZvcmUgd2hp
bGUgSlNPTiBUb2tlbnMgY2FuIGRvIHNvbWUgb2YgdGhlIHRoaW5ncyBTQU1MIGFzc2VydGlvbnMK
ICAgICAgZG8sIEpTT04gVG9rZW5zIGFyZSBub3QgaW50ZW5kZWQgYXMgYSBmdWxsIHJlcGxhY2Vt
ZW50IGZvciBTQU1MLiBCdXQKICAgICAgcmF0aGVyIGEgY29tcHJvbWlzZSBhc3NlcnRpb24gZm9y
bWF0IHRvIGJlIHVzZWQgd2hlbiBzcGFjZSBpcyBhdCBhCiAgICAgIHByZW1pdW0uPC90PgogICAg
PC9zZWN0aW9uPgogIDwvbWlkZGxlPgoKICA8YmFjaz4KICAgIDxyZWZlcmVuY2VzIHRpdGxlPSJO
b3JtYXRpdmUgUmVmZXJlbmNlcyI+CiAgICAgICZSRkMyMTA0OwoKICAgICAgJnJmYzIxMTk7Cgog
ICAgICAmUkZDMzMzOTsKCiAgICAgICZSRkMzNjI5OwoKICAgICAgJlJGQzM5ODY7CgogICAgICAm
UkZDNDYyNzsKCiAgICAgICZSRkM0NjQ4OwoKICAgICAgJlJGQzUyMjY7CgogICAgICA8cmVmZXJl
bmNlIGFuY2hvcj0iRklQUy4xODAtMyI+CiAgICAgICAgPGZyb250PgogICAgICAgICAgPHRpdGxl
PlNlY3VyZSBIYXNoIFN0YW5kYXJkIChTSFMpPC90aXRsZT4KCiAgICAgICAgICA8YXV0aG9yPgog
ICAgICAgICAgICA8b3JnYW5pemF0aW9uPk5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMg
YW5kCiAgICAgICAgICAgIFRlY2hub2xvZ3k8L29yZ2FuaXphdGlvbj4KICAgICAgICAgIDwvYXV0
aG9yPgoKICAgICAgICAgIDxkYXRlIG1vbnRoPSJPY3RvYmVyIiB5ZWFyPSIyMDA4IiAvPgogICAg
ICAgIDwvZnJvbnQ+CgogICAgICAgIDxzZXJpZXNJbmZvIG5hbWU9IkZJUFMiIHZhbHVlPSJQVUIg
MTgwLTMiIC8+CiAgICAgIDwvcmVmZXJlbmNlPgoKICAgICAgPHJlZmVyZW5jZSBhbmNob3I9IkZJ
UFMuMTg2LTMiPgogICAgICAgIDxmcm9udD4KICAgICAgICAgIDx0aXRsZT5EaWdpdGFsIFNpZ25h
dHVyZSBTdGFuZGFyZCAoRFNTKTwvdGl0bGU+CgogICAgICAgICAgPGF1dGhvcj4KICAgICAgICAg
ICAgPG9yZ2FuaXphdGlvbj5OYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZAogICAg
ICAgICAgICBUZWNobm9sb2d5PC9vcmdhbml6YXRpb24+CiAgICAgICAgICA8L2F1dGhvcj4KCiAg
ICAgICAgICA8ZGF0ZSBtb250aD0iSnVuZSIgeWVhcj0iMjAwOSIgLz4KICAgICAgICA8L2Zyb250
PgoKICAgICAgICA8c2VyaWVzSW5mbyBuYW1lPSJGSVBTIiB2YWx1ZT0iUFVCIDE4Ni0zIiAvPgog
ICAgICA8L3JlZmVyZW5jZT4KCiAgICAgIDxyZWZlcmVuY2UgYW5jaG9yPSJVU0ExNSI+CiAgICAg
ICAgPGZyb250PgogICAgICAgICAgPHRpdGxlPlVuaWNvZGUgTm9ybWFsaXphdGlvbiBGb3Jtczwv
dGl0bGU+CgogICAgICAgICAgPGF1dGhvciBmdWxsbmFtZT0iTWFyayBEYXZpcyIgaW5pdGlhbHM9
Ik0uIiBzdXJuYW1lPSJEYXZpcyI+CiAgICAgICAgICAgIDxhZGRyZXNzPgogICAgICAgICAgICAg
IDxlbWFpbD5tYXJrZGF2aXNAZ29vZ2xlLmNvbTwvZW1haWw+CiAgICAgICAgICAgIDwvYWRkcmVz
cz4KICAgICAgICAgIDwvYXV0aG9yPgoKICAgICAgICAgIDxhdXRob3IgZnVsbG5hbWU9IktlbiBX
aGlzdGxlciIgaW5pdGlhbHM9IksuIiBzdXJuYW1lPSJXaGlzdGxlciI+CiAgICAgICAgICAgIDxh
ZGRyZXNzPgogICAgICAgICAgICAgIDxlbWFpbD5rZW5AdW5pY29kZS5vcmc8L2VtYWlsPgogICAg
ICAgICAgICA8L2FkZHJlc3M+CiAgICAgICAgICA8L2F1dGhvcj4KCiAgICAgICAgICA8YXV0aG9y
IGZ1bGxuYW1lPSJNYXJ0aW4gRCZVdW1sO3JzdCIgaW5pdGlhbHM9Ik0uIgogICAgICAgICAgICAg
ICAgICBzdXJuYW1lPSJEJlV1bWw7cnN0Ij48L2F1dGhvcj4KCiAgICAgICAgICA8ZGF0ZSBkYXk9
IjAzIiBtb250aD0iMDkiIHllYXI9IjIwMDkiIC8+CiAgICAgICAgPC9mcm9udD4KCiAgICAgICAg
PHNlcmllc0luZm8gbmFtZT0iVW5pY29kZSBTdGFuZGFyZCBBbm5leCIgdmFsdWU9IjE1IiAvPgog
ICAgICA8L3JlZmVyZW5jZT4KICAgIDwvcmVmZXJlbmNlcz4KCiAgICA8cmVmZXJlbmNlcyB0aXRs
ZT0iSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyI+CiAgICAgICZPQVNJUy5zYW1sLWNvcmUtMi4wLW9z
OwoKICAgICAgJlczQy5DUi14bWwxMS0yMDAyMTAxNTsKCiAgICAgICZSRkMzMjc1OwoKICAgICAg
JlJGQzQxMjI7CiAgICA8L3JlZmVyZW5jZXM+CiAgPC9iYWNrPgo8L3JmYz4K

--_005_7C01E631FF4B654FA1E783F1C0265F8C62D263BBTK5EX14MBXC111r_--

From tonynad@microsoft.com  Mon Aug 30 15:53:31 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21873A67F9 for ; Mon, 30 Aug 2010 15:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.617
X-Spam-Level: 
X-Spam-Status: No, score=-8.617 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_50=0.001, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ANbHrea2ahP for ; Mon, 30 Aug 2010 15:53:24 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 6C5363A689E for ; Mon, 30 Aug 2010 15:53:24 -0700 (PDT)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Aug 2010 15:53:43 -0700
Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.183]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0218.010; Mon, 30 Aug 2010 15:53:43 -0700
From: Anthony Nadalin 
To: "Zeltsan, Zachary (Zachary)" , "Chuck Mortimore" , Eran Hammer-Lahav , Brian Campbell 
Thread-Topic: [OAUTH-WG] more than one assertion?
Thread-Index: AQHLN/nn+pWzYl6T5UKTKi41Ej4aj5LakquAgAC9twCAAANjgIADN/wAgAwa+aCAADssMIAP1a0Q
Date: Mon, 30 Aug 2010 22:53:43 +0000
Message-ID: <1990A18DEA6E97429CFD1B4D2C5DA7E7073E88@TK5EX14MBXC101.redmond.corp.microsoft.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <5710F82C0E73B04FA559560098BF95B124FA54AB20@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
In-Reply-To: <5710F82C0E73B04FA559560098BF95B124FA54AB20@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.123.12]
Content-Type: multipart/alternative; boundary="_000_1990A18DEA6E97429CFD1B4D2C5DA7E7073E88TK5EX14MBXC101red_"
MIME-Version: 1.0
Cc: oauth 
Subject: Re: [OAUTH-WG] more than one assertion?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 22:53:32 -0000

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

The sets of use case that we have on various ongoing projects just have a s=
ingle subject (note that the single subject will be known by different iden=
tifiers since there are jurisdictional requirements for this).

From: Zeltsan, Zachary (Zachary) [mailto:zachary.zeltsan@alcatel-lucent.com=
]
Sent: Friday, August 20, 2010 2:11 PM
To: Anthony Nadalin; Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] more than one assertion?

This is a convincing use in support of the multiple assertions.
My understanding is that in the use case the two assertions provide the dif=
ferent statements of the different issuers regarding the same subject (the =
person seeking a parking permit). Is there a use case that requires multipl=
e assertions regarding different subjects?

Zachary

________________________________
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A=
nthony Nadalin
Sent: Friday, August 20, 2010 2:19 PM
To: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

So the UK Government Gateway project is a concrete use case. The use case f=
or the UK government is that the government has many assertion providers; t=
his is due to both legal and historical reasons. The first assertion provid=
er is UK Department of Works and Pension (DWP), the second one is Departmen=
t of Motor Vehicles and the third is the Department of Revenue (and so on .=
..). A citizen may need and assertion from each one of these government dep=
artments attesting to various things. A person wants a parking permit, so D=
WP and Department of Motor Vehicles are involved; DWP is the authoritative =
source of address and DMV is the authoritative source of vehicle informatio=
n. So in order to obtain a parking permit, I have to live on the street tha=
t I obtain the parking permit for and I also need to own the vehicle for wh=
ich I'm obtaining the parking permit. So these 2 assertions under different=
 subject identifiers would have to be submitted to obtain the parking permi=
t. So there has to be a way to carry the 2 assertions to obtain the token t=
o get the parking permit.


From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of C=
huck Mortimore
Sent: Thursday, August 12, 2010 10:24 AM
To: Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

Personally, I'd first like to see more concrete use-cases of how multiple a=
ssertions are going to be used in practice.   Tony alluded to some abstract=
 use-cases, but fuller descriptions would probably help everyone out.

-cmort


On 8/10/10 9:15 AM, "Eran Hammer-Lahav"  wrote:
WFM.

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Tuesday, August 10, 2010 9:03 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] more than one assertion?
>
> To be honest, I somehow overlooked that particular text - my mistake and
> apologies. Reading it again, it probably does preclude parameters from
> repeating, however, I can see some room for varied interpretations as to =
if
> that's a strong normative requirement or a looser suggestion about an err=
or
> code that could be used in that circumstance.
>
> Perhaps it could be made more clear by adding some wording about it to th=
e
> end of the first part of sections 3&4 where it says: "Parameters sent wit=
hout
> a value MUST be treated as if they were omitted from the request.  The
> authorization server SHOULD ignore unrecognized request parameters."?
>
> That said, does it make sense to relax the ban on repeating parameters in
> some situations, like for the assertion parameter, to facilitate
> easy encoding of multiple assertions?   Anthony (Tony?) Nadalin
> suggested that multiple assertions might be a common use case and I think
> allowing for that via repeating assertion parameters is a cleaner and mor=
e
> reusable way to do it.
>
> The text at the bottom of section for could say something like:
>
> "Parameters sent without a value MUST be treated as if they were omitted
> from the request.  The authorization server SHOULD ignore unrecognized
> request parameters.  Parameters MUST NOT repeat unless otherwise noted
> in the parameter definition."
>
> Then in 4.1.3. the assertion parameter could be something like this:
>
>   "assertion
>          REQUIRED.  The assertion(s).  This parameter MAY be repeated in =
the
> request,  if more than one
>           assertion is needed for the access grant"
>
>
> Obviously Eran could improve on the actual text but hopefully that gets t=
he
> concept across?
>
>
>
> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
>  wrote:
> > Do we need to clarify 4.3.1 "repeats a parameter" description for
> "invalid_request" error code does not preclude parameters from repeating?
> I'm not sure.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Brian Campbell
> >> Sent: Monday, August 09, 2010 12:34 PM
> >> To: oauth
> >> Subject: [OAUTH-WG] more than one assertion?
> >>
> >> The question of allowing for multiple assertions in the SAML profile
> >> came up recently.  See http://www.ietf.org/mail-
> >> archive/web/oauth/current/msg04068.html and several subsequent
> >> messages in the thread.
> >>
> >> I pushed back on the idea at first due to added complexity.  There
> >> are a number of things that need to be addressed that aren't present
> >> in the single assertion case.   One of the sticker ones, to me, was
> >> how to encode the assertions into the request.   A SAML 
> >> element is a nice container for multiple assertions but using it in
> >> this context seemed awkward at best.  A new schema could be defined
> >> or a special deliminator character could be used but that seems excess=
ive
> and kludgy respectively.
> >>
> >> What about pushing it up into the HTTP layer and allowing for
> >> multiple occurrences of the assertion=3DXXX parameter in the POST body=
?
> >> I don't see anything in core OAuth that would necessarily preclude doi=
ng
> this.
> >>  It seems cleaner and more lightweight than some of the other options.
> >>  And perhaps it could be a more general (not just SAML) method of
> >> sending multiple assertions in a single assertion grant type request?
> >>
> >> It'd look something like this:
> >>
> >>   POST /token.oauth2 HTTP/1.1
> >>   Host: authz.example.net
> >>   Content-Type: application/x-www-form-urlencoded
> >>
> >>    grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%2Fa
> sse
> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st
> >> assertion...]&assertion=3D
> >>    [...2nd assertion...]&assertion=3D[...3nd assertion...]
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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






Re: [OAUTH-WG] more than one assertion?






The sets of use case that=
 we have on various ongoing projects just have a single subject (note that =
the single subject will be known by different identifiers
 since there are jurisdictional requirements for this).

 <=
/p>





From: Zeltsan,=
 Zachary (Zachary) [mailto:zachary.zeltsan@alcatel-lucent.com]


Sent: Friday, August 20, 2010 2:11 PM

To: Anthony Nadalin; Chuck Mortimore; Eran Hammer-Lahav; Brian Campb=
ell

Cc: oauth

Subject: RE: [OAUTH-WG] more than one assertion?





 


This is a convincing use in su=
pport of the multiple assertions.



My understanding is that in th=
e use case the two assertions provide the different statements of the diffe=
rent issuers regarding the same subject (the person seeking
 a parking permit). Is there a use case that requires multiple assertions r=
egarding different subjects?


 


Zachary


 










From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Anthony Nadalin

Sent: Friday, August 20, 2010 2:19 PM

To: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] more than one assertion?



 


So the UK Government Gate=
way project is a concrete use case. The use case for the UK government is t=
hat the government has many assertion providers; this is
 due to both legal and historical reasons. The first assertion provider is =
UK Department of Works and Pension (DWP), the second one is Department of M=
otor Vehicles and the third is the Department of Revenue (and so on …=
). A citizen may need and assertion from
 each one of these government departments attesting to various things. A pe=
rson wants a parking permit, so DWP and Department of Motor Vehicles are in=
volved; DWP is the authoritative source of address and DMV is the authorita=
tive source of vehicle information.
 So in order to obtain a parking permit, I have to live on the street that =
I obtain the parking permit for and I also need to own the vehicle for whic=
h I’m obtaining the parking permit. So these 2 assertions under diffe=
rent subject identifiers would have to
 be submitted to obtain the parking permit. So there has to be a way to car=
ry the 2 assertions to obtain the token to get the parking permit.


 <=
/p>

 <=
/p>





From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Chuck Mortimore

Sent: Thursday, August 12, 2010 10:24 AM

To: Eran Hammer-Lahav; Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] more than one assertion?





 


Persona=
lly, I’d first like to see more concrete use-cases of how multiple as=
sertions are going to be used in practice.   Tony alluded to some
 abstract use-cases, but fuller descriptions would probably help everyone o=
ut.



-cmort





On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:


WFM.


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

> From: Brian Campbell [ma=
ilto:bcampbell@pingidentity.com]

> Sent: Tuesday, August 10, 2010 9:03 AM

> To: Eran Hammer-Lahav

> Cc: oauth

> Subject: Re: [OAUTH-WG] more than one assertion?

>

> To be honest, I somehow overlooked that particular text - my mistake a=
nd

> apologies. Reading it again, it probably does preclude parameters from=


> repeating, however, I can see some room for varied interpretations as =
to if

> that's a strong normative requirement or a looser suggestion about an =
error

> code that could be used in that circumstance.

>

> Perhaps it could be made more clear by adding some wording about it to=
 the

> end of the first part of sections 3&4 where it says: "Paramet=
ers sent without

> a value MUST be treated as if they were omitted from the request. &nbs=
p;The

> authorization server SHOULD ignore unrecognized request parameters.&qu=
ot;?

>

> That said, does it make sense to relax the ban on repeating parameters=
 in

> some situations, like for the assertion parameter, to facilitate

> easy encoding of multiple assertions?   Anthony (Tony?) Nada=
lin

> suggested that multiple assertions might be a common use case and I th=
ink

> allowing for that via repeating assertion parameters is a cleaner and =
more

> reusable way to do it.

>

> The text at the bottom of section for could say something like:

>

> "Parameters sent without a value MUST be treated as if they were =
omitted

> from the request.  The authorization server SHOULD ignore unrecog=
nized

> request parameters.  Parameters MUST NOT repeat unless otherwise =
noted

> in the parameter definition."

>

> Then in 4.1.3. the assertion parameter could be something like this:
>

>   "assertion

>          REQUIRED.  =
The assertion(s).  This parameter MAY be repeated in the

> request,  if more than one

>           assertion =
is needed for the access grant"

>

>

> Obviously Eran could improve on the actual text but hopefully that get=
s the

> concept across?

>

>

>

> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav

> <eran@hueniverse.com> wrote:=


> > Do we need to clarify 4.3.1 "repeats a parameter" descr=
iption for

> "invalid_request" error code does not preclude parameters fr=
om repeating?

> I'm not sure.

> >

> > EHL

> >

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

> >> From: oauth-bounces@ietf.o=
rg [mailto:oauth-bounces@ietf=
.org] On

> >> Behalf Of Brian Campbell

> >> Sent: Monday, August 09, 2010 12:34 PM

> >> To: oauth

> >> Subject: [OAUTH-WG] more than one assertion?

> >>

> >> The question of allowing for multiple assertions in the SAML =
profile

> >> came up recently.  See http://www.ietf.org/mail-

> >> archive/web/oauth/current/msg04068.html and several subsequen=
t

> >> messages in the thread.

> >>

> >> I pushed back on the idea at first due to added complexity. &=
nbsp;There

> >> are a number of things that need to be addressed that aren't =
present

> >> in the single assertion case.   One of the sticker ones,=
 to me, was

> >> how to encode the assertions into the request.   A SAML =
<Response>

> >> element is a nice container for multiple assertions but using=
 it in

> >> this context seemed awkward at best.  A new schema could=
 be defined

> >> or a special deliminator character could be used but that see=
ms excessive

> and kludgy respectively.

> >>

> >> What about pushing it up into the HTTP layer and allowing for=


> >> multiple occurrences of the assertion=3DXXX parameter in the =
POST body?

> >> I don't see anything in core OAuth that would necessarily pre=
clude doing

> this.

> >>  It seems cleaner and more lightweight than some of the =
other options.

> >>  And perhaps it could be a more general (not just SAML) =
method of

> >> sending multiple assertions in a single assertion grant type =
request?

> >>

> >> It'd look something like this:

> >>

> >>   POST /token.oauth2 HTTP/1.1

> >>   Host: authz.example.net

> >>   Content-Type: application/x-www-form-urlencoded

> >>

> >>    grant_type=3Dassertion&assertion_type=3Dhttp=
%3A%2F%2Foauth.net%2Fa

> sse

> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=
=3D[...1st

> >> assertion...]&assertion=3D

> >>    [...2nd assertion...]&assertion=3D[...3nd as=
sertion...]

> >> _______________________________________________

> >> OAuth mailing list

> >> OAuth@ietf.org

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

> >

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth






--_000_1990A18DEA6E97429CFD1B4D2C5DA7E7073E88TK5EX14MBXC101red_--

From zachary.zeltsan@alcatel-lucent.com  Mon Aug 30 16:01:25 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9743A6897 for ; Mon, 30 Aug 2010 16:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1kPWdqE8G3s for ; Mon, 30 Aug 2010 16:01:21 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 463283A6870 for ; Mon, 30 Aug 2010 16:01:20 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id o7UN1mRj028360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 30 Aug 2010 18:01:48 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o7UN1mLw001985 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Aug 2010 18:01:48 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 30 Aug 2010 18:01:48 -0500
From: "Zeltsan, Zachary (Zachary)" 
To: "'Jonathan Leibiusky'" , "oauth@ietf.org" 
Date: Mon, 30 Aug 2010 18:01:47 -0500
Thread-Topic: [OAUTH-WG] Doubts about the User-Agent Profile in OAuth2
Thread-Index: ActIYfLjNFazRMppQ+KDTBdUuSKGmQAJre1A
Message-ID: <5710F82C0E73B04FA559560098BF95B124FA54AB34@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B124FA54AB34USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Subject: Re: [OAUTH-WG] Doubts about the User-Agent Profile in OAuth2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 23:01:25 -0000

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

> I can't really understand how steps D, E and F works. Once I get the acce=
ss_token in the fragment, what happens then?
In step C client receives from authorization server an access token in the =
fragment part of the redirection URL, which the client provided to the auth=
orization server in step A.
In step D the client follows that URL (without sending the fragment).
In step E client receives a script embedded in an HTML page (in response to=
 the request of step D).
In step F client runs the script locally. The script extracts the access to=
ken from the URL received in step C and passes it to the client.

> How can I avoid from a malicious user check the source of my user-agent a=
pp, get the app-id and repeat the same steps from his own application somew=
here else?

I do not see how it can be done. The client's authentication to authorizati=
on server is not specified clearly in the draft.
The specification says:
"These clients cannot keep client
secrets confidential and the authentication of the client is based on
the user-agent's same-origin policy".

Can anyone explain how client's authentication works in the User-Agent use =
case?

Zachary

________________________________
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
onathan Leibiusky
Sent: Monday, August 30, 2010 9:45 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Doubts about the User-Agent Profile in OAuth2

Hi, I read the OAuth2 draft and I still have lots of doubts regard security=
 when talking about the User-Agent Profile.
I can't really understand how steps D, E and F works. Once I get the access=
_token in the fragment, what happens then?
How can I avoid from a malicious user check the source of my user-agent app=
, get the app-id and repeat the same steps from his own application somewhe=
re else?

Thanks!

Jonathan

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

















> I can't really
understand how steps D, E and F works. Once I get the access_token in the
fragment, what happens then?<=
/font>



In step C client receives from
authorization server an access token in the fragment part of the redirectio=
n
URL, which the client provided to the authorization server in step A.<=
/o:p>



In step D the client follows that URL =
(without
sending the fragment). 



In step E client receives a script
embedded in an HTML page (in response to the request of step D).=




In step F client runs the script local=
ly.
The script extracts the access token from the URL received in step C and pa=
sses
it to the client.



 



> How can I avoid fro=
m a
malicious user check the source of my user-agent app, get the app-id and re=
peat
the same steps from his own application somewhere else?



 



I do not see how it can be done. The
client’s authentication to authorization server is not specified clea=
rly
in the draft.



The specification says:



“These clients c=
annot
keep client



secrets confidential a=
nd the
authentication of the client is based on



the user-agent's same-origin policy”.=




 



Can anyone explain how client’s =
authentication
works in the User-Agent use case?



 



Zachary



 















From:
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Jonathan Leibiusky

Sent: Monday, August 30, 201=
0 9:45
AM

To: oauth@ietf.org

Subject: [OAUTH-WG] Doubts a=
bout
the User-Agent Profile in OAuth2






 



Hi, I read the OA=
uth2
draft and I still have lots of doubts regard security when talking about th=
e
User-Agent Profile.

I can't really understand how steps D, E and F works. Once I get the
access_token in the fragment, what happens then?

How can I avoid from a malicious user check the source of my user-agent app=
,
get the app-id and repeat the same steps from his own application somewhere
else?



Thanks!



Jonathan









--_000_5710F82C0E73B04FA559560098BF95B124FA54AB34USNAVSXCHMBSA_--

From tonynad@microsoft.com  Mon Aug 30 16:54:24 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0C03A68DD for ; Mon, 30 Aug 2010 16:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.691
X-Spam-Level: 
X-Spam-Status: No, score=-9.691 tagged_above=-999 required=5 tests=[AWL=0.173,  BAYES_00=-2.599, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82EpbbCWQzqc for ; Mon, 30 Aug 2010 16:54:17 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 6FE0B3A69EA for ; Mon, 30 Aug 2010 16:54:15 -0700 (PDT)
Received: from TK5EX14CASC129.redmond.corp.microsoft.com (157.54.52.7) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 30 Aug 2010 16:54:35 -0700
Received: from TK5EX14MBXC101.redmond.corp.microsoft.com ([169.254.1.183]) by TK5EX14CASC129.redmond.corp.microsoft.com ([157.54.52.7]) with mapi id 14.01.0218.010; Mon, 30 Aug 2010 16:54:34 -0700
From: Anthony Nadalin 
To: Torsten Lodderstedt 
Thread-Topic: [OAUTH-WG] more than one assertion?
Thread-Index: AQHLN/nn+pWzYl6T5UKTKi41Ej4aj5LakquAgAC9twCAAANjgIADN/wAgAwa+aCAAInfgIAPh7HQ
Date: Mon, 30 Aug 2010 23:54:32 +0000
Message-ID: <1990A18DEA6E97429CFD1B4D2C5DA7E7073F6A@TK5EX14MBXC101.redmond.corp.microsoft.com>
References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET>   <4C6EC97F.1020601@lodderstedt.net>
In-Reply-To: <4C6EC97F.1020601@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.123.12]
Content-Type: multipart/alternative; boundary="_000_1990A18DEA6E97429CFD1B4D2C5DA7E7073F6ATK5EX14MBXC101red_"
MIME-Version: 1.0
Cc: oauth 
Subject: Re: [OAUTH-WG] more than one assertion?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Aug 2010 23:54:24 -0000

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

The issues token may contain different subject identifiers which come from =
different issuing authorities; the new token may inherit from the source as=
sertions (aggregated) or these may be verified and passed on, there are cas=
es where both are methods are used.  So we have thought about multiple toke=
ns,, this winds up being more complicated and traffic, the reason to not se=
nd directly is for user consent.

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Friday, August 20, 2010 11:29 AM
To: Anthony Nadalin
Cc: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell; oauth
Subject: Re: [OAUTH-WG] more than one assertion?

What data shall the issued token contain? Different identifiers and also in=
formation about the different issuing authorities? Is the new token's data =
inherited from the source assertions or are the assertions just verified an=
d the token data (incl. identity) are from other sources?

What do you think about the following alternatives?
- issue one access token per assertion and send all tokens to the target se=
rvice
- directly send the assertions to the target service (underlying question: =
what is the benefit of converting assertions into tokens?)

regards,
Torsten.

Am 20.08.2010 20:19, schrieb Anthony Nadalin:
So the UK Government Gateway project is a concrete use case. The use case f=
or the UK government is that the government has many assertion providers; t=
his is due to both legal and historical reasons. The first assertion provid=
er is UK Department of Works and Pension (DWP), the second one is Departmen=
t of Motor Vehicles and the third is the Department of Revenue (and so on .=
..). A citizen may need and assertion from each one of these government dep=
artments attesting to various things. A person wants a parking permit, so D=
WP and Department of Motor Vehicles are involved; DWP is the authoritative =
source of address and DMV is the authoritative source of vehicle informatio=
n. So in order to obtain a parking permit, I have to live on the street tha=
t I obtain the parking permit for and I also need to own the vehicle for wh=
ich I'm obtaining the parking permit. So these 2 assertions under different=
 subject identifiers would have to be submitted to obtain the parking permi=
t. So there has to be a way to carry the 2 assertions to obtain the token t=
o get the parking permit.


From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Chuck Mortimore
Sent: Thursday, August 12, 2010 10:24 AM
To: Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

Personally, I'd first like to see more concrete use-cases of how multiple a=
ssertions are going to be used in practice.   Tony alluded to some abstract=
 use-cases, but fuller descriptions would probably help everyone out.

-cmort


On 8/10/10 9:15 AM, "Eran Hammer-Lahav"  wrote:
WFM.

> -----Original Message-----
> From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> Sent: Tuesday, August 10, 2010 9:03 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] more than one assertion?
>
> To be honest, I somehow overlooked that particular text - my mistake and
> apologies. Reading it again, it probably does preclude parameters from
> repeating, however, I can see some room for varied interpretations as to =
if
> that's a strong normative requirement or a looser suggestion about an err=
or
> code that could be used in that circumstance.
>
> Perhaps it could be made more clear by adding some wording about it to th=
e
> end of the first part of sections 3&4 where it says: "Parameters sent wit=
hout
> a value MUST be treated as if they were omitted from the request.  The
> authorization server SHOULD ignore unrecognized request parameters."?
>
> That said, does it make sense to relax the ban on repeating parameters in
> some situations, like for the assertion parameter, to facilitate
> easy encoding of multiple assertions?   Anthony (Tony?) Nadalin
> suggested that multiple assertions might be a common use case and I think
> allowing for that via repeating assertion parameters is a cleaner and mor=
e
> reusable way to do it.
>
> The text at the bottom of section for could say something like:
>
> "Parameters sent without a value MUST be treated as if they were omitted
> from the request.  The authorization server SHOULD ignore unrecognized
> request parameters.  Parameters MUST NOT repeat unless otherwise noted
> in the parameter definition."
>
> Then in 4.1.3. the assertion parameter could be something like this:
>
>   "assertion
>          REQUIRED.  The assertion(s).  This parameter MAY be repeated in =
the
> request,  if more than one
>           assertion is needed for the access grant"
>
>
> Obviously Eran could improve on the actual text but hopefully that gets t=
he
> concept across?
>
>
>
> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
>  wrote:
> > Do we need to clarify 4.3.1 "repeats a parameter" description for
> "invalid_request" error code does not preclude parameters from repeating?
> I'm not sure.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> >> Behalf Of Brian Campbell
> >> Sent: Monday, August 09, 2010 12:34 PM
> >> To: oauth
> >> Subject: [OAUTH-WG] more than one assertion?
> >>
> >> The question of allowing for multiple assertions in the SAML profile
> >> came up recently.  See http://www.ietf.org/mail-
> >> archive/web/oauth/current/msg04068.html and several subsequent
> >> messages in the thread.
> >>
> >> I pushed back on the idea at first due to added complexity.  There
> >> are a number of things that need to be addressed that aren't present
> >> in the single assertion case.   One of the sticker ones, to me, was
> >> how to encode the assertions into the request.   A SAML 
> >> element is a nice container for multiple assertions but using it in
> >> this context seemed awkward at best.  A new schema could be defined
> >> or a special deliminator character could be used but that seems excess=
ive
> and kludgy respectively.
> >>
> >> What about pushing it up into the HTTP layer and allowing for
> >> multiple occurrences of the assertion=3DXXX parameter in the POST body=
?
> >> I don't see anything in core OAuth that would necessarily preclude doi=
ng
> this.
> >>  It seems cleaner and more lightweight than some of the other options.
> >>  And perhaps it could be a more general (not just SAML) method of
> >> sending multiple assertions in a single assertion grant type request?
> >>
> >> It'd look something like this:
> >>
> >>   POST /token.oauth2 HTTP/1.1
> >>   Host: authz.example.net
> >>   Content-Type: application/x-www-form-urlencoded
> >>
> >>    grant_type=3Dassertion&assertion_type=3Dhttp%3A%2F%2Foauth.net%2Fa
> sse
> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=3D[...1st
> >> assertion...]&assertion=3D
> >>    [...2nd assertion...]&assertion=3D[...3nd assertion...]
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


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





Re: [OAUTH-WG] more than one assertion?






The issues token may cont=
ain different subject identifiers which come from different issuing authori=
ties; the new token may inherit from the source assertions
 (aggregated) or these may be verified and passed on, there are cases where=
 both are methods are used.  So we have thought about multiple tokens,=
, this winds up being more complicated and traffic, the reason to not send =
directly is for user consent.


 <=
/p>





From: Torsten Lodderstedt [mailto:torsten@lodderstedt.n=
et]


Sent: Friday, August 20, 2010 11:29 AM

To: Anthony Nadalin

Cc: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell; oauth

Subject: Re: [OAUTH-WG] more than one assertion?





 


What data shall the issued token contain? Different =
identifiers and also information about the different issuing authorities? I=
s the new token's data inherited from the source assertions or are the asse=
rtions just verified and the token
 data (incl. identity) are from other sources?  



What do you think about the following alternatives?

- issue one access token per assertion and send all tokens to the target se=
rvice 

- directly send the assertions to the target service (underlying question: =
what is the benefit of converting assertions into tokens?)



regards,

Torsten.



Am 20.08.2010 20:19, schrieb Anthony Nadalin: 


So the UK Government Gateway project is=
 a concrete use case. The use case for the UK government is that the govern=
ment has many assertion providers; this is due to both legal
 and historical reasons. The first assertion provider is UK Department of W=
orks and Pension (DWP), the second one is Department of Motor Vehicles and =
the third is the Department of Revenue (and so on …). A citizen may n=
eed and assertion from each one of these
 government departments attesting to various things. A person wants a parki=
ng permit, so DWP and Department of Motor Vehicles are involved; DWP is the=
 authoritative source of address and DMV is the authoritative source of veh=
icle information. So in order to
 obtain a parking permit, I have to live on the street that I obtain the pa=
rking permit for and I also need to own the vehicle for which I’m obt=
aining the parking permit. So these 2 assertions under different subject id=
entifiers would have to be submitted to
 obtain the parking permit. So there has to be a way to carry the 2 asserti=
ons to obtain the token to get the parking permit.


 


 






From:
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Chuck Mortimore

Sent: Thursday, August 12, 2010 10:24 AM

To: Eran Hammer-Lahav; Brian Campbell

Cc: oauth

Subject: Re: [OAUTH-WG] more than one assertion?





 


Personally, I’d first like to see more concrete use-cases of how m=
ultiple assertions are going to be used in practice.   Tony allud=
ed
 to some abstract use-cases, but fuller descriptions would probably help ev=
eryone out.



-cmort





On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:


WFM.



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

> From: Brian Campbell [ma=
ilto:bcampbell@pingidentity.com]

> Sent: Tuesday, August 10, 2010 9:03 AM

> To: Eran Hammer-Lahav

> Cc: oauth

> Subject: Re: [OAUTH-WG] more than one assertion?

>

> To be honest, I somehow overlooked that particular text - my mistake a=
nd

> apologies. Reading it again, it probably does preclude parameters from=


> repeating, however, I can see some room for varied interpretations as =
to if

> that's a strong normative requirement or a looser suggestion about an =
error

> code that could be used in that circumstance.

>

> Perhaps it could be made more clear by adding some wording about it to=
 the

> end of the first part of sections 3&4 where it says: "Paramet=
ers sent without

> a value MUST be treated as if they were omitted from the request. &nbs=
p;The

> authorization server SHOULD ignore unrecognized request parameters.&qu=
ot;?

>

> That said, does it make sense to relax the ban on repeating parameters=
 in

> some situations, like for the assertion parameter, to facilitate

> easy encoding of multiple assertions?   Anthony (Tony?) Nada=
lin

> suggested that multiple assertions might be a common use case and I th=
ink

> allowing for that via repeating assertion parameters is a cleaner and =
more

> reusable way to do it.

>

> The text at the bottom of section for could say something like:

>

> "Parameters sent without a value MUST be treated as if they were =
omitted

> from the request.  The authorization server SHOULD ignore unrecog=
nized

> request parameters.  Parameters MUST NOT repeat unless otherwise =
noted

> in the parameter definition."

>

> Then in 4.1.3. the assertion parameter could be something like this:
>

>   "assertion

>          REQUIRED.  =
The assertion(s).  This parameter MAY be repeated in the

> request,  if more than one

>           assertion =
is needed for the access grant"

>

>

> Obviously Eran could improve on the actual text but hopefully that get=
s the

> concept across?

>

>

>

> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav

> <eran@hueniverse.com> wrote:=


> > Do we need to clarify 4.3.1 "repeats a parameter" descr=
iption for

> "invalid_request" error code does not preclude parameters fr=
om repeating?

> I'm not sure.

> >

> > EHL

> >

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

> >> From: oauth-bounces@ietf.o=
rg [mailto:oauth-bounces@ietf=
.org] On

> >> Behalf Of Brian Campbell

> >> Sent: Monday, August 09, 2010 12:34 PM

> >> To: oauth

> >> Subject: [OAUTH-WG] more than one assertion?

> >>

> >> The question of allowing for multiple assertions in the SAML =
profile

> >> came up recently.  See http://www.ietf.org/mail-

> >> archive/web/oauth/current/msg04068.html and several subsequen=
t

> >> messages in the thread.

> >>

> >> I pushed back on the idea at first due to added complexity. &=
nbsp;There

> >> are a number of things that need to be addressed that aren't =
present

> >> in the single assertion case.   One of the sticker ones,=
 to me, was

> >> how to encode the assertions into the request.   A SAML =
<Response>

> >> element is a nice container for multiple assertions but using=
 it in

> >> this context seemed awkward at best.  A new schema could=
 be defined

> >> or a special deliminator character could be used but that see=
ms excessive

> and kludgy respectively.

> >>

> >> What about pushing it up into the HTTP layer and allowing for=


> >> multiple occurrences of the assertion=3DXXX parameter in the =
POST body?

> >> I don't see anything in core OAuth that would necessarily pre=
clude doing

> this.

> >>  It seems cleaner and more lightweight than some of the =
other options.

> >>  And perhaps it could be a more general (not just SAML) =
method of

> >> sending multiple assertions in a single assertion grant type =
request?

> >>

> >> It'd look something like this:

> >>

> >>   POST /token.oauth2 HTTP/1.1

> >>   Host: authz.example.net

> >>   Content-Type: application/x-www-form-urlencoded

> >>

> >>    grant_type=3Dassertion&assertion_type=3Dhttp=
%3A%2F%2Foauth.net%2Fa

> sse

> >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=
=3D[...1st

> >> assertion...]&assertion=3D

> >>    [...2nd assertion...]&assertion=3D[...3nd as=
sertion...]

> >> _______________________________________________

> >> OAuth mailing list

> >> OAuth@ietf.org

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

> >

_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth


 


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


https://www.ie=
tf.org/mailman/listinfo/oauth


 






--_000_1990A18DEA6E97429CFD1B4D2C5DA7E7073F6ATK5EX14MBXC101red_--

From ionathan@gmail.com  Mon Aug 30 19:10:43 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3C13A67E9 for ; Mon, 30 Aug 2010 19:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.127
X-Spam-Level: 
X-Spam-Status: No, score=-2.127 tagged_above=-999 required=5 tests=[AWL=0.471,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkP+LiAF2s2O for ; Mon, 30 Aug 2010 19:10:38 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 04DDC3A6860 for ; Mon, 30 Aug 2010 19:10:21 -0700 (PDT)
Received: by wyi11 with SMTP id 11so7807664wyi.31 for ; Mon, 30 Aug 2010 19:10:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=HFAVioldweOmMSkaQ9ftF/YifeZcIKwgdn9abm7pM4E=; b=CI7QeZsKK628CubJTZDIHQwNhwrf1fckRo1FjXmme3vceWHU7d0tB1BpX6OWgaog92 wVqRMsm7zBL+W+bMksNE8Ty1j0CMbXS0JWrLXGkjTt+bRLvror/cl7FL0r/qa1TsCpZ4 JxfbIzDEqfG5viQ9xTDxNsLOuR3i/RVIh2d3U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SPnBl2BcQfRWJOn8Tp8Dc43+fL/fs+7wGeMQCjbBpS9g8wb4+uNfiEVtV+x3CRqxAW evPoB081petPA4MbVuhKSZYt4xoST9eRk6lH4nf0P2ikKaTjNcdXwi9UhSJ9tk1CVTWT xeZK302nEPHlPtfvqcIOgXunAkOoAC14IBZj0=
MIME-Version: 1.0
Received: by 10.216.236.149 with SMTP id w21mr5673633weq.65.1283220649836; Mon, 30 Aug 2010 19:10:49 -0700 (PDT)
Received: by 10.216.220.217 with HTTP; Mon, 30 Aug 2010 19:10:49 -0700 (PDT)
In-Reply-To: <5710F82C0E73B04FA559560098BF95B124FA54AB34@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References:  <5710F82C0E73B04FA559560098BF95B124FA54AB34@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Date: Mon, 30 Aug 2010 23:10:49 -0300
Message-ID: 
From: Jonathan Leibiusky 
To: "Zeltsan, Zachary (Zachary)" 
Content-Type: multipart/alternative; boundary=000e0cd4024a008194048f151769
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Doubts about the User-Agent Profile in OAuth2
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Aug 2010 02:10:43 -0000

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

Ok I think I got it. So I believe authentication would be redirecting the
end-user to the authorization server where he needs to authenticate himself=
.
Now, based on Facebook javascript SDK, it seems like steps D-F are implicit=
.
So once step C is done, D, E and F are not needed because a local javascrip=
t
can extract the acccess_token from the fragment and execute JSONP calls wit=
h
the access_token to get the protected resource. Is that correct? Am I
missing something here or is it valid?

On Mon, Aug 30, 2010 at 8:01 PM, Zeltsan, Zachary (Zachary) <
zachary.zeltsan@alcatel-lucent.com> wrote:

>  > I can't really understand how steps D, E and F works. Once I get the
> access_token in the fragment, what happens then?
>
> In step C client receives from authorization server an access token in th=
e
> fragment part of the redirection URL, which the client provided to the
> authorization server in step A.
>
> In step D the client follows that URL (without sending the fragment).
>
> In step E client receives a script embedded in an HTML page (in response =
to
> the request of step D).
>
> In step F client runs the script locally. The script extracts the access
> token from the URL received in step C and passes it to the client.
>
>
>
> > How can I avoid from a malicious user check the source of my user-agent
> app, get the app-id and repeat the same steps from his own application
> somewhere else?
>
>
>
> I do not see how it can be done. The client=92s authentication to
> authorization server is not specified clearly in the draft.
>
> The specification says:
>
> =93These clients cannot keep client
>
> secrets confidential and the authentication of the client is based on
>
> the user-agent's same-origin policy=94.
>
>
>
> Can anyone explain how client=92s authentication works in the User-Agent =
use
> case?
>
>
>
> Zachary
>
>
>  ------------------------------
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Jonathan Leibiusky
> *Sent:* Monday, August 30, 2010 9:45 AM
> *To:* oauth@ietf.org
> *Subject:* [OAUTH-WG] Doubts about the User-Agent Profile in OAuth2
>
>
>
> Hi, I read the OAuth2 draft and I still have lots of doubts regard securi=
ty
> when talking about the User-Agent Profile.
> I can't really understand how steps D, E and F works. Once I get the
> access_token in the fragment, what happens then?
> How can I avoid from a malicious user check the source of my user-agent
> app, get the app-id and repeat the same steps from his own application
> somewhere else?
>
> Thanks!
>
> Jonathan
>

--000e0cd4024a008194048f151769
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Ok I think I got it. So I believe authentication would be redirecting the e=
nd-user to the authorization server where he needs to authenticate himself.=

Now, based on Facebook javascript SDK, it seems like steps D-F are impl=
icit. So once step C is done, D, E and F are not needed because a local jav=
ascript can extract the acccess_token from the fragment and execute JSONP c=
alls with the access_token to get the protected resource. Is that correct? =
Am I missing something here or is it valid?


On Mon, Aug 30, 2010 at 8:01 PM, Zeltsan, Za=
chary (Zachary) <zachary.zeltsan@alcatel-lucent.com> wrote:


















> I can't really
understand how steps D, E and F works. Once I get the access_token in the
fragment, what happens then?=




In step =
C client receives from
authorization server an access token in the fragment part of the redirectio=
n
URL, which the client provided to the authorization server in step A.



In step D the =
client follows that URL (without
sending the fragment). 



In step E clie=
nt receives a script
embedded in an HTML page (in response to the request of step D).



In step F clie=
nt runs the script locally.
The script extracts the access token from the URL received in step C and pa=
sses
it to the client.



=A0



> How can I avoid from a
malicious user check the source of my user-agent app, get the app-id and re=
peat
the same steps from his own application somewhere else?



=A0



I do not=
 see how it can be done. The
client=92s authentication to authorization server is not specified clearly
in the draft.



The specificat=
ion says:



=93These clients cannot
keep client



secrets confidential and the
authentication of the client is based on



the user-agent'=
;s same-origin policy=94.



=A0<=
/p>


Can anyone exp=
lain how client=92s authentication
works in the User-Agent use case?



=A0



Zachary=




=A0















From:
oauth-bounces@i=
etf.org [mailto:oauth-bounces@ietf.org] On B=
ehalf Of Jonathan Leibiusky


Sent: Monday, August 30, 2=
010 9:45
AM

To: oauth@ietf.org

Subject: [OAUTH-WG] Doubts=
 about
the User-Agent Profile in OAuth2






=A0



Hi, I read the OAuth2
draft and I still have lots of doubts regard security when talking about th=
e
User-Agent Profile.

I can't really understand how steps D, E and F works. Once I get the
access_token in the fragment, what happens then?

How can I avoid from a malicious user check the source of my user-agent app=
,
get the app-id and repeat the same steps from his own application somewhere
else?



Thanks!



Jonathan













--000e0cd4024a008194048f151769--

From torsten@lodderstedt.net  Tue Aug 31 00:36:24 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8DE3A6927 for ; Tue, 31 Aug 2010 00:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.022
X-Spam-Level: 
X-Spam-Status: No, score=-1.022 tagged_above=-999 required=5 tests=[AWL=0.492,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_93=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wNpCctvTw8P for ; Tue, 31 Aug 2010 00:36:15 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id 951693A6926 for ; Tue, 31 Aug 2010 00:36:13 -0700 (PDT)
Received: from [80.187.218.72] (helo=[127.0.0.1]) by smtprelay03.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1OqLOa-0001P0-O9; Tue, 31 Aug 2010 09:36:41 +0200
Message-ID: <4C7CB0FD.8000508@lodderstedt.net>
Date: Tue, 31 Aug 2010 09:36:29 +0200
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Anthony Nadalin 
References: <90C41DD21FB7C64BB94121FBBC2E72343B3F124503@P3PW5EX1MB01.EX1.SECURESERVER.NET>	  <4C6EC97F.1020601@lodderstedt.net> <1990A18DEA6E97429CFD1B4D2C5DA7E7073F6A@TK5EX14MBXC101.redmond.corp.microsoft.com>
In-Reply-To: <1990A18DEA6E97429CFD1B4D2C5DA7E7073F6A@TK5EX14MBXC101.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------070209040902090304060009"
X-Df-Sender: 141509
Cc: oauth 
Subject: Re: [OAUTH-WG] more than one assertion?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Aug 2010 07:36:24 -0000

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

  User consent in the assertion flow? How do you envision to acquire the 
user consent?

Am 31.08.2010 01:54, schrieb Anthony Nadalin:
>
> The issues token may contain different subject identifiers which come 
> from different issuing authorities; the new token may inherit from the 
> source assertions (aggregated) or these may be verified and passed on, 
> there are cases where both are methods are used.  So we have thought 
> about multiple tokens,, this winds up being more complicated and 
> traffic, the reason to not send directly is for user consent.
>
> *From:* Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> *Sent:* Friday, August 20, 2010 11:29 AM
> *To:* Anthony Nadalin
> *Cc:* Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell; oauth
> *Subject:* Re: [OAUTH-WG] more than one assertion?
>
> What data shall the issued token contain? Different identifiers and 
> also information about the different issuing authorities? Is the new 
> token's data inherited from the source assertions or are the 
> assertions just verified and the token data (incl. identity) are from 
> other sources?
>
> What do you think about the following alternatives?
> - issue one access token per assertion and send all tokens to the 
> target service
> - directly send the assertions to the target service (underlying 
> question: what is the benefit of converting assertions into tokens?)
>
> regards,
> Torsten.
>
> Am 20.08.2010 20:19, schrieb Anthony Nadalin:
>
> So the UK Government Gateway project is a concrete use case. The use 
> case for the UK government is that the government has many assertion 
> providers; this is due to both legal and historical reasons. The first 
> assertion provider is UK Department of Works and Pension (DWP), the 
> second one is Department of Motor Vehicles and the third is the 
> Department of Revenue (and so on ...). A citizen may need and 
> assertion from each one of these government departments attesting to 
> various things. A person wants a parking permit, so DWP and Department 
> of Motor Vehicles are involved; DWP is the authoritative source of 
> address and DMV is the authoritative source of vehicle information. So 
> in order to obtain a parking permit, I have to live on the street that 
> I obtain the parking permit for and I also need to own the vehicle for 
> which I'm obtaining the parking permit. So these 2 assertions under 
> different subject identifiers would have to be submitted to obtain the 
> parking permit. So there has to be a way to carry the 2 assertions to 
> obtain the token to get the parking permit.
>
> *From:* oauth-bounces@ietf.org  
> [mailto:oauth-bounces@ietf.org] *On Behalf Of *Chuck Mortimore
> *Sent:* Thursday, August 12, 2010 10:24 AM
> *To:* Eran Hammer-Lahav; Brian Campbell
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] more than one assertion?
>
> Personally, I'd first like to see more concrete use-cases of how 
> multiple assertions are going to be used in practice.   Tony alluded 
> to some abstract use-cases, but fuller descriptions would probably 
> help everyone out.
>
> -cmort
>
>
> On 8/10/10 9:15 AM, "Eran Hammer-Lahav"  wrote:
>
> WFM.
>
> > -----Original Message-----
> > From: Brian Campbell [mailto:bcampbell@pingidentity.com]
> > Sent: Tuesday, August 10, 2010 9:03 AM
> > To: Eran Hammer-Lahav
> > Cc: oauth
> > Subject: Re: [OAUTH-WG] more than one assertion?
> >
> > To be honest, I somehow overlooked that particular text - my mistake and
> > apologies. Reading it again, it probably does preclude parameters from
> > repeating, however, I can see some room for varied interpretations as 
> to if
> > that's a strong normative requirement or a looser suggestion about an 
> error
> > code that could be used in that circumstance.
> >
> > Perhaps it could be made more clear by adding some wording about it 
> to the
> > end of the first part of sections 3&4 where it says: "Parameters sent 
> without
> > a value MUST be treated as if they were omitted from the request.  The
> > authorization server SHOULD ignore unrecognized request parameters."?
> >
> > That said, does it make sense to relax the ban on repeating parameters in
> > some situations, like for the assertion parameter, to facilitate
> > easy encoding of multiple assertions?   Anthony (Tony?) Nadalin
> > suggested that multiple assertions might be a common use case and I think
> > allowing for that via repeating assertion parameters is a cleaner and 
> more
> > reusable way to do it.
> >
> > The text at the bottom of section for could say something like:
> >
> > "Parameters sent without a value MUST be treated as if they were omitted
> > from the request.  The authorization server SHOULD ignore unrecognized
> > request parameters.  Parameters MUST NOT repeat unless otherwise noted
> > in the parameter definition."
> >
> > Then in 4.1.3. the assertion parameter could be something like this:
> >
> >   "assertion
> >          REQUIRED.  The assertion(s).  This parameter MAY be repeated 
> in the
> > request,  if more than one
> >           assertion is needed for the access grant"
> >
> >
> > Obviously Eran could improve on the actual text but hopefully that 
> gets the
> > concept across?
> >
> >
> >
> > On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
> >  wrote:
> > > Do we need to clarify 4.3.1 "repeats a parameter" description for
> > "invalid_request" error code does not preclude parameters from repeating?
> > I'm not sure.
> > >
> > > EHL
> > >
> > >> -----Original Message-----
> > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> > >> Behalf Of Brian Campbell
> > >> Sent: Monday, August 09, 2010 12:34 PM
> > >> To: oauth
> > >> Subject: [OAUTH-WG] more than one assertion?
> > >>
> > >> The question of allowing for multiple assertions in the SAML profile
> > >> came up recently.  See http://www.ietf.org/mail-
> > >> archive/web/oauth/current/msg04068.html and several subsequent
> > >> messages in the thread.
> > >>
> > >> I pushed back on the idea at first due to added complexity.  There
> > >> are a number of things that need to be addressed that aren't present
> > >> in the single assertion case.   One of the sticker ones, to me, was
> > >> how to encode the assertions into the request.   A SAML 
> > >> element is a nice container for multiple assertions but using it in
> > >> this context seemed awkward at best.  A new schema could be defined
> > >> or a special deliminator character could be used but that seems 
> excessive
> > and kludgy respectively.
> > >>
> > >> What about pushing it up into the HTTP layer and allowing for
> > >> multiple occurrences of the assertion=XXX parameter in the POST body?
> > >> I don't see anything in core OAuth that would necessarily preclude 
> doing
> > this.
> > >>  It seems cleaner and more lightweight than some of the other options.
> > >>  And perhaps it could be a more general (not just SAML) method of
> > >> sending multiple assertions in a single assertion grant type request?
> > >>
> > >> It'd look something like this:
> > >>
> > >>   POST /token.oauth2 HTTP/1.1
> > >>   Host: authz.example.net
> > >>   Content-Type: application/x-www-form-urlencoded
> > >>
> > >>    grant_type=assertion&assertion_type=http%3A%2F%2Foauth.net%2Fa
> > sse
> > >>    rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=[...1st
> > >> assertion...]&assertion=
> > >>    [...2nd assertion...]&assertion=[...3nd assertion...]
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OAuth@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>   
>   
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org  
> https://www.ietf.org/mailman/listinfo/oauth
>

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



  
    
  
  
    User consent in the assertion flow? How do you envision to acquire
    the user consent?

    

    Am 31.08.2010 01:54, schrieb Anthony Nadalin:
    

      
      
      Re: [OAUTH-WG] more than one assertion?
      
      

        
The issues token may contain different subject
            identifiers which come from different issuing authorities;
            the new token may inherit from the source assertions
            (aggregated) or these may be verified and passed on, there
            are cases where both are methods are used.  So we have
            thought about multiple tokens,, this winds up being more
            complicated and traffic, the reason to not send directly is
            for user consent.

        
 

        

          

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

                Sent: Friday, August 20, 2010 11:29 AM

                To: Anthony Nadalin

                Cc: Chuck Mortimore; Eran Hammer-Lahav; Brian
                Campbell; oauth

                Subject: Re: [OAUTH-WG] more than one assertion?

          

        

        
 

        
What data shall the issued token contain?
          Different identifiers and also information about the different
          issuing authorities? Is the new token's data inherited from
          the source assertions or are the assertions just verified and
          the token data (incl. identity) are from other sources?  

          

          What do you think about the following alternatives?

          - issue one access token per assertion and send all tokens to
          the target service 

          - directly send the assertions to the target service
          (underlying question: what is the benefit of converting
          assertions into tokens?)

          

          regards,

          Torsten.

          

          Am 20.08.2010 20:19, schrieb Anthony Nadalin: 

        
So the UK
            Government Gateway project is a concrete use case. The use
            case for the UK government is that the government has many
            assertion providers; this is due to both legal and
            historical reasons. The first assertion provider is UK
            Department of Works and Pension (DWP), the second one is
            Department of Motor Vehicles and the third is the Department
            of Revenue (and so on …). A citizen may need and assertion
            from each one of these government departments attesting to
            various things. A person wants a parking permit, so DWP and
            Department of Motor Vehicles are involved; DWP is the
            authoritative source of address and DMV is the authoritative
            source of vehicle information. So in order to obtain a
            parking permit, I have to live on the street that I obtain
            the parking permit for and I also need to own the vehicle
            for which I’m obtaining the parking permit. So these 2
            assertions under different subject identifiers would have to
            be submitted to obtain the parking permit. So there has to
            be a way to carry the 2 assertions to obtain the token to
            get the parking permit.

        
 

        
 

        

          

            
From:
                oauth-bounces@ietf.org
                [mailto:oauth-bounces@ietf.org]
                On Behalf Of Chuck Mortimore

                Sent: Thursday, August 12, 2010 10:24 AM

                To: Eran Hammer-Lahav; Brian Campbell

                Cc: oauth

                Subject: Re: [OAUTH-WG] more than one assertion?

          

        

        
 

        
Personally, I’d first like
            to see more concrete use-cases of how multiple assertions
            are going to be used in practice.   Tony alluded to some
            abstract use-cases, but fuller descriptions would probably
            help everyone out.

            

            -cmort

            

            

            On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <eran@hueniverse.com>
            wrote:

        
WFM.

            

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

            > From: Brian Campbell [mailto:bcampbell@pingidentity.com]

            > Sent: Tuesday, August 10, 2010 9:03 AM

            > To: Eran Hammer-Lahav

            > Cc: oauth

            > Subject: Re: [OAUTH-WG] more than one assertion?

            >

            > To be honest, I somehow overlooked that particular text
            - my mistake and

            > apologies. Reading it again, it probably does preclude
            parameters from

            > repeating, however, I can see some room for varied
            interpretations as to if

            > that's a strong normative requirement or a looser
            suggestion about an error

            > code that could be used in that circumstance.

            >

            > Perhaps it could be made more clear by adding some
            wording about it to the

            > end of the first part of sections 3&4 where it
            says: "Parameters sent without

            > a value MUST be treated as if they were omitted from
            the request.  The

            > authorization server SHOULD ignore unrecognized request
            parameters."?

            >

            > That said, does it make sense to relax the ban on
            repeating parameters in

            > some situations, like for the assertion parameter, to
            facilitate

            > easy encoding of multiple assertions?   Anthony (Tony?)
            Nadalin

            > suggested that multiple assertions might be a common
            use case and I think

            > allowing for that via repeating assertion parameters is
            a cleaner and more

            > reusable way to do it.

            >

            > The text at the bottom of section for could say
            something like:

            >

            > "Parameters sent without a value MUST be treated as if
            they were omitted

            > from the request.  The authorization server SHOULD
            ignore unrecognized

            > request parameters.  Parameters MUST NOT repeat unless
            otherwise noted

            > in the parameter definition."

            >

            > Then in 4.1.3. the assertion parameter could be
            something like this:

            >

            >   "assertion

            >          REQUIRED.  The assertion(s).  This parameter
            MAY be repeated in the

            > request,  if more than one

            >           assertion is needed for the access grant"

            >

            >

            > Obviously Eran could improve on the actual text but
            hopefully that gets the

            > concept across?

            >

            >

            >

            > On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav

            > <eran@hueniverse.com>
            wrote:

            > > Do we need to clarify 4.3.1 "repeats a parameter"
            description for

            > "invalid_request" error code does not preclude
            parameters from repeating?

            > I'm not sure.

            > >

            > > EHL

            > >

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

            > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
            On

            > >> Behalf Of Brian Campbell

            > >> Sent: Monday, August 09, 2010 12:34 PM

            > >> To: oauth

            > >> Subject: [OAUTH-WG] more than one assertion?

            > >>

            > >> The question of allowing for multiple
            assertions in the SAML profile

            > >> came up recently.  See http://www.ietf.org/mail-

            > >> archive/web/oauth/current/msg04068.html and
            several subsequent

            > >> messages in the thread.

            > >>

            > >> I pushed back on the idea at first due to
            added complexity.  There

            > >> are a number of things that need to be
            addressed that aren't present

            > >> in the single assertion case.   One of the
            sticker ones, to me, was

            > >> how to encode the assertions into the request.
              A SAML <Response>

            > >> element is a nice container for multiple
            assertions but using it in

            > >> this context seemed awkward at best.  A new
            schema could be defined

            > >> or a special deliminator character could be
            used but that seems excessive

            > and kludgy respectively.

            > >>

            > >> What about pushing it up into the HTTP layer
            and allowing for

            > >> multiple occurrences of the assertion=XXX
            parameter in the POST body?

            > >> I don't see anything in core OAuth that would
            necessarily preclude doing

            > this.

            > >>  It seems cleaner and more lightweight than
            some of the other options.

            > >>  And perhaps it could be a more general (not
            just SAML) method of

            > >> sending multiple assertions in a single
            assertion grant type request?

            > >>

            > >> It'd look something like this:

            > >>

            > >>   POST /token.oauth2 HTTP/1.1

            > >>   Host: authz.example.net

            > >>   Content-Type:
            application/x-www-form-urlencoded

            > >>

            > >>  
             grant_type=assertion&assertion_type=http%3A%2F%2Foauth.net%2Fa

            > sse

            > >>  
             rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=[...1st

            > >> assertion...]&assertion=

            > >>    [...2nd assertion...]&assertion=[...3nd
            assertion...]

            > >>
            _______________________________________________

            > >> OAuth mailing list

            > >> OAuth@ietf.org

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

            > >

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.org

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

        
 

        
 

        
_______________________________________________

        
OAuth mailing list

        
OAuth@ietf.org

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

        
 

      

    

  


--------------070209040902090304060009--


From bill@dehora.net  Tue Aug 31 03:13:15 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C137E3A6A36 for ; Tue, 31 Aug 2010 03:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cg1yBXxld8G for ; Tue, 31 Aug 2010 03:13:07 -0700 (PDT)
Received: from chilco.textdrive.com (chilco.textdrive.com [207.7.108.242]) by core3.amsl.com (Postfix) with ESMTP id F08E83A6926 for ; Tue, 31 Aug 2010 03:12:32 -0700 (PDT)
Received: from [192.168.3.29] (87-198-172-217.static.ptr.magnet.ie [87.198.172.217]) by chilco.textdrive.com (Postfix) with ESMTP id 56F40F15AC; Tue, 31 Aug 2010 10:13:00 +0000 (UTC)
From: Bill de =?ISO-8859-1?Q?h=D3ra?= 
To: Eran Hammer-Lahav 
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3F35B370@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References:   <1283172404.2719.35.camel@dehora-laptop> <90C41DD21FB7C64BB94121FBBC2E72343B3F35B370@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 31 Aug 2010 11:12:47 +0100
Message-ID: <1283249567.9405.8.camel@dehora-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.28.3 
Content-Transfer-Encoding: 8bit
Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , OAuth WG 
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bill@dehora.net
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Aug 2010 10:13:15 -0000

Why not?

Bill

On Mon, 2010-08-30 at 10:10 -0700, Eran Hammer-Lahav wrote:
> It does not need to have any normative references to 5849.
> 
> EHL
> 
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Bill de hÓra
> Sent: Monday, August 30, 2010 5:47 AM
> To: David Recordon
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG
> Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
> 
> On Fri, 2010-08-27 at 20:26 +0000, David Recordon wrote:
> > This draft is now an Internet Draft and I'm curious if anyone has any 
> > feedback on it? 
> > http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00
> > 
> 
> replace
> 
> [[[
> client_id
>       REQUIRED.  The client identifier as described in Section 2 of
>       [I-D.ietf.oauth-v2].
> 
>    client_secret
>       REQUIRED.  The client secret as described in Section 2 of
>       [I-D.ietf.oauth-v2].
> ]]]
> 
> with
> 
> {{{
> client_id
>       REQUIRED.  The client identifier as described in Section 2 of
>       [I-D.ietf.oauth-v2], the value of which is the oauth_consumer_key
>       as described in [@@@rfc5849]
> 
>    client_secret
>       REQUIRED.  The client secret as described in Section 2 of
>       [I-D.ietf.oauth-v2],the value of which is the shared-secret
>       as described in "3.4 Signature" of [@@@rfc5849] }}}
> 
> The draft needs to reference rfc5849 rather than OAuth 1.0.
> 
> Bill
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



From eran@hueniverse.com  Tue Aug 31 11:11:37 2010
Return-Path: 
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637C53A69E2 for ; Tue, 31 Aug 2010 11:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level: 
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4QJgZ3Emidl for ; Tue, 31 Aug 2010 11:11:35 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id C1E2C3A6840 for ; Tue, 31 Aug 2010 11:11:35 -0700 (PDT)
Received: (qmail 10500 invoked from network); 31 Aug 2010 18:12:06 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 31 Aug 2010 18:12:06 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 31 Aug 2010 11:12:06 -0700
From: Eran Hammer-Lahav 
To: "bill@dehora.net" 
Date: Tue, 31 Aug 2010 11:12:02 -0700
Thread-Topic: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
Thread-Index: ActI9Rky+GTigbpFTyqGS7DunQvr/AAQulZV
Message-ID: 
In-Reply-To: <1283249567.9405.8.camel@dehora-laptop>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C8A294023964Beranhueniversecom_"
MIME-Version: 1.0
Cc: Hannes Tschofenig , OAuth WG 
Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Aug 2010 18:11:37 -0000

--_000_C8A294023964Beranhueniversecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Because 2.0 deployments are not likely to share the same credentials with 1=
.0, or at least it is not something I would like to suggest. This is a new =
protocol.

EHL


On 8/31/10 3:12 AM, "bill@dehora.net"  wrote:

Why not?

Bill

On Mon, 2010-08-30 at 10:10 -0700, Eran Hammer-Lahav wrote:
> It does not need to have any normative references to 5849.
>
> EHL
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of=
 Bill de h=D3ra
> Sent: Monday, August 30, 2010 5:47 AM
> To: David Recordon
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG
> Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension
>
> On Fri, 2010-08-27 at 20:26 +0000, David Recordon wrote:
> > This draft is now an Internet Draft and I'm curious if anyone has any
> > feedback on it?
> > http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00
> >
>
> replace
>
> [[[
> client_id
>       REQUIRED.  The client identifier as described in Section 2 of
>       [I-D.ietf.oauth-v2].
>
>    client_secret
>       REQUIRED.  The client secret as described in Section 2 of
>       [I-D.ietf.oauth-v2].
> ]]]
>
> with
>
> {{{
> client_id
>       REQUIRED.  The client identifier as described in Section 2 of
>       [I-D.ietf.oauth-v2], the value of which is the oauth_consumer_key
>       as described in [@@@rfc5849]
>
>    client_secret
>       REQUIRED.  The client secret as described in Section 2 of
>       [I-D.ietf.oauth-v2],the value of which is the shared-secret
>       as described in "3.4 Signature" of [@@@rfc5849] }}}
>
> The draft needs to reference rfc5849 rather than OAuth 1.0.
>
> Bill
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




--_000_C8A294023964Beranhueniversecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension


Because 2.0 deployments are not likely to share the same credentials =
with 1.0, or at least it is not something I would like to suggest. This is =
a new protocol.



EHL





On 8/31/10 3:12 AM, "bill@dehora.net&q=
uot; <bill@dehora.net> wrote:




Why not?



Bill



On Mon, 2010-08-30 at 10:10 -0700, Eran Hammer-Lahav wrote:

> It does not need to have any normative references to 5849.

>

> EHL

>

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

> From: oauth-bounces@ietf.org [<=
a href=3D"mailto:oauth-bounces@ietf.org">mailto:oauth-bounces@ietf.org]=
 On Behalf Of Bill de hÓra

> Sent: Monday, August 30, 2010 5:47 AM

> To: David Recordon

> Cc: Tschofenig, Hannes (NSN - FI/Espoo); OAuth WG

> Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension

>

> On Fri, 2010-08-27 at 20:26 +0000, David Recordon wrote:

> > This draft is now an Internet Draft and I'm curious if anyone has=
 any

> > feedback on it?

> > http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00<=
BR>
> >

>

> replace

>

> [[[

> client_id

>       REQUIRED.  The client identif=
ier as described in Section 2 of

>       [I-D.ietf.oauth-v2].

>

>    client_secret

>       REQUIRED.  The client secret =
as described in Section 2 of

>       [I-D.ietf.oauth-v2].

> ]]]

>

> with

>

> {{{

> client_id

>       REQUIRED.  The client identif=
ier as described in Section 2 of

>       [I-D.ietf.oauth-v2], the value of =
which is the oauth_consumer_key

>       as described in [@@@rfc5849]

>

>    client_secret

>       REQUIRED.  The client secret =
as described in Section 2 of

>       [I-D.ietf.oauth-v2],the value of w=
hich is the shared-secret

>       as described in "3.4 Signatur=
e" of [@@@rfc5849] }}}

>

> The draft needs to reference rfc5849 rather than OAuth 1.0.

>

> Bill

>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

> https://www.ie=
tf.org/mailman/listinfo/oauth













--_000_C8A294023964Beranhueniversecom_--