From nobody Fri Jun 1 06:57:43 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A429A12D875 for ; Fri, 1 Jun 2018 06:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRxyE1YvayLc for ; Fri, 1 Jun 2018 06:57:39 -0700 (PDT) Received: from smtp-out4.electric.net (smtp-out4.electric.net [192.162.216.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC49212D87B for ; Fri, 1 Jun 2018 06:57:38 -0700 (PDT) Received: from 1fOkYg-0003IO-Vz by out4a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fOkYi-0003Wa-Uo for oauth@ietf.org; Fri, 01 Jun 2018 06:57:36 -0700 Received: by emcmailer; Fri, 01 Jun 2018 06:57:36 -0700 Received: from [130.246.132.234] (helo=exchsmtp.stfc.ac.uk) by out4a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fOkYg-0003IO-Vz for oauth@ietf.org; Fri, 01 Jun 2018 06:57:34 -0700 Received: from exch03.fed.cclrc.ac.uk (130.246.132.234) by exch03.fed.cclrc.ac.uk (130.246.132.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1415.2; Fri, 1 Jun 2018 14:57:34 +0100 Received: from exch03.fed.cclrc.ac.uk ([fe80::25c0:55bd:d31a:d95b]) by exch03.fed.cclrc.ac.uk ([fe80::25c0:55bd:d31a:d95b%7]) with mapi id 15.01.1415.002; Fri, 1 Jun 2018 14:57:34 +0100 From: Matt Pryor - UKRI STFC To: "oauth@ietf.org" Thread-Topic: Dynamic Client Registration in trusted federation Thread-Index: AQHT+bB9jLQbu/dxiE+4zzbH9GudLA== Date: Fri, 1 Jun 2018 13:57:34 +0000 Message-ID: <59B07252-0FEA-433F-9DD7-F3C5A5B8CF66@stfc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.246.135.148] x-esetresult: clean, is OK x-esetid: 37303A295AAF266D607262 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-IP: 130.246.132.234 X-Env-From: Matt.Pryor@stfc.ac.uk X-Proto: esmtps X-Revdns: exch03.rl.ac.uk X-HELO: exchsmtp.stfc.ac.uk X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256 X-Authenticated_ID: X-PolicySMART: 3590380 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: [OAUTH-WG] Dynamic Client Registration in trusted federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 13:57:42 -0000 SGksDQoNCkkgYW0gd29ya2luZyBvbiBhIHVzZSBjYXNlIG9mIE9BdXRoIDIuMCBpbiBhIGZlZGVy YXRpb24gYW5kIGFtIGFmdGVyIHNvbWUgYWR2aWNlIGFib3V0IGJvb3RzdHJhcHBpbmcgdHJ1c3Qu DQoNCkVhY2ggc2l0ZSBpbiB0aGUgZmVkZXJhdGlvbiBoYXMgYW4gT0F1dGggMi4wIGF1dGhvcml6 YXRpb24gc2VydmVyIGFuZCBhbiBPQXV0aCAyLjAgcmVseWluZyBwYXJ0eS4gVGhlIHJlbHlpbmcg cGFydHkgYXQgZWFjaCBzaXRlIG5lZWRzIHRvIGJlIHJlZ2lzdGVyZWQgd2l0aCBhbGwgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVycyBpbiB0aGUgZmVkZXJhdGlvbi4gV2Ugd2FudCB0byBhdXRvbWF0 ZSBhcyBtdWNoIG9mIHRoaXMgcHJvY2VzcyBhcyBwb3NzaWJsZSwgYnV0IHJlc3RyaWN0IGNsaWVu dCByZWdpc3RyYXRpb24gdG8gdHJ1c3RlZCBtZW1iZXJzIG9mIHRoZSBmZWRlcmF0aW9uLiBXZSBh bHNvIHdhbnQgdG8gbWFrZSBvbmJvYXJkaW5nIGEgbmV3IGZlZGVyYXRpb24gbWVtYmVyIGFzIGVh c3kgYXMgcG9zc2libGUuDQoNClRoaXMgc2VlbXMgYW4gaWRlYWwgdXNlIGNhc2UgZm9yIHRoZSBE eW5hbWljIENsaWVudCBSZWdpc3RyYXRpb24gUHJvdG9jb2wgKFJGQyA3NTkxKS4gVGhlIFJGQyBw ZXJtaXRzIHRoZSBjbGllbnQgcmVnaXN0cmF0aW9uIGVuZHBvaW50IHRvIHJlcXVpcmUgYSBwcmUt ZXhpc3RpbmcgdG9rZW4gaW4gb3JkZXIgdG8gcmVnaXN0ZXIgYSBuZXcgY2xpZW50IHdoaWNoIGdp dmVzIHVzIG91ciBzZWN1cml0eSAob25seSB0cnVzdGVkIGZlZGVyYXRpb24gbWVtYmVycyBjYW4g cmVnaXN0ZXIgYSBjbGllbnQpLg0KDQpUaGUgY2hhbGxlbmdlIHNlZW1zIHRvIGJlIGluIGJvb3Rz dHJhcHBpbmcgdGhlIGluaXRpYWwgdHJ1c3QuIEl0IHNlZW1zIGN1bWJlcnNvbWUgdG8gcmVxdWly ZSB0aGF0IGEgbmV3IGZlZGVyYXRpb24gbWVtYmVyIG11c3QgbWFudWFsbHkgb2J0YWluIGEgdG9r ZW4gZnJvbSBlYWNoIGF1dGhvcml6YXRpb24gc2VydmVyIGJlZm9yZSByZWdpc3RlcmluZyAtIHRo ZXkgbWF5IGFzIHdlbGwgbWFudWFsbHkgcmVnaXN0ZXIgdGhlaXIgY2xpZW50LiBJJ2QgYmUgaW50 ZXJlc3RlZCB0byBrbm93IGlmIGFueW9uZSBoYXMgYW55IGlkZWFzIGZvciBhIHNvbHV0aW9uIG90 aGVyIHRoYW4gc2VjdXJlbHkgZGlzdHJpYnV0aW5nIGEgc2hhcmVkIHNlY3JldCB0byBuZXcgZmVk ZXJhdGlvbiBtZW1iZXJzLg0KDQpPbmUgcG9zc2libGUgb3B0aW9uIGlzIHRvIHBpZ2d5LWJhY2sg b24gdGhlIGxlZ2FjeSBhdXRobi96IHdlIGFscmVhZHkgaGF2ZSAtIHVzZXJzIGNhbiBvYnRhaW4g YW4gWDUwOSBjZXJ0aWZpY2F0ZSBmcm9tIHRoZWlyIGhvbWUgaWRwLCB3aGljaCBpcyB0aGVuIHRy dXN0ZWQgYnkgYWxsIHRoZSBvdGhlciBzaXRlcy4gV2UgY2FuIHRoZW4gb2J0YWluIFNBTUwgYXNz ZXJ0aW9ucyBhYm91dCB0aGVpciBwZXJtaXNzaW9ucyBiYXNlZCBvbiB0aGF0IGNlcnRpZmljYXRl LiBXZSBjb3VsZCB1c2UgdGhpcyBtZWNoYW5pc20gdG8gbWFpbnRhaW4gYSBsaXN0IG9mIHRydXN0 ZWQgYWRtaW5zLCByZXF1aXJpbmcgYXV0aGVudGljYXRpb24gd2l0aCBhbiBYNTA5IGNlcnRpZmlj YXRlIHdpdGggdGhlIGNvcnJlY3QgU0FNTCBhc3NlcnRpb24gZm9yIHRoZSBjbGllbnQgcmVnaXN0 cmF0aW9uIGVuZHBvaW50LiBIb3dldmVyLCB3ZSBhcmUgaG9waW5nIHRvIHJldGlyZSB0aGUgWDUw OSBzdXBwb3J0IGluIHRoZSBzaG9ydC10by1tZWRpdW0gdGVybSwgc28gSSdtIGFsc28gbG9va2lu ZyBmb3Igc29sdXRpb25zIHRoYXQgZG8gbm90IHVzZSBpdC4gSSdtIGFsc28gbm90IHN1cmUgaG93 IHRoZSB1c2Ugb2YgWDUwOSBjZXJ0aWZpY2F0ZXMgd291bGQgZml0IGluIHdpdGggYW4gUkZDLWNv bXBsaWFudCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgRHluYW1pYyBDbGllbnQgUmVnaXN0cmF0aW9u IFByb3RvY29sLg0KDQpUaGFua3MgaW4gYWR2YW5jZSBmb3IgeW91ciBoZWxwLA0KTWF0dA0KDQoN Cg== From nobody Fri Jun 1 07:28:14 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F112712D883 for ; Fri, 1 Jun 2018 07:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fls5yxc5jI4h for ; Fri, 1 Jun 2018 07:28:10 -0700 (PDT) Received: from sonic304-11.consmr.mail.bf2.yahoo.com (sonic304-11.consmr.mail.bf2.yahoo.com [74.6.128.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DDC12D880 for ; Fri, 1 Jun 2018 07:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1527863289; bh=kFpmhxbbeu3XqTsEneQ3AGnoTYJfp82N5ytqFuNatwM=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=IaS5kvDQDY76wlBqTYfhZZfeI/rC8ISeE/FQ6MwJs8tC6IYYeGJ867jjU33Y9T7hWR9K1s+QkWtYKTC/DluCQApyIVvIl3nI4CP5ShC1fzDfHswpws2Q12f66X2j5/wjM/4o1q2JyngzfmJKR95U13g5j1Z3gaFs68mZmTcZ0wdzK+Ca2UxoHjJrkddJ4D62wEQHNPy8l/CBkQYFBoRcXt8n+SRM5uviUVqqQYN2ZcA+BOUkjI/OFirg7BQcdxbit7BQraPE4Xxo70nu14UUrkLPk9JbB+Gxz4aLrOTNAe1ZUWNSRCEQIS6m/0u/cM0DtCyf/iiGCtLOtmrvBCr2qw== X-YMail-OSG: AHrHtFIVM1ktIaVPWVxaMBO56Tg.Hsx.2EudRLMsTDVGndm8_nz0jND7ksJE27A zM5pIrRnFYgZsqq.JtpR3_l0fV4zY93CTV4zK4Ia6u4aRV3f2jq7sod6IwBCCS3LnNdnUOL69HBT jk.WpOOcSqpz0FwonWuHsYXD43MeHIGtc3iAsVbMYcGIOAAT5hwUwwkcPvFAU_ULRZ_D_rTg3d9o jX8gOjSUKB.LcyZS8ZGlCnUq1fmFypLHkKJs_UnZOiFbV1lQSpHQVBXCYU7cPZ1tHmXLD8WQwWnn yZCHJNWA9zK3yZwRJvEZNBcd1NzrhCvQwuemhKHFcjUPEcR_xopsOKup9FCX8EiM6uHS6an4CFtZ 343j0sjzy2yfRJOsBn7dmlPRDd6ZBJ1_5uO3VHckZJEFyRNjjLQUGjlX75O6sad9C6_HoY9eZm_9 f0umH2QMkhFUOsVhWkalK3rCqldJVE.aES6rgzdblWerVy1doFv.IBAWgv.99Zbh5idvxhOy9odQ ywzIVrIdHETwa42xTWaJcHkWgulqaiJ7mNn3L9P.lIRmrTWY9ZyVEZASA_yE7cbzXV0dIRwJFZnf vNGIB9Qkcvg_.3EwaheMaHpRV1UP1sFKP6uejN8gN.CjBkTYQsjEYETHdOE59hryG.eM27WIpQ7s KIojHWHjhkuk_frkexkgJc2UH Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Fri, 1 Jun 2018 14:28:09 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID be9f83e131f62a7f99dc67841202658b; Fri, 01 Jun 2018 14:28:06 +0000 (UTC) To: Matt Pryor - UKRI STFC , "oauth@ietf.org" References: <59B07252-0FEA-433F-9DD7-F3C5A5B8CF66@stfc.ac.uk> From: George Fletcher Organization: AOL LLC Message-ID: Date: Fri, 1 Jun 2018 10:28:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <59B07252-0FEA-433F-9DD7-F3C5A5B8CF66@stfc.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Dynamic Client Registration in trusted federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 14:28:13 -0000 Given that you have a federation, could not the federation issue the signed software-statement to each of the relying parties (existing or old) and the AS will trust the dynamic client registration if and only if the signed software-statement is signed by the federation. This fits more closely with the trust framework model. Thanks, George On 6/1/18 9:57 AM, Matt Pryor - UKRI STFC wrote: > Hi, > > I am working on a use case of OAuth 2.0 in a federation and am after some advice about bootstrapping trust. > > Each site in the federation has an OAuth 2.0 authorization server and an OAuth 2.0 relying party. The relying party at each site needs to be registered with all the authorization servers in the federation. We want to automate as much of this process as possible, but restrict client registration to trusted members of the federation. We also want to make onboarding a new federation member as easy as possible. > > This seems an ideal use case for the Dynamic Client Registration Protocol (RFC 7591). The RFC permits the client registration endpoint to require a pre-existing token in order to register a new client which gives us our security (only trusted federation members can register a client). > > The challenge seems to be in bootstrapping the initial trust. It seems cumbersome to require that a new federation member must manually obtain a token from each authorization server before registering - they may as well manually register their client. I'd be interested to know if anyone has any ideas for a solution other than securely distributing a shared secret to new federation members. > > One possible option is to piggy-back on the legacy authn/z we already have - users can obtain an X509 certificate from their home idp, which is then trusted by all the other sites. We can then obtain SAML assertions about their permissions based on that certificate. We could use this mechanism to maintain a list of trusted admins, requiring authentication with an X509 certificate with the correct SAML assertion for the client registration endpoint. However, we are hoping to retire the X509 support in the short-to-medium term, so I'm also looking for solutions that do not use it. I'm also not sure how the use of X509 certificates would fit in with an RFC-compliant implementation of the Dynamic Client Registration Protocol. > > Thanks in advance for your help, > Matt > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From nobody Fri Jun 1 07:33:43 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EE312D883 for ; Fri, 1 Jun 2018 07:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKDUvNGRghYJ for ; Fri, 1 Jun 2018 07:33:39 -0700 (PDT) Received: from smtp-out4.electric.net (smtp-out4.electric.net [192.162.216.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4BC412D880 for ; Fri, 1 Jun 2018 07:33:39 -0700 (PDT) Received: from 1fOl7W-00068B-TX by out4a.electric.net with emc1-ok (Exim 4.90_1) (envelope-from ) id 1fOl7Z-0006bi-VM; Fri, 01 Jun 2018 07:33:37 -0700 Received: by emcmailer; Fri, 01 Jun 2018 07:33:37 -0700 Received: from [130.246.132.232] (helo=exchsmtp.stfc.ac.uk) by out4a.electric.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fOl7W-00068B-TX; Fri, 01 Jun 2018 07:33:34 -0700 Received: from exch03.fed.cclrc.ac.uk (130.246.132.234) by exch01.fed.cclrc.ac.uk (130.246.132.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.1415.2; Fri, 1 Jun 2018 15:33:33 +0100 Received: from exch03.fed.cclrc.ac.uk ([fe80::25c0:55bd:d31a:d95b]) by exch03.fed.cclrc.ac.uk ([fe80::25c0:55bd:d31a:d95b%7]) with mapi id 15.01.1415.002; Fri, 1 Jun 2018 15:33:33 +0100 From: Matt Pryor - UKRI STFC To: George Fletcher , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Dynamic Client Registration in trusted federation Thread-Index: AQHT+bB9jLQbu/dxiE+4zzbH9GudLKRLZV2AgAASSoA= Date: Fri, 1 Jun 2018 14:33:33 +0000 Message-ID: References: <59B07252-0FEA-433F-9DD7-F3C5A5B8CF66@stfc.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.246.135.148] x-esetresult: clean, is OK x-esetid: 37303A290F3E246D607262 Content-Type: text/plain; charset="utf-8" Content-ID: <568E97CD7874724EAB827980A6A24067@fed.cclrc.ac.uk> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-IP: 130.246.132.232 X-Env-From: Matt.Pryor@stfc.ac.uk X-Proto: esmtps X-Revdns: exch01.rl.ac.uk X-HELO: exchsmtp.stfc.ac.uk X-TLS: TLSv1.2:ECDHE-RSA-AES256-SHA384:256 X-Authenticated_ID: X-PolicySMART: 3590380 X-Virus-Status: Scanned by VirusSMART (c) X-Virus-Status: Scanned by VirusSMART (s) Archived-At: Subject: Re: [OAUTH-WG] Dynamic Client Registration in trusted federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 14:33:42 -0000 SGkgR2VvcmdlLA0KDQpUaGF0IGRpZCBvY2N1ciB0byBtZS4gSXQgc2VlbWVkIGxpa2UgYSBiaXQg b2YgYW4gYWJ1c2Ugb2YgdGhlIHNvZnR3YXJlLXN0YXRlbWVudCBzeXN0ZW0sIGJ1dCBtYXliZSBp dCBpcyBwYXJ0aWFsbHkgaW50ZW5kZWQgZm9yIHRoaXMuDQoNCkl0IHN0aWxsIG5lZWRzIHVzIHRv IHNlY3VyZWx5IGRpc3RyaWJ1dGUgdGhlIHNvZnR3YXJlIHN0YXRlbWVudCBhcyB3ZWxsLiBXb3Vs ZCB5b3UgZW52aXNhZ2UgYSBzaW5nbGUgc29mdHdhcmUtc3RhdGVtZW50IGZvciBhbGwgaW5zdGFs bGF0aW9ucywgd2l0aCBlYWNoIGluc3RhbGxhdGlvbiBzcGVjaWZ5aW5nIHRoZWlyIG93biBjbGll bnQtc3BlY2lmaWMgbWV0YWRhdGEsIG9yIHdvdWxkIHlvdSBpc3N1ZSBhIHNvZnR3YXJlLXN0YXRl bWVudCBwZXIgaW5zdGFsbGF0aW9uLiBUaGUgc2Vjb25kIHNvdW5kcyBsaWtlIGl0IHdvdWxkIGFs bG93IHVzIHRvIGV4ZXJ0IG1vcmUgY29udHJvbC4NCg0KVGhhbmtzIGZvciB5b3VyIGhlbHAhDQpN YXR0DQoNCu+7v09uIDAxLzA2LzIwMTgsIDE1OjI4LCAiR2VvcmdlIEZsZXRjaGVyIiA8Z2ZmbGV0 Y2hAYW9sLmNvbT4gd3JvdGU6DQoNCiAgICBHaXZlbiB0aGF0IHlvdSBoYXZlIGEgZmVkZXJhdGlv biwgY291bGQgbm90IHRoZSBmZWRlcmF0aW9uIGlzc3VlIHRoZSANCiAgICBzaWduZWQgc29mdHdh cmUtc3RhdGVtZW50IHRvIGVhY2ggb2YgdGhlIHJlbHlpbmcgcGFydGllcyAoZXhpc3Rpbmcgb3Ig DQogICAgb2xkKSBhbmQgdGhlIEFTIHdpbGwgdHJ1c3QgdGhlIGR5bmFtaWMgY2xpZW50IHJlZ2lz dHJhdGlvbiBpZiBhbmQgb25seSANCiAgICBpZiB0aGUgc2lnbmVkIHNvZnR3YXJlLXN0YXRlbWVu dCBpcyBzaWduZWQgYnkgdGhlIGZlZGVyYXRpb24uIFRoaXMgZml0cyANCiAgICBtb3JlIGNsb3Nl bHkgd2l0aCB0aGUgdHJ1c3QgZnJhbWV3b3JrIG1vZGVsLg0KICAgIA0KICAgIFRoYW5rcywNCiAg ICBHZW9yZ2UNCiAgICANCiAgICBPbiA2LzEvMTggOTo1NyBBTSwgTWF0dCBQcnlvciAtIFVLUkkg U1RGQyB3cm90ZToNCiAgICA+IEhpLA0KICAgID4NCiAgICA+IEkgYW0gd29ya2luZyBvbiBhIHVz ZSBjYXNlIG9mIE9BdXRoIDIuMCBpbiBhIGZlZGVyYXRpb24gYW5kIGFtIGFmdGVyIHNvbWUgYWR2 aWNlIGFib3V0IGJvb3RzdHJhcHBpbmcgdHJ1c3QuDQogICAgPg0KICAgID4gRWFjaCBzaXRlIGlu IHRoZSBmZWRlcmF0aW9uIGhhcyBhbiBPQXV0aCAyLjAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5k IGFuIE9BdXRoIDIuMCByZWx5aW5nIHBhcnR5LiBUaGUgcmVseWluZyBwYXJ0eSBhdCBlYWNoIHNp dGUgbmVlZHMgdG8gYmUgcmVnaXN0ZXJlZCB3aXRoIGFsbCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXJzIGluIHRoZSBmZWRlcmF0aW9uLiBXZSB3YW50IHRvIGF1dG9tYXRlIGFzIG11Y2ggb2YgdGhp cyBwcm9jZXNzIGFzIHBvc3NpYmxlLCBidXQgcmVzdHJpY3QgY2xpZW50IHJlZ2lzdHJhdGlvbiB0 byB0cnVzdGVkIG1lbWJlcnMgb2YgdGhlIGZlZGVyYXRpb24uIFdlIGFsc28gd2FudCB0byBtYWtl IG9uYm9hcmRpbmcgYSBuZXcgZmVkZXJhdGlvbiBtZW1iZXIgYXMgZWFzeSBhcyBwb3NzaWJsZS4N CiAgICA+DQogICAgPiBUaGlzIHNlZW1zIGFuIGlkZWFsIHVzZSBjYXNlIGZvciB0aGUgRHluYW1p YyBDbGllbnQgUmVnaXN0cmF0aW9uIFByb3RvY29sIChSRkMgNzU5MSkuIFRoZSBSRkMgcGVybWl0 cyB0aGUgY2xpZW50IHJlZ2lzdHJhdGlvbiBlbmRwb2ludCB0byByZXF1aXJlIGEgcHJlLWV4aXN0 aW5nIHRva2VuIGluIG9yZGVyIHRvIHJlZ2lzdGVyIGEgbmV3IGNsaWVudCB3aGljaCBnaXZlcyB1 cyBvdXIgc2VjdXJpdHkgKG9ubHkgdHJ1c3RlZCBmZWRlcmF0aW9uIG1lbWJlcnMgY2FuIHJlZ2lz dGVyIGEgY2xpZW50KS4NCiAgICA+DQogICAgPiBUaGUgY2hhbGxlbmdlIHNlZW1zIHRvIGJlIGlu IGJvb3RzdHJhcHBpbmcgdGhlIGluaXRpYWwgdHJ1c3QuIEl0IHNlZW1zIGN1bWJlcnNvbWUgdG8g cmVxdWlyZSB0aGF0IGEgbmV3IGZlZGVyYXRpb24gbWVtYmVyIG11c3QgbWFudWFsbHkgb2J0YWlu IGEgdG9rZW4gZnJvbSBlYWNoIGF1dGhvcml6YXRpb24gc2VydmVyIGJlZm9yZSByZWdpc3Rlcmlu ZyAtIHRoZXkgbWF5IGFzIHdlbGwgbWFudWFsbHkgcmVnaXN0ZXIgdGhlaXIgY2xpZW50LiBJJ2Qg YmUgaW50ZXJlc3RlZCB0byBrbm93IGlmIGFueW9uZSBoYXMgYW55IGlkZWFzIGZvciBhIHNvbHV0 aW9uIG90aGVyIHRoYW4gc2VjdXJlbHkgZGlzdHJpYnV0aW5nIGEgc2hhcmVkIHNlY3JldCB0byBu ZXcgZmVkZXJhdGlvbiBtZW1iZXJzLg0KICAgID4NCiAgICA+IE9uZSBwb3NzaWJsZSBvcHRpb24g aXMgdG8gcGlnZ3ktYmFjayBvbiB0aGUgbGVnYWN5IGF1dGhuL3ogd2UgYWxyZWFkeSBoYXZlIC0g dXNlcnMgY2FuIG9idGFpbiBhbiBYNTA5IGNlcnRpZmljYXRlIGZyb20gdGhlaXIgaG9tZSBpZHAs IHdoaWNoIGlzIHRoZW4gdHJ1c3RlZCBieSBhbGwgdGhlIG90aGVyIHNpdGVzLiBXZSBjYW4gdGhl biBvYnRhaW4gU0FNTCBhc3NlcnRpb25zIGFib3V0IHRoZWlyIHBlcm1pc3Npb25zIGJhc2VkIG9u IHRoYXQgY2VydGlmaWNhdGUuIFdlIGNvdWxkIHVzZSB0aGlzIG1lY2hhbmlzbSB0byBtYWludGFp biBhIGxpc3Qgb2YgdHJ1c3RlZCBhZG1pbnMsIHJlcXVpcmluZyBhdXRoZW50aWNhdGlvbiB3aXRo IGFuIFg1MDkgY2VydGlmaWNhdGUgd2l0aCB0aGUgY29ycmVjdCBTQU1MIGFzc2VydGlvbiBmb3Ig dGhlIGNsaWVudCByZWdpc3RyYXRpb24gZW5kcG9pbnQuIEhvd2V2ZXIsIHdlIGFyZSBob3Bpbmcg dG8gcmV0aXJlIHRoZSBYNTA5IHN1cHBvcnQgaW4gdGhlIHNob3J0LXRvLW1lZGl1bSB0ZXJtLCBz byBJJ20gYWxzbyBsb29raW5nIGZvciBzb2x1dGlvbnMgdGhhdCBkbyBub3QgdXNlIGl0LiBJJ20g YWxzbyBub3Qgc3VyZSBob3cgdGhlIHVzZSBvZiBYNTA5IGNlcnRpZmljYXRlcyB3b3VsZCBmaXQg aW4gd2l0aCBhbiBSRkMtY29tcGxpYW50IGltcGxlbWVudGF0aW9uIG9mIHRoZSBEeW5hbWljIENs aWVudCBSZWdpc3RyYXRpb24gUHJvdG9jb2wuDQogICAgPg0KICAgID4gVGhhbmtzIGluIGFkdmFu Y2UgZm9yIHlvdXIgaGVscCwNCiAgICA+IE1hdHQNCiAgICA+DQogICAgPg0KICAgID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IE9BdXRoIG1h aWxpbmcgbGlzdA0KICAgID4gT0F1dGhAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCiAgICA+DQogICAgDQogICAgDQoNCg== From nobody Fri Jun 1 08:04:36 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A8D12D88A for ; Fri, 1 Jun 2018 08:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcGCjze8ns2h for ; Fri, 1 Jun 2018 08:04:21 -0700 (PDT) Received: from sonic316-13.consmr.mail.bf2.yahoo.com (sonic316-13.consmr.mail.bf2.yahoo.com [74.6.130.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB0212D892 for ; Fri, 1 Jun 2018 08:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1527865460; bh=4UR6GSkvxds0PLxk60or+dikclX1Gf/d7O8ZXdETWDQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=LTWKjb5L/LZD2nEzH43lve0xFWZVCr8FE1Q+ige4zGdfXU0d96z034Nq3SS2AYKu95eEVFsKT2BJD2/5mmqp/v2d+JiGQVSlaRGAr3AUA8p7X5QIkSuwc6s7qqOAe8nnhq67xg/+WBadhPgiVmsACn1DbJnRIqid23EWVPqX82pta6Kg7Q0rjIQ2J4/zvCpoAhe/VO4UFkJf527JPg/pI+CpWUIhGkdvE/sigcslzL6QfDGRUkSvim2Rl3CZhwBLJp0wJ3LG3DmaGkGJVA8HuZOeR2tv9Oc8Yr6zjRxDKHbYCG6RuGASHAQHLSd7SOW5M9DbaKCoBtGiPur7x4F3ig== X-YMail-OSG: C1JzXLIVM1mN34Sjkle8B9nxEg0DzJEIttMpASr7X5cDFiSDO2KIXyVk7VKSX2U Ss3hkryFz90v18Aje8kuMPt_mIyaK8_ksYEuJUhq_OELcn9ZiGdc3YVCAevZ8g7mZ0aBH4Lw_vwK 8BXIhotpkn2BoEm5_ewv8BJftMsbwDWwaaxae8plbJuwHEgGey7r2mWExAief1BPlwmDqUydt4r8 B7Vz3c0YAJOdDmbMksN7N2LWhUxHCCUvXvBJAIB3pyn194oa676HX9wziIAtpn2gbl6rZib3el0r x8Www6kiLtj0grtDXGYAxuamVdlhamoXNdoo0dpbT_i.PIyszuXGSJsAhPMOBC03Zjp7IkaDVUR1 kc8RwhJQ7Y1G12dqO9AwCF0I7L0x58U5GQccceBQNleiQC8tRbGU_RVsPYmElzfokTWWpwtChRhY aCAqykeGO4oRUEhSQumLlCKqthMD2ht34NmZPLXfXwiwuY4grZgVlYREfWQCCiD5FvDnFixca.TN quxDa4dIAYyrJ8LfITXZ5AK4flDdvCSM6qVW955CIWIK_pDaQXB.fn5Ge_0aOMHdzkL3Mevp4UmH NSWFDDW.TUTG6hul7JV2pL0ffszEVp4WpSzdCY9jUCpb_8ACPn67ieF29qngkpgHL5ZFrLlFL.F4 CH6JYONcr5t0Jw3ZGJTqX6kqulcBmd31A.kFX Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Fri, 1 Jun 2018 15:04:20 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a7599839fa5bc309bf66b2680291a5ca; Fri, 01 Jun 2018 15:04:16 +0000 (UTC) To: Bill Burke , Brian Campbell Cc: oauth References: From: George Fletcher Organization: AOL LLC Message-ID: <0e12c6a8-4733-e4a2-e8c8-863d4a3b2a0e@aol.com> Date: Fri, 1 Jun 2018 11:04:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 15:04:25 -0000 I'm fine with it being optional but I don't think it should be removed. I have a use case where the actor_token is being used. In my use case the "actor" represents a device making a token exchange between two applications running on the device. It allows the AS to enforce a binding such that only apps on the same device can exchange tokens. Full details can be found on the OpenID Connect working group mailing list: http://lists.openid.net/pipermail/openid-specs-ab/Week-of-Mon-20180430/006733.html Thanks, George On 5/17/18 8:10 AM, Bill Burke wrote: > My personal opinion is that I'm glad this actor stuff is optional. > For one, none of our users have asked for it and really only do simple > exchanges. Secondly, the rules for who can exchange what for what is > controlled and defined within our AS. Makes things a lot simpler on > the client. I kind of wish the actor stuff would be defined in a > separate specification. I don't see us implementing it unless users > start asking us to. > > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell > wrote: >> Well, it's already called the "actor claim" so the claimed part is kind of >> implied. And "claimed actor claim" is a rather awkward. Really, all JWT >> claims are "claimed something" but they don't include the "claimed" bit in >> the name. RFC 7519, for example, defines the subject claim but not the >> claimed subject claim. >> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: >>> Brian, >>> >>> Eric said: "what is the RP supposed to do when they encounter it? This >>> seems kind of under specified". >>> >>> After reading your explanations below, it looks like the RP can do >>> anything he wants with the "actor". >>> It is a "claimed actor" and, if we keep the concept, it should be called >>> as such. Such a claim cannot be verified. >>> A RP could copy and paste that claim in an audit log. No standard action >>> related to the content of such a claim >>> can be specified in the spec. If the content of a "claimed actor" is used >>> by the RP, it should be only used as an hint >>> and thus be subject to other verifications which are not specified in this >>> specification. >>> >>> Denis >>> >>> Eric, I realize you weren't particularly impressed by my prior statements >>> about the actor claim but, for lack of knowing what else to say, I'm going >>> to kind of repeat what I said about it over in the Phabricator tool and add >>> a little color. >>> >>> The actor claim is intended as a way to express that delegation has >>> happened and identify the entities involved. Access control or other >>> decisions based on it are at the discretion of the consumer of the token >>> based on whatever policy might be in place. >>> >>> There are JWT claims that have concise processing rules with respect to >>> whether or not the JWT can be accepted as valid. Some examples are "aud" >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RFC 7519. >>> E.g. if the token is expired or was intended for someone or something else, >>> reject it. >>> >>> And there are JWT claims that appropriately don't specify such processing >>> rules and are solely statements of fact or circumstance. Also from RFC 7519, >>> the "sub" (Subject) and "iat" (Issued At) claims are good examples of such. >>> There might be application or policy specific rules applied to the content >>> of those kinds of claims (e.g. only subjects from a particular organization >>> are able to access tenant specific data or, less realistic but still >>> possible, disallow access for tokens issued outside of regular business >>> hours) but that's all outside the scope of a specification's definition of >>> the claim. >>> >>> The actor claim falls into the latter category. It's a way for the issuer >>> of the token to tell the consumer of the token what is going on. But any >>> action to take (or not) based on that information is at the discretion of >>> the token consumer. I honestly don't know it could be anything more. And >>> don't think it should be. >>> >>> There are two main expected uses of the actor claim (that I'm aware of >>> anyway) that describing here might help. Maybe. One is a human to human >>> delegation case like a customer service rep doing something on behalf of an >>> end user. The subject would be that user and the actor would be the customer >>> service rep. And there wouldn't be any chaining or nesting of the actor. The >>> other case is so called service chaining where a system might exchange a >>> token it receives for a new token that it can use to call a downstream >>> service. And that service in turn might do another exchange to get a new >>> token suitable to call yet another downstream service. And again and so on >>> and turtles all the way. I'm not necessarily endorsing that level of >>> granularity in chaining but it's bound to happen somewhere/sometime. The >>> nested actor claim is able to express that all that has happened with the >>> top level or outermost one being the system currently using the token and >>> prior systems being nested.. What actually gets done with that information >>> is up to the respective systems involved. There might be policy about what >>> system is allowed to call what other system that is enforced. Or maybe the >>> info is just written to an audit log somewhere. Or something else. I don't >>> know. But whatever it is application/deployment/policy dependent and not >>> specifiable by a spec. >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote: >>>> Hi folks, >>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem >>>> generally OK. I do still have one remaining concern, which is about >>>> the actor claim. Specifically, what is the RP supposed to do when they >>>> encounter it? This seems kind of underspecified. >>>> >>>> In particular: >>>> >>>> 1. What facts am I supposed to know here? Merely that everyone in >>>> the chain signed off on the next person in the chain acting as them? >>>> >>>> 2. Am I just supposed to pretend that the person presenting the token >>>> is the identity at the top of the chain? Say I have the >>>> delegation A -> B -> C, and there is some resource which >>>> B can access but A and C cannot, should I give access? >>>> >>>> I think the first question definitely needs an answer. The second >>>> question I guess we could make not answer, but it's pretty hard >>>> to know how to make a system with this left open.. >>>> >>>> -Ekr >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged >>> material for the sole use of the intended recipient(s). Any review, use, >>> distribution or disclosure by others is strictly prohibited.. If you have >>> received this communication in error, please notify the sender immediately >>> by e-mail and delete the message and any file attachments from your >>> computer. Thank you. >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged >> material for the sole use of the intended recipient(s). Any review, use, >> distribution or disclosure by others is strictly prohibited.. If you have >> received this communication in error, please notify the sender immediately >> by e-mail and delete the message and any file attachments from your >> computer. Thank you. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > From nobody Fri Jun 1 08:21:27 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FE812D890 for ; Fri, 1 Jun 2018 08:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsZn6QSKO6Kq for ; Fri, 1 Jun 2018 08:21:22 -0700 (PDT) Received: from sonic317-27.consmr.mail.bf2.yahoo.com (sonic317-27.consmr.mail.bf2.yahoo.com [74.6.129.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A136C1205F0 for ; Fri, 1 Jun 2018 08:21:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1527866480; bh=34szvtU81tIGEdfUW6JtMYOJHNiPOJity1RtkKC9PVw=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=bhNMLlHu5Yrzd9hafk+ttSYtKYYssYnWkk69kIhh9FjdtVHI1cqnrovkTSBa18krJxf34y9dyDqredIZ/JtnlT00pL7C87CF6eLLuvp17q2Hk7u7FGhhlMz0H4uimx2p1EjdDb5K0H94/TxnYNhsvi6Gr0zRyqF/MAmMpP8deIUJnCnXGOp1egN/nWhgSJ2aglELfr+UTQkkvA+31HQjPSlIym9UFn6nLHKIpcOnPTUA4eJo45cvjVLhtLtoSoF/q3f652Em/b/ftzz17J7nkLjNLibvBTIjgo8oqeSWx/CjgieuaA9QIwHO8mGkQBA/8jfA5dUCt+SbV6ARhGM/jg== X-YMail-OSG: 9yBJun4VM1lrkLau0388NBx5o02apY7IyijRyO5yTu670ehrErgLpxxCYvvgCQ6 .IlAqgOSztfOck.d2OKU2_CRvRXX09JjtSzZOAlJGm57JgUQm4N2xMbg7um0iFJoaLjI7GQZptkl VXD_pjXRjZVS3uLm9tfNKI3wNVbsIC.5b8lplvng2PyfxhjgWUwT46BOWnLngxTKo4kKc8ga9yHw wq1we1dfz.9mCDIT4L2xkfd4yNnxctahcH49KYLChIg6EFneyA9W0Ky.HYI9WG3VvrUev21KZu5m M9ymkUfDR8dmucWIzh5dSKnNjVoNJXgwz3EO1Wh7P1c0Oa868A4vmKqzmj3oPUq9wAY5txolF.Wi tPJOjGfRnDsb51eG4fDKPyNnH2eWRdfcJGm_2dZ1LVGB0jfWDy8Jweo2KOZcMI7pRpubX8kBVnw1 IVfR8x..cv9NFRyBQaeAGAyYqFt3HE6GQUq22yS_3Bn90bY4Ys1JFGXt2MlhWi47qhV.aOe1g1EV 7x2EAI9cVxynJvQsHAzMflZylCK.cmyvYw6OqIcGo06gvn.rq1nuHV.SeV6SFSNkUhf.FXON04od O8X1RuuslVyf78dL3MGjErjn1S4Ib1OmU9LgGWCL9hOtUCjqh65u8BSKHjq7ltXfhCyw8lEXcQk5 iH6_wcgMsj6YdwkdZLf7Xs5o_9sSGTsA4R2CVZ1LrreoD7A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Fri, 1 Jun 2018 15:21:20 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp425.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 130ff5da5f052be1f1b25ca9478601d9; Fri, 01 Jun 2018 15:21:20 +0000 (UTC) To: Matt Pryor - UKRI STFC , "oauth@ietf.org" References: <59B07252-0FEA-433F-9DD7-F3C5A5B8CF66@stfc.ac.uk> From: George Fletcher Organization: AOL LLC Message-ID: <3d432797-4645-7215-d855-3f33cfd2efb3@aol.com> Date: Fri, 1 Jun 2018 11:21:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1852B830AFA6D3FE0513CBF1" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Dynamic Client Registration in trusted federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 15:21:25 -0000 This is a multi-part message in MIME format. --------------1852B830AFA6D3FE0513CBF1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Matt, I think your use case is fully within the use cases enabled by software-statements. A per client software-statement allows you to tighten the security model (if desired). For example binding the software-statement to the client presenting it in such a way as to have a cryptographic trust chain. Unfortunately, the specifications are not clear about the best way to do this. The Client Registration Request does allow for "extension parameters" so that may be a way to add what's necessary. Thanks, George On 6/1/18 10:33 AM, Matt Pryor - UKRI STFC wrote: > Hi George, > > That did occur to me. It seemed like a bit of an abuse of the software-statement system, but maybe it is partially intended for this. > > It still needs us to securely distribute the software statement as well. Would you envisage a single software-statement for all installations, with each installation specifying their own client-specific metadata, or would you issue a software-statement per installation. The second sounds like it would allow us to exert more control. > > Thanks for your help! > Matt > > On 01/06/2018, 15:28, "George Fletcher" wrote: > > Given that you have a federation, could not the federation issue the > signed software-statement to each of the relying parties (existing or > old) and the AS will trust the dynamic client registration if and only > if the signed software-statement is signed by the federation. This fits > more closely with the trust framework model. > > Thanks, > George > > On 6/1/18 9:57 AM, Matt Pryor - UKRI STFC wrote: > > Hi, > > > > I am working on a use case of OAuth 2.0 in a federation and am after some advice about bootstrapping trust. > > > > Each site in the federation has an OAuth 2.0 authorization server and an OAuth 2.0 relying party. The relying party at each site needs to be registered with all the authorization servers in the federation. We want to automate as much of this process as possible, but restrict client registration to trusted members of the federation. We also want to make onboarding a new federation member as easy as possible. > > > > This seems an ideal use case for the Dynamic Client Registration Protocol (RFC 7591). The RFC permits the client registration endpoint to require a pre-existing token in order to register a new client which gives us our security (only trusted federation members can register a client). > > > > The challenge seems to be in bootstrapping the initial trust. It seems cumbersome to require that a new federation member must manually obtain a token from each authorization server before registering - they may as well manually register their client. I'd be interested to know if anyone has any ideas for a solution other than securely distributing a shared secret to new federation members. > > > > One possible option is to piggy-back on the legacy authn/z we already have - users can obtain an X509 certificate from their home idp, which is then trusted by all the other sites. We can then obtain SAML assertions about their permissions based on that certificate. We could use this mechanism to maintain a list of trusted admins, requiring authentication with an X509 certificate with the correct SAML assertion for the client registration endpoint. However, we are hoping to retire the X509 support in the short-to-medium term, so I'm also looking for solutions that do not use it. I'm also not sure how the use of X509 certificates would fit in with an RFC-compliant implementation of the Dynamic Client Registration Protocol. > > > > Thanks in advance for your help, > > Matt > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > --------------1852B830AFA6D3FE0513CBF1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Matt,

I think your use case is fully within the use cases enabled by software-statements.

A per client software-statement allows you to tighten the security model (if desired). For example binding the software-statement to the client presenting it in such a way as to have a cryptographic trust chain. Unfortunately, the specifications are not clear about the best way to do this. The Client Registration Request does allow for "extension parameters" so that may be a way to add what's necessary.

Thanks,
George

On 6/1/18 10:33 AM, Matt Pryor - UKRI STFC wrote:
Hi George,

That did occur to me. It seemed like a bit of an abuse of the software-statement system, but maybe it is partially intended for this.

It still needs us to securely distribute the software statement as well. Would you envisage a single software-statement for all installations, with each installation specifying their own client-specific metadata, or would you issue a software-statement per installation. The second sounds like it would allow us to exert more control.

Thanks for your help!
Matt

On 01/06/2018, 15:28, "George Fletcher" <gffletch@aol.com> wrote:

    Given that you have a federation, could not the federation issue the 
    signed software-statement to each of the relying parties (existing or 
    old) and the AS will trust the dynamic client registration if and only 
    if the signed software-statement is signed by the federation. This fits 
    more closely with the trust framework model.
    
    Thanks,
    George
    
    On 6/1/18 9:57 AM, Matt Pryor - UKRI STFC wrote:
    > Hi,
    >
    > I am working on a use case of OAuth 2.0 in a federation and am after some advice about bootstrapping trust.
    >
    > Each site in the federation has an OAuth 2.0 authorization server and an OAuth 2.0 relying party. The relying party at each site needs to be registered with all the authorization servers in the federation. We want to automate as much of this process as possible, but restrict client registration to trusted members of the federation. We also want to make onboarding a new federation member as easy as possible.
    >
    > This seems an ideal use case for the Dynamic Client Registration Protocol (RFC 7591). The RFC permits the client registration endpoint to require a pre-existing token in order to register a new client which gives us our security (only trusted federation members can register a client).
    >
    > The challenge seems to be in bootstrapping the initial trust. It seems cumbersome to require that a new federation member must manually obtain a token from each authorization server before registering - they may as well manually register their client. I'd be interested to know if anyone has any ideas for a solution other than securely distributing a shared secret to new federation members.
    >
    > One possible option is to piggy-back on the legacy authn/z we already have - users can obtain an X509 certificate from their home idp, which is then trusted by all the other sites. We can then obtain SAML assertions about their permissions based on that certificate. We could use this mechanism to maintain a list of trusted admins, requiring authentication with an X509 certificate with the correct SAML assertion for the client registration endpoint. However, we are hoping to retire the X509 support in the short-to-medium term, so I'm also looking for solutions that do not use it. I'm also not sure how the use of X509 certificates would fit in with an RFC-compliant implementation of the Dynamic Client Registration Protocol.
    >
    > Thanks in advance for your help,
    > Matt
    >
    >
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.ietf.org/mailman/listinfo/oauth
    >

--------------1852B830AFA6D3FE0513CBF1-- From nobody Fri Jun 1 08:41:13 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6431F12D94F for ; Fri, 1 Jun 2018 08:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_WW5X66PDMp for ; Fri, 1 Jun 2018 08:41:08 -0700 (PDT) Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E44312D943 for ; Fri, 1 Jun 2018 08:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1527867667; bh=DQl74s1XITBQ1BBo4XhgXBs9UNuTyHEasGoFIxU4bj8=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=ibtXbtXqDsVLoLbxQo8Yq5/RIa1cYYjEizuqPMZYfwqmN5Z1m4U8bfOexsgKd7V24F1XRBPbQVpMVsjB0c9BnAcFGQicrQ2JBzgoEqP5+Qs1U04zgBPNGN/B1Ry9wRAKI2KdonfdJ/zV73k3YHSRga9o7otdtROo50zmB6mw9t5Y+s8HkPjZHVRMTafRasGKcEltIz0XlSdH1rop6Czvogp+DjWAlXmnQMMk/ISPaZcSmNX2gdrNEOU295Ah9eCddSCpGJXyCrd7exl9WLPZhx7Y6cmP5Br5IjinjThn90FfcBSK1RoyFDz0L44/9Q3pMcLOYH1hhRZ8w6BWCVGe6Q== X-YMail-OSG: RNAO.pAVM1ndyMfQgD0QYtKSACxUodFoNMJVoRswBvcjK5WAP5pbkaiZPXC.wbl GLyPn80FMzFXf_qwke0ivhSgEK6_imGVwWPs6nMA_eDtRMDxRJ1AnGM1u8MhXBcYZRxGlPbyRJ6f nK07lrlNclNA1cCDToV2McnFQgmv00aFtng4ZYHdRoRlKILKU73kOUr49D2Dsfq6x1F_WSSDt38b _MhuyaPlNWeyi5NvJtvt4508v5ZbFgGpO3Z3Cke7H0LRUUtU3m4mydpFGv59bdMsC6pvt0eUQbmy fK6Nq0gUL8DFQHkpBQhZcoBOPwWFXf7ljeOo_R3TpIlGO55dBVhyurCulZOXGmw60WLaeyTsSKJk nBPwoCNgZpFCfvGfFFwi1VUsUuwkazKeO3WK2DlbyYw9aT1zHOcnbh62D65aXyqe1JL.czggVTIv CEiMgFArjQtk7ELmgDaIFQkUNh6D_kWL3jnk09WeEh98.DYmtNT05cf6fIU.Aes.l9v.TvQ7eWmF gFmbv1FffYhoYtyyPVXyP5vMvd7PpcHcVm2aVFVyqbSpjv2JmbA2LUHBIYG.zjfKAUbghJmjpvzp WxaUNud.2Ep8nsIaovml3Q4ME4rhefLEuWRCSG27CAF6TFjWhlFhp1oKfIOsgkCBEGjlhRnpJQGI T6KYD7VXzCXt4238RBebczU_x Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Fri, 1 Jun 2018 15:41:07 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp405.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 39bc5f9491ac6904422c8abf6a7dd3bc; Fri, 01 Jun 2018 15:41:02 +0000 (UTC) To: Torsten Lodderstedt , oauth References: <152752608213.4961.1659822390005305046.idtracker@ietfa.amsl.com> <4D24E05B-EDC1-458C-A106-662345090399@lodderstedt.net> From: George Fletcher Organization: AOL LLC Message-ID: <37aa8ce8-c999-57bd-e4d5-387c6e365adc@aol.com> Date: Fri, 1 Jun 2018 11:41:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <4D24E05B-EDC1-458C-A106-662345090399@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------88A8C69C5772D9EF71063C2B" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 15:41:11 -0000 This is a multi-part message in MIME format. --------------88A8C69C5772D9EF71063C2B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit What is the expectation if the RS requests a signed JWT response but the AS doesn't support it? Should getting a signed response require both? (meaning the Accept header and an AS config that that RP wants it)? That may be the safest from a backward compatibility perspective. I have some concerns around relying on 'iss' and 'aud' to prevent abuse and wonder if a JWT Header claim describing the context of the JWT might be better. Thanks, George On 5/28/18 12:58 PM, Torsten Lodderstedt wrote: > Hi all, > > I just published a new revision of the JWT Introspection response > draft. Based on the feedback in London, the draft entirely focuses on > use cases where the RS requires stronger assurance that the respective > AS issued the token, including cases where the AS assumes liability > for the token’s content. > > We incorporated the following changes: > • fixed typos in client meta data field names (thanks Petteri!) > • added OAuth Server Metadata parameters to publish algorithms > supported for signing and encrypting the introspection response > • added registration of new parameters for OAuth Server Metadata and > Client Registration > • added explicit request for JWT introspection response > • made iss and aud claims mandatory in introspection response (thanks > Neil!) > • Stylistic and clarifying edits, updates references > > Thanks to all reviewers! > > Vladimir and I are on the fence whether the Introspection Response > format should be determined by the AS based on its policy and/or > RS-related registration metadata or whether the RS should explicitly > request a JWT response by including an Accept header „application/jwt“ > in the respective request. > > What do you think? > > kind regards, > Torsten. > >> Anfang der weitergeleiteten Nachricht: >> >> *Von: *internet-drafts@ietf.org >> *Betreff: **New Version Notification for >> draft-lodderstedt-oauth-jwt-introspection-response-01.txt* >> *Datum: *28. Mai 2018 um 18:48:02 MESZ >> *An: *"Vladimir Dzhuvinov" > >, "Torsten Lodderstedt" >> > >> >> >> A new version of I-D, >> draft-lodderstedt-oauth-jwt-introspection-response-01.txt >> has been successfully submitted by Torsten Lodderstedt and posted to the >> IETF repository. >> >> Name:draft-lodderstedt-oauth-jwt-introspection-response >> Revision:01 >> Title:JWT Response for OAuth Token Introspection >> Document date:2018-05-28 >> Group:Individual Submission >> Pages:10 >> URL: >> https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/ >> Htmlized: >> https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-jwt-introspection-response-01 >> >> Abstract: >>   This draft proposes an additional JSON Web Token (JWT) based response >>   for OAuth 2.0 Token Introspection. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------88A8C69C5772D9EF71063C2B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit What is the expectation if the RS requests a signed JWT response but the AS doesn't support it? Should getting a signed response require both? (meaning the Accept header and an AS config that that RP wants it)? That may be the safest from a backward compatibility perspective.

I have some concerns around relying on 'iss' and 'aud' to prevent abuse and wonder if a JWT Header claim describing the context of the JWT might be better.

Thanks,
George

On 5/28/18 12:58 PM, Torsten Lodderstedt wrote:
Hi all, 

I just published a new revision of the JWT Introspection response draft. Based on the feedback in London, the draft entirely focuses on use cases where the RS requires stronger assurance that the respective AS issued the token, including cases where the AS assumes liability for the token’s content. 

We incorporated the following changes:
• fixed typos in client meta data field names (thanks Petteri!)
• added OAuth Server Metadata parameters to publish algorithms supported for signing and encrypting the introspection response
• added registration of new parameters for OAuth Server Metadata and Client Registration
• added explicit request for JWT introspection response
• made iss and aud claims mandatory in introspection response (thanks Neil!)
• Stylistic and clarifying edits, updates references

Thanks to all reviewers!

Vladimir and I are on the fence whether the Introspection Response format should be determined by the AS based on its policy and/or RS-related registration metadata or whether the RS should explicitly request a JWT response by including an Accept header „application/jwt“ in the respective request. 

What do you think?

kind regards,
Torsten.

Anfang der weitergeleiteten Nachricht:

Betreff: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-01.txt
Datum: 28. Mai 2018 um 18:48:02 MESZ
An: "Vladimir Dzhuvinov" <vladimir@connect2id.com>, "Torsten Lodderstedt" <torsten@lodderstedt.net>


A new version of I-D, draft-lodderstedt-oauth-jwt-introspection-response-01.txt
has been successfully submitted by Torsten Lodderstedt and posted to the
IETF repository.

Name: draft-lodderstedt-oauth-jwt-introspection-response
Revision: 01
Title: JWT Response for OAuth Token Introspection
Document date: 2018-05-28
Group: Individual Submission
Pages: 10
URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-01.txt
Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/
Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response
Diff:           https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-jwt-introspection-response-01

Abstract:
  This draft proposes an additional JSON Web Token (JWT) based response
  for OAuth 2.0 Token Introspection.




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

The IETF Secretariat




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

--------------88A8C69C5772D9EF71063C2B-- From nobody Fri Jun 1 09:20:09 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6176212D95A for ; Fri, 1 Jun 2018 09:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-stuttgart.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0zK9evy_sZY for ; Fri, 1 Jun 2018 09:20:03 -0700 (PDT) Received: from mxex2.tik.uni-stuttgart.de (mxex2.tik.uni-stuttgart.de [IPv6:2001:7c0:2041:24::a:2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2AB212D961 for ; Fri, 1 Jun 2018 09:20:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTP id 2238782F6E for ; Fri, 1 Jun 2018 18:20:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=uni-stuttgart.de; h=content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=dkim; i= @sec.uni-stuttgart.de; t=1527869999; x=1529608800; bh=YGbIvjduY7 SUvaGOKIky59E5mVt43KJaw9y+210n2gA=; b=O+SuH627twvi+MVT6Xog8bIztV a+3j6ifLzykDgGgFyCaJgrREusUw56zlmIHxgAP8MELjtsq4He2javLhvM5DZlHQ y7+OIlgU8NKt59D6drAVbhaiIJKrYtHwLTtvqIk+Re9j6hbmFue6X+Lxdf9PCqsB Vp0rXfN1MvLFOssq9AenR74onpPNjOizUAQxRMnmDlui4H4C7KimK3dHnQZbobcZ TljV+nNiXqiwazzrx5LNVf0q88BxSbh/2tjinPZ5adLONV4/zEl/kAD2gneQzIUG Q5E6S1XH450fLgSd3BE8IvqSi+IQJ9Xu5vr3TEgI0rpwENR+W5bDPkc+jXZA== X-Virus-Scanned: USTUTT mailrelay AV services at mxex2.tik.uni-stuttgart.de Received: from mxex2.tik.uni-stuttgart.de ([127.0.0.1]) by localhost (mxex2.tik.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10031) with ESMTP id K-IcEOp0NWr4 for ; Fri, 1 Jun 2018 18:19:59 +0200 (CEST) Received: from [IPv6:2001:7c0:2015:182::1:32] (unknown [IPv6:2001:7c0:2015:182::1:32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTPSA for ; Fri, 1 Jun 2018 18:19:59 +0200 (CEST) References: <36ec5346-3b8c-f60e-879d-a95141273a9a@sec.uni-stuttgart.de> To: oauth@ietf.org From: Daniel Fett Openpgp: preference=signencrypt Autocrypt: addr=daniel.fett@sec.uni-stuttgart.de; prefer-encrypt=mutual; keydata= xsFNBFbu2RUBEAC3F5+IMjFcXSj46xS8QQe6d/FAb+7IkkOdFKrINhgCialH4enWB2V3ykOX xESdrchRBCLoePyNmoJdFTijGxBMGNqSKU9rrppF5uvPFv/qIvCaBDAjFXR+qshsHjsMxTNH 67kuhkFQczKQHs4KVICG/gnssC3iejrk6Mav0MIJKXXdz6bUQPDyUTD+LsyHJ7vNfkfitnO4 rbD+kEZ0n14dQqp+c91b7X5KZVTt1c3d/N1kbruS29SlIDUJSHV0AdDZmP6wuH5a9XUIlDkP mM2bncIry3xiXWolYf3BJigxYg1XwVMYBdsrVg4kID5WY1RCHns07cDGluERcurjj3QHjToL T7VemcnFVzSphjjisi9a1QfRYCPf5xw5L8IjsAuNTBLv2DXKtL6Mf5Tv9BAZPD2em0rNS5n/ M7S6D2AAxIt9BQQ4aS16faI0gfUspj09RLdHANwOcLUPu+OE+O2IdgglBQLkadwLj9aY0ncE 8GhqFWcQ9xbtvHAljYaz5VmsOnjsadfGD8xW+QtWeFc8mfq7PncRjrc0Ywtb8TKeXkLHUQoT 4v2ilXisfOhryVj6/GuQvDjKKyUBW1tQPxei4n/W0zBC4LWehmwCH+WrFt+mTh3uHSyy9VbR FYmY6MBBMUpHHVQ3AVLgxoldu/yX/ery+fdE8MeScAWg+WE5rQARAQABzSBEYW5pZWwgRmV0 dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPsLBgAQTAQgAKgIbAwUJC0c1AAULCQgHAwUVCgkICwUW AgMBAAIeAQIXgAUCVu7cmAIZAQAKCRBYD1kOlZ2qqXCPD/wLpgL6j51OUlGzLaA+Xt+QzX/v qUiHJsvv1mEnyofk/3pGr7ce/1UNp7e8/W2JnnHvz4RBaNkn07DFyOvrVNXiMyU6mKWvG6xw Ri5Qc2t1Cup+mXlNc5fxlZGnwOYXZJErYVTPodkFlbb6LKUMyg6v2P7ZEvw4YyPh7WpV5ujF VVkYBSLviNCjVwKr8WlJJlVI4uvHZshnX85lVpRNcF+Hqf7IhnJzCQ5bUNnV7aKc4WPNw7L6 EquuCAl6JGKdeV2M+S5UVN9Eaa/CQxJf8X9I3SVgWCGQ/gLt0x1oKt6oFMECJcH2LDFOJyWv 61AUIzqCdRiTUagdc+7sn2OFbbjhKin9x+Qq6pyoXa6ZcpEuyBoAy+hNU8RAXcPgvEBy4Bwx BYQ9S3uQmBx/TcYgSUbBwBhvIYRVM5DfBefolj3HyUlvHx8JO8scbdcVl+v1+f9d5x4YS16t bWNe7awE6UWM2I02+uv7SI2ieJ2zQsOulDTEYVYjWcu0hBH24K53wniyh3JHzu6RVCgewx4P 6H2WHOSVf2p9ppuIrbWh7J6pp9nFdDXESKxH3GO5LooLamGugSlRwdgsqxY0O4BbCpKIpfe8 31peA+7qbh1f4TXHo/ZQE8fZ2s4VN5XR5J5/yjfqY2pWDy1XocixzXboLAcuzGmZNutS46eH Azjo2CxTa87BTQRW7tkVARAA1cAIBWNxYj/QE7RcOHGgr8xXcKWk/wwTWgLvjEbp5tqMl3Jk EwD1Iajz1s+Qp7U+U4UqyI+ZSfm03bYFYlTyKaS2esiM+Incutg18N943xwGNc6csyNoW5/f xbDQ4hoMKsod9zjfvxpA8xLg8gjuPKi5Y698K7qDCCfGvo6e67qwFWIvrB7cv/NAoaVd1OPI 79nt2H5yWo0PE2Kd2yAMnWJ/3clLR6X4jqkmpoc2uEPE6aM7iQ6SCx7rMFP9W9OvovnzVksS dh65JRkiA3DTUWBxZM6h/oEERBTr9Q/JYXXugO300loterwBVu0ymBHdAjIlxpetFwZu/Wlb nymC4VSxGPS/+mJ9Lnh3WWjVEcP5F9WgqmfJ49BNqOjmgZ9u9VYV8R9fOaYvtPFTdGTYT9iw JYic/0xt9NcW/hRkff0UHdiN/BrTxbHVI7Qf4MLBK/+VtqVi0MLs7U80/2fPRebTq4yQ6aoY 7hErExrJ7TgTmZghsBJTd2cmau26Kb7stLJ4ySADcyrsADl03MNoj8QqVuO8HXx2InM18sHP xldjovv8dhmj7uiKmMPAqq5f8pA5bcA/EQ6S+ItjjohSLiYQtq6UgDPlt4tIA9nCfx+cGi6f o4sJE0InaQLinm0USp0zE+slpqXGwjzeFSTioL81cDGhN3dcCK94VsntblsAEQEAAcLBZQQY AQgADwUCVu7ZFQIbDAUJC0c1AAAKCRBYD1kOlZ2qqdnTD/9fOyWwdhOv4ehtR8ShfhM1FAc8 bWMfCrxTpI4baPM4fqIFgMAJ9iQ0FF6cB0zQjDwsWNC+3t+2JdiNeM8FB7s4bbJlhjaavzKK 77Kbf4WpVs7ge0+Zghc2qHRg/SQeC1G26GzSZDDWzDHFZX0va8H0KmT/tHJYD263CIcff/E9 WXT/22rrgYvuQXPIOBzON9WqUkCAvPA19xuBsDQSbXkXwiPsZRqmyktjc8GQn1iemQ/dzlU/ e6ORNrPcK15kUyPyJMaZf+6QJ8EivUyg+pTXicEcghWNYHXxop4k0y+bsay0cBN2lmNu7UEF qhO8HQmp2jrwZXFZD/fbZukXFHNWvNsvQ55flUfajPZhUokXHskkerbq6ZCS58HkWl0tqSIb 5TxNfP0zjcrlDBc8sF6UHXgNR1oUXypGOAq4iHeJNVpI4aQm/PufmeGExx6lPtJxJ9jOs5gD rYRuBfa1cJznEPNbIe0/eCv5qDpf95csdGJhM418x2xeg58PbmBByS9MXOGFtli0K9sxIej/ YdA94hlk/R9ViIPDuqDxz0PP+IRFVVOQhOprSnG8cV31oOe00e1bIBH3ttdsgp3AHqz/zlfF kZt27s1VH+aRF4STntrU97dNmxrgjq8zUZ7VgYjq8KqLg0BsDRIy4b/AnptYh6E4oE74gKCo Qoim4V9DGw== X-Forwarded-Message-Id: <36ec5346-3b8c-f60e-879d-a95141273a9a@sec.uni-stuttgart.de> Message-ID: <0f3329c0-2544-f6ff-fb4f-577d347c37de@sec.uni-stuttgart.de> Date: Fri, 1 Jun 2018 18:19:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 MIME-Version: 1.0 In-Reply-To: <36ec5346-3b8c-f60e-879d-a95141273a9a@sec.uni-stuttgart.de> Content-Type: multipart/alternative; boundary="------------9747ECFA5BF28C3CA2EB77C6" Content-Language: de-DE Archived-At: Subject: [OAUTH-WG] Call for Papers: Conf on Security Standardisation Research (SSR 2018) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 16:20:08 -0000 This is a multi-part message in MIME format. --------------9747ECFA5BF28C3CA2EB77C6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, I didn't see this posted here before. This conference might be interesting for some of you. -Daniel -------- Forwarded Message -------- ------------------------------------------------------------------------ Conference on Security Standardisation Research (SSR) 2018 26-27 November 2018, Darmstadt, Germany https://ssr2018.net/ submissions due: 22nd June 2018 ------------------------------------------------------------------------ === Call For Papers === Papers offering research contributions to the area of security  standardisation are solicited for submission to the SSR 2018 conference.  Papers may present theory, applications or practical experience in the  field of security standardisation, including, but not necessarily  limited to: - access control - biometrics - cloud computing - critical national infrastructure (CNI) protection - consistency and comparison of multiple standards - critiques of standards - cryptanalysis - cryptographic protocols - cryptographic techniques - evaluation criteria - formal analysis of standards - history of standardization - identity management - industrial control systems security - internet security - interoperability of standards - intrusion detection - key management and PKIs - management of the standardisation process - mobile security - network security - open standards and open source - payment system security - privacy - regional and international standards - RFID tag security - risk analysis - security controls - security management - security protocols - security services - security tokens - smart cards - telecommunications security - trusted computing - web security New this year is that SSR will also accept Systematisation of Knowledge  (SoK) papers relating to security standardisation, which integrate  experience and previous research, drawing new comprehensive conclusions.  SoK papers should evaluate, systematise, and contextualise existing  knowledge. They should provide a new viewpoint, offer a comprehensive  taxonomy, or cast doubt on long-held beliefs, based on compelling  evidence. We also welcome SoK papers that document existing  standardisation practices and analyse their weaknesses and strengths. General Chair: Marc Fischlin (TU Darmstadt, Germany) Program Co-Chairs: Cas Cremers (University of Oxford, UK) Anja Lehmann (IBM Research - Zurich, Switzerland) Program Committee: Steve Babbage, Vodafone, UK Liqun Chen, University of Surrey, UK Jean Paul Degabriele, TU Darmstadt, Germany Antoine Delignat-Lavaud, Microsoft Research, UK Orr Dunkelman, University of Haifa, Israel Cedric Fournet, Microsoft Research, UK Britta Hale, Norwegian University of Science and Technology, Norway Harry Halpin, INRIA, France Tibor Jager, Paderborn University, Germany John Kelsey, NIST, USA Markulf Kohlweiss, University of Edinburgh, UK Stephan Krenn, AIT Austrian Institute of Technology, Austria Xuejia Lai, Shanghai Jiaotong University, China Tancrede Lepoint, SRI International, USA Peter Lipp, Graz University of Technology, Austria Atul Luykx, Visa Research, USA Catherine Meadows, Naval Research Laboratory, USA David Naccache, ENS, France Valtteri Niemi, University of Helsinki, Finland Kenneth Paterson, Royal Holloway, University of London, UK Eric Rescorla, Mozilla, USA Matt Robshaw, Impinj, USA Phillip Rogaway, University of California, Davis, USA Mark Ryan, University of Birmingham, UK Kazue Sako, NEC, Japan Peter Schwabe, Radboud University, The Netherlands Tom Shrimpton, University of Florida, USA Ben Smyth, University of Luxembourg, Luxembourg Douglas Stebila, McMaster University, Canada Claire Vishik, Intel Corporation, UK Michael Ward, MasterCard, UK William Whyte, Security Innovation, USA == Important Dates ==  Submission Deadline         Jun 22, 2018 Notification Due         Aug 22, 2018 Final Version Due         Sep 19, 2018  Conference                Nov 26-27, 2018 == Instructions for Authors == Submissions must be original and must not substantially duplicate work  that any of the authors has published elsewhere or has submitted in  parallel to any journal or to any other conference or workshop that has  published proceedings. Authors submitting a systematisation of knowledge paper should have a  title consisting of "SoK: Title". This is to ensure that the committee  is made aware that the paper is an SoK paper, and so will be reviewed  with different criteria. Submitted papers must be in PDF format and written in English. The  submission must be anonymous with no author names, affiliations or  obvious references. It should begin with a title, a short abstract, and  an introduction. Papers should be at most 16 pages (excluding  bibliography and appendices) in the standard LNCS format (see  instructions at http://www.springer.de/comp/lncs/authors.html.).  Reviewers are not obliged to read appendices, so the paper must be  self-contained without them. Papers that do not adhere to these requirements will be rejected without  consideration of their merits. Accepted papers will be presented at the conference and published in  Springer's Lecture Notes in Computer Science (LNCS) series. At least one  author of each accepted paper must register for the conference. Submission Site: Papers must be submitted using the EasyChair system. The link will be  provided on the conference website when the system is open for  submissions. --------------9747ECFA5BF28C3CA2EB77C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi all,

I didn't see this posted here before. This conference might be interesting for some of you.

-Daniel


-------- Forwarded Message --------


------------------------------------------------------------------------
Conference on Security Standardisation Research (SSR) 2018
26-27 November 2018, Darmstadt, Germany
https://ssr2018.net/
submissions due: 22nd June 2018
------------------------------------------------------------------------


=== Call For Papers ===


Papers offering research contributions to the area of security 
standardisation are solicited for submission to the SSR 2018 conference. 
Papers may present theory, applications or practical experience in the 
field of security standardisation, including, but not necessarily 
limited to:


- access control
- biometrics
- cloud computing
- critical national infrastructure (CNI) protection
- consistency and comparison of multiple standards
- critiques of standards
- cryptanalysis
- cryptographic protocols
- cryptographic techniques
- evaluation criteria
- formal analysis of standards
- history of standardization
- identity management
- industrial control systems security
- internet security
- interoperability of standards
- intrusion detection
- key management and PKIs
- management of the standardisation process
- mobile security
- network security
- open standards and open source
- payment system security
- privacy
- regional and international standards
- RFID tag security
- risk analysis
- security controls
- security management
- security protocols
- security services
- security tokens
- smart cards
- telecommunications security
- trusted computing
- web security


New this year is that SSR will also accept Systematisation of Knowledge 
(SoK) papers relating to security standardisation, which integrate 
experience and previous research, drawing new comprehensive conclusions. 
SoK papers should evaluate, systematise, and contextualise existing 
knowledge. They should provide a new viewpoint, offer a comprehensive 
taxonomy, or cast doubt on long-held beliefs, based on compelling 
evidence. We also welcome SoK papers that document existing 
standardisation practices and analyse their weaknesses and strengths.


General Chair:
Marc Fischlin (TU Darmstadt, Germany)


Program Co-Chairs:
Cas Cremers (University of Oxford, UK)
Anja Lehmann (IBM Research - Zurich, Switzerland)


Program Committee:
Steve Babbage, Vodafone, UK
Liqun Chen, University of Surrey, UK
Jean Paul Degabriele, TU Darmstadt, Germany
Antoine Delignat-Lavaud, Microsoft Research, UK
Orr Dunkelman, University of Haifa, Israel
Cedric Fournet, Microsoft Research, UK
Britta Hale, Norwegian University of Science and Technology, Norway
Harry Halpin, INRIA, France
Tibor Jager, Paderborn University, Germany
John Kelsey, NIST, USA
Markulf Kohlweiss, University of Edinburgh, UK
Stephan Krenn, AIT Austrian Institute of Technology, Austria
Xuejia Lai, Shanghai Jiaotong University, China
Tancrede Lepoint, SRI International, USA
Peter Lipp, Graz University of Technology, Austria
Atul Luykx, Visa Research, USA
Catherine Meadows, Naval Research Laboratory, USA
David Naccache, ENS, France
Valtteri Niemi, University of Helsinki, Finland
Kenneth Paterson, Royal Holloway, University of London, UK
Eric Rescorla, Mozilla, USA
Matt Robshaw, Impinj, USA
Phillip Rogaway, University of California, Davis, USA
Mark Ryan, University of Birmingham, UK
Kazue Sako, NEC, Japan
Peter Schwabe, Radboud University, The Netherlands
Tom Shrimpton, University of Florida, USA
Ben Smyth, University of Luxembourg, Luxembourg
Douglas Stebila, McMaster University, Canada
Claire Vishik, Intel Corporation, UK
Michael Ward, MasterCard, UK
William Whyte, Security Innovation, USA


== Important Dates == 
Submission Deadline         Jun 22, 2018
Notification Due         Aug 22, 2018
Final Version Due         Sep 19, 2018 
Conference                Nov 26-27, 2018


== Instructions for Authors ==
Submissions must be original and must not substantially duplicate work 
that any of the authors has published elsewhere or has submitted in 
parallel to any journal or to any other conference or workshop that has 
published proceedings.


Authors submitting a systematisation of knowledge paper should have a 
title consisting of "SoK: Title". This is to ensure that the committee 
is made aware that the paper is an SoK paper, and so will be reviewed 
with different criteria.


Submitted papers must be in PDF format and written in English. The 
submission must be anonymous with no author names, affiliations or 
obvious references. It should begin with a title, a short abstract, and 
an introduction. Papers should be at most 16 pages (excluding 
bibliography and appendices) in the standard LNCS format (see 
instructions at http://www.springer.de/comp/lncs/authors.html.). 
Reviewers are not obliged to read appendices, so the paper must be 
self-contained without them.


Papers that do not adhere to these requirements will be rejected without 
consideration of their merits.


Accepted papers will be presented at the conference and published in 
Springer's Lecture Notes in Computer Science (LNCS) series. At least one 
author of each accepted paper must register for the conference.


Submission Site:
Papers must be submitted using the EasyChair system. The link will be 
provided on the conference website when the system is open for 
submissions.
--------------9747ECFA5BF28C3CA2EB77C6-- From nobody Fri Jun 1 10:23:35 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D051D12D96A for ; Fri, 1 Jun 2018 10:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-stuttgart.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMPOHADxYMqi for ; Fri, 1 Jun 2018 10:23:30 -0700 (PDT) Received: from mxex2.tik.uni-stuttgart.de (mxex2.tik.uni-stuttgart.de [IPv6:2001:7c0:2041:24::a:2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66ED412D962 for ; Fri, 1 Jun 2018 10:23:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTP id 1DCF783183 for ; Fri, 1 Jun 2018 19:23:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=uni-stuttgart.de; h=content-language:content-type:content-type:in-reply-to :mime-version:user-agent:date:date:message-id:from:from :references:subject:subject:received:received; s=dkim; i= @sec.uni-stuttgart.de; t=1527873806; x=1529612607; bh=9ibTzMb7dC gACiGNQZ9KSM6+dZRYkCiJtYM5FKZUMYw=; b=VtZyBDjXY8Y7/o1d2g+xzuRyUq geOqDXEG/PAV0I/pMI+VH7e695B3/FhmS10o/yq5qMjFiO1zceKmdGmGBn5UdMi2 10uNxaVAMQR+L1RsFKBZvPijSrfsitIp1vXq7JapE+VfVaUzFdH1pl2m6AqLXd/I KdRsC5iO5rpU2PftbnBb0nou4Rn3HQR8CHfhpqxrzUQQu7iM9f5duWBqaRMKTPWX PUrkjD5jcCNXK1LrcBwXDEiGy5UIw7hpirP+7VRCe3MTQsQV0rXUdxvy5w7P2QhH Jp4s3/R2PVUuhsdrU9i+r8OrYVfYyzo+cul74foS/iv6wtxERnLAOPHLMjhg== X-Virus-Scanned: USTUTT mailrelay AV services at mxex2.tik.uni-stuttgart.de Received: from mxex2.tik.uni-stuttgart.de ([127.0.0.1]) by localhost (mxex2.tik.uni-stuttgart.de [127.0.0.1]) (amavisd-new, port 10031) with ESMTP id aqqspM8hWzI7 for ; Fri, 1 Jun 2018 19:23:26 +0200 (CEST) Received: from [IPv6:2001:7c0:2015:182::1:32] (unknown [IPv6:2001:7c0:2015:182::1:32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mxex2.tik.uni-stuttgart.de (Postfix) with ESMTPSA for ; Fri, 1 Jun 2018 19:23:26 +0200 (CEST) To: oauth@ietf.org References: From: Daniel Fett Openpgp: preference=signencrypt Autocrypt: addr=daniel.fett@sec.uni-stuttgart.de; prefer-encrypt=mutual; keydata= xsFNBFbu2RUBEAC3F5+IMjFcXSj46xS8QQe6d/FAb+7IkkOdFKrINhgCialH4enWB2V3ykOX xESdrchRBCLoePyNmoJdFTijGxBMGNqSKU9rrppF5uvPFv/qIvCaBDAjFXR+qshsHjsMxTNH 67kuhkFQczKQHs4KVICG/gnssC3iejrk6Mav0MIJKXXdz6bUQPDyUTD+LsyHJ7vNfkfitnO4 rbD+kEZ0n14dQqp+c91b7X5KZVTt1c3d/N1kbruS29SlIDUJSHV0AdDZmP6wuH5a9XUIlDkP mM2bncIry3xiXWolYf3BJigxYg1XwVMYBdsrVg4kID5WY1RCHns07cDGluERcurjj3QHjToL T7VemcnFVzSphjjisi9a1QfRYCPf5xw5L8IjsAuNTBLv2DXKtL6Mf5Tv9BAZPD2em0rNS5n/ M7S6D2AAxIt9BQQ4aS16faI0gfUspj09RLdHANwOcLUPu+OE+O2IdgglBQLkadwLj9aY0ncE 8GhqFWcQ9xbtvHAljYaz5VmsOnjsadfGD8xW+QtWeFc8mfq7PncRjrc0Ywtb8TKeXkLHUQoT 4v2ilXisfOhryVj6/GuQvDjKKyUBW1tQPxei4n/W0zBC4LWehmwCH+WrFt+mTh3uHSyy9VbR FYmY6MBBMUpHHVQ3AVLgxoldu/yX/ery+fdE8MeScAWg+WE5rQARAQABzSBEYW5pZWwgRmV0 dCA8ZmV0dEBkYW5pZWxmZXR0LmRlPsLBgAQTAQgAKgIbAwUJC0c1AAULCQgHAwUVCgkICwUW AgMBAAIeAQIXgAUCVu7cmAIZAQAKCRBYD1kOlZ2qqXCPD/wLpgL6j51OUlGzLaA+Xt+QzX/v qUiHJsvv1mEnyofk/3pGr7ce/1UNp7e8/W2JnnHvz4RBaNkn07DFyOvrVNXiMyU6mKWvG6xw Ri5Qc2t1Cup+mXlNc5fxlZGnwOYXZJErYVTPodkFlbb6LKUMyg6v2P7ZEvw4YyPh7WpV5ujF VVkYBSLviNCjVwKr8WlJJlVI4uvHZshnX85lVpRNcF+Hqf7IhnJzCQ5bUNnV7aKc4WPNw7L6 EquuCAl6JGKdeV2M+S5UVN9Eaa/CQxJf8X9I3SVgWCGQ/gLt0x1oKt6oFMECJcH2LDFOJyWv 61AUIzqCdRiTUagdc+7sn2OFbbjhKin9x+Qq6pyoXa6ZcpEuyBoAy+hNU8RAXcPgvEBy4Bwx BYQ9S3uQmBx/TcYgSUbBwBhvIYRVM5DfBefolj3HyUlvHx8JO8scbdcVl+v1+f9d5x4YS16t bWNe7awE6UWM2I02+uv7SI2ieJ2zQsOulDTEYVYjWcu0hBH24K53wniyh3JHzu6RVCgewx4P 6H2WHOSVf2p9ppuIrbWh7J6pp9nFdDXESKxH3GO5LooLamGugSlRwdgsqxY0O4BbCpKIpfe8 31peA+7qbh1f4TXHo/ZQE8fZ2s4VN5XR5J5/yjfqY2pWDy1XocixzXboLAcuzGmZNutS46eH Azjo2CxTa87BTQRW7tkVARAA1cAIBWNxYj/QE7RcOHGgr8xXcKWk/wwTWgLvjEbp5tqMl3Jk EwD1Iajz1s+Qp7U+U4UqyI+ZSfm03bYFYlTyKaS2esiM+Incutg18N943xwGNc6csyNoW5/f xbDQ4hoMKsod9zjfvxpA8xLg8gjuPKi5Y698K7qDCCfGvo6e67qwFWIvrB7cv/NAoaVd1OPI 79nt2H5yWo0PE2Kd2yAMnWJ/3clLR6X4jqkmpoc2uEPE6aM7iQ6SCx7rMFP9W9OvovnzVksS dh65JRkiA3DTUWBxZM6h/oEERBTr9Q/JYXXugO300loterwBVu0ymBHdAjIlxpetFwZu/Wlb nymC4VSxGPS/+mJ9Lnh3WWjVEcP5F9WgqmfJ49BNqOjmgZ9u9VYV8R9fOaYvtPFTdGTYT9iw JYic/0xt9NcW/hRkff0UHdiN/BrTxbHVI7Qf4MLBK/+VtqVi0MLs7U80/2fPRebTq4yQ6aoY 7hErExrJ7TgTmZghsBJTd2cmau26Kb7stLJ4ySADcyrsADl03MNoj8QqVuO8HXx2InM18sHP xldjovv8dhmj7uiKmMPAqq5f8pA5bcA/EQ6S+ItjjohSLiYQtq6UgDPlt4tIA9nCfx+cGi6f o4sJE0InaQLinm0USp0zE+slpqXGwjzeFSTioL81cDGhN3dcCK94VsntblsAEQEAAcLBZQQY AQgADwUCVu7ZFQIbDAUJC0c1AAAKCRBYD1kOlZ2qqdnTD/9fOyWwdhOv4ehtR8ShfhM1FAc8 bWMfCrxTpI4baPM4fqIFgMAJ9iQ0FF6cB0zQjDwsWNC+3t+2JdiNeM8FB7s4bbJlhjaavzKK 77Kbf4WpVs7ge0+Zghc2qHRg/SQeC1G26GzSZDDWzDHFZX0va8H0KmT/tHJYD263CIcff/E9 WXT/22rrgYvuQXPIOBzON9WqUkCAvPA19xuBsDQSbXkXwiPsZRqmyktjc8GQn1iemQ/dzlU/ e6ORNrPcK15kUyPyJMaZf+6QJ8EivUyg+pTXicEcghWNYHXxop4k0y+bsay0cBN2lmNu7UEF qhO8HQmp2jrwZXFZD/fbZukXFHNWvNsvQ55flUfajPZhUokXHskkerbq6ZCS58HkWl0tqSIb 5TxNfP0zjcrlDBc8sF6UHXgNR1oUXypGOAq4iHeJNVpI4aQm/PufmeGExx6lPtJxJ9jOs5gD rYRuBfa1cJznEPNbIe0/eCv5qDpf95csdGJhM418x2xeg58PbmBByS9MXOGFtli0K9sxIej/ YdA94hlk/R9ViIPDuqDxz0PP+IRFVVOQhOprSnG8cV31oOe00e1bIBH3ttdsgp3AHqz/zlfF kZt27s1VH+aRF4STntrU97dNmxrgjq8zUZ7VgYjq8KqLg0BsDRIy4b/AnptYh6E4oE74gKCo Qoim4V9DGw== Message-ID: Date: Fri, 1 Jun 2018 19:23:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AB021E7DC01BCEEA677DB905" Content-Language: de-DE Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 17:23:34 -0000 This is a multi-part message in MIME format. --------------AB021E7DC01BCEEA677DB905 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thank you Travis for your feedback! Am 20.03.18 um 12:48 schrieb Travis Spencer: > I read through this doc and would like to share a bit of feedback in > hopes that it helps: > > * There is no mention of Content Security Policy (CSP). This is a very > helpful security mechanism that all OAuth servers and web-based > clients should implement. I think this needs to be addressed in this > doc. > - No mention of frame breaking scripts for non-CSP aware user agent= s > - No mention of X-Frame-Options > * There's no mention of HSTS which all OAuth servers and web-based > client should implement (or the reverse proxies in front of them > should) If I see this correctly, all of these mechanisms fall in the category of "do web security right" that Jim mentioned, i.e., there are no concrete, OAuth-specific attacks that would be prevented by these. If so, I think we should not mention them in the document. > * The examples only use 302 and don't mention that 303 is safer[1] > - Despite what it says in section 1.7 of RFC 6749, many people > think that a 302 is mandated by OAuth. It would be good to recommend a > 303 and use examples with other status codes. Yes, we should address that. > [1] https://arxiv.org/pdf/1601.01229v2.pdf (That link, by the way, points to an old version of our paper. There is an updated version with more attacks and a better presentation: https://arxiv.org/pdf/1601.01229.pdf) Thanks again for your feedback! -Daniel --=20 SEC - Institute of Information Security University of Stuttgart Phone +49 711 685 88468 Universit=C3=A4tsstra=C3=9Fe 38 - 70569 Stuttgart - Room 2.434 --------------AB021E7DC01BCEEA677DB905 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Thank you Travis for your feedback!

Am 20.03.18 um 12:48 schrieb Travis Spencer:
I read through this doc and would like to share a bit of feedback in
hopes that it helps:

* There is no mention of Content Security Policy (CSP). This is a very
helpful security mechanism that all OAuth servers and web-based
clients should implement. I think this needs to be addressed in this
doc.
    - No mention of frame breaking scripts for non-CSP aware user agents
    -  No mention of X-Frame-Options
* There's no mention of HSTS which all OAuth servers and web-based
client should implement (or the reverse proxies in front of them
should)

If I see this correctly, all of these mechanisms fall in the category of "do web security right" that Jim mentioned, i.e., there are no concrete, OAuth-specific attacks that would be prevented by these. If so, I think we should not mention them in the document. 

* The examples only use 302 and don't mention that 303 is safer[1]
   - Despite what it says in section 1.7 of RFC 6749, many people
think that a 302 is mandated by OAuth. It would be good to recommend a
303 and use examples with other status codes.

Yes, we should address that.

[1] https://arxiv.org/pdf/1601.01229v2.pdf

(That link, by the way, points to an old version of our paper. There is an updated version with more attacks and a better presentation: https://arxiv.org/pdf/1601.01229.pdf)

Thanks again for your feedback!

-Daniel


-- 
SEC - Institute of Information Security
University of Stuttgart
Phone +49 711 685 88468
Universitätsstraße 38 - 70569 Stuttgart - Room 2.434
--------------AB021E7DC01BCEEA677DB905-- From nobody Fri Jun 1 11:48:03 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA45112DA1A for ; Fri, 1 Jun 2018 11:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvA0AfKiwZrx for ; Fri, 1 Jun 2018 11:47:47 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413B812E059 for ; Fri, 1 Jun 2018 11:47:42 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id j186-v6so2997577ita.5 for ; Fri, 01 Jun 2018 11:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9LfbhvPipDvqVRKAGx2HTGJwgtQnR6TATbaYtYLIWp4=; b=RKt8pVGphoQYX5iSxYiEA+7y6wJkTLAQNr+mUn1inxqff/rHYYwx4qotguClSu9k07 5WTu2oht5t2vhfhv9laTVTxE3Ao7sN8W94LdoLEA7yUGtK7WscuioQTvfN4kaeskEty1 AUkznAjuRMwDDmzSEuCq7/Vtzo1VjyEraCVYo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9LfbhvPipDvqVRKAGx2HTGJwgtQnR6TATbaYtYLIWp4=; b=d+vqTkMZEJLRJ8/nzhcd2qyv6QM5e19K72MWBhdccYkEAjzXstA+xG9p4M/fyDAjr4 hgk30fCWuLc7/m4O0DxW57DMybo0/y+42hb3GeoHkIk8Str1U6df2nD56B+PU6sfXkxD ML4XpUpxMaGcZugiU30/nkw37Gp7jT2GYbc2Db/skCDrfh90QhSHVp7rXj41peFnz3q3 aL6kL/mBjosKMcW3OpIxXJNF+knMnoKwl8EURdQKYD1gP9HTyQUwhoVIs1D5I58YcFsP G5UMAkr/nZo16gN9YHRr9i1sfKOkEIS7ajXtrlvNFx4bsyPXuyEEOScKSJDIoLPTm6+x FR1w== X-Gm-Message-State: ALKqPwcCOMsgrsuxO6l1Si4FscZmkvdEmOCdqkMcE7IX5v1Vbeb+zL6x 5j6i6cgHsh6xWulHcPJkhnbvGT20cnade+WXv8FSr1fVVRuqXJBU7AdYsXfpNn1pmsGUEKYUoh4 u31RWh4YPOdFwX+/z X-Google-Smtp-Source: ADUXVKIfMKJzfUOvFwShUa0i4Nm7AjySI5wOsv7eHdMx6oRF3RKLX5JoMih40gk47GQvJPpNBDLzj4H/+2w/bcD9H9k= X-Received: by 2002:a24:1f4a:: with SMTP id d71-v6mr5457302itd.53.1527878861302; Fri, 01 Jun 2018 11:47:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 11:47:10 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 1 Jun 2018 12:47:10 -0600 Message-ID: To: Eric Rescorla Cc: Bill Burke , Mike Jones , oauth Content-Type: multipart/alternative; boundary="000000000000c9c8cf056d99044e" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 18:48:02 -0000 --000000000000c9c8cf056d99044e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, Apologies for my somewhat slow response. I've honestly been unsure of how else to try and address the comment/question. But will continue trying... My expectation would be that access control decisions would be made based on the subject of the token itself or on the current actor. And maybe a combination of both in some situations (like, for example, the actor is an administrator and the token allows admin level access to the stuff the token subject would normally have access to). However, I don't believe that nested prior actors would or should be considered in access control decisions. The nesting is more just to express what has happened for auditing or tracking or the like. To be honest, the nesting was added in the draft largely because the structure naturally and easily allowed for it and it seemed like it might be useful information to convey in some cases. So in that A->B->C case (the claims of such a token would, I think, look like the JSON below), B *is not* giving C his authority. B is just noted in the token as having been involved previously. While A is identified as the subject of the token and C is the current actor. { "aud":"... ,"iss":... , "exp":..., etc. etc. ... "sub":"A", "act": { "sub":"C", "act": { "sub":"B" } } } Would some text explicitly saying that only the token subject (top level sub and claims) and the party identified by the outermost "act" claim (the current actor) are to be considered in access control decisions address your concern? On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla wrote: > Hi Brian, > > To be clear, I'm not opposing Delegation. My concern here is that we have > a chain of signed assertions and I'm trying to understand how I as a > consumer of those assertions am supposed to evaluate it. > > I don't think it's sufficient to just say that that the access control > rules are local policy, because then the entity generating the signature > has no way of knowing how its signature will be used. > > To go back to the case I gave in my initial e-mail, say we have a chain > A->B->C and a resource that A and C could ordinarily not access, but B ca= n. > If C has this delegation, can C access the resource? I.e., is B giving C > his authority or just passing on A's authority? It seems pretty important > for B to know that before he gives the token to C. > > -Ekr > > > On Thu, May 17, 2018 at 11:06 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Delegation has been in the document since its inception and throughout >> the three and a half years as a working group document. >> >> From a process point of view, the document is now in AD Evaluation. I >> worked through a number of questions and clarifications with Eric (said >> AD), however he raised the particular questions that started this thread= on >> the WG list. And I responded with an attempt at addressing those questio= ns. >> That was about a month ago. >> >> Eric, was my explanation helpful in clarify anything for you? Is there >> some text that you'd like to see added? Something else? I'm unsure how t= o >> proceed but would like to move things forward. >> >> >> On Thu, May 17, 2018 at 8:03 AM, Bill Burke wrote: >> >>> This is an honest question: How important is the actor stuff to the >>> players involved? Are people going to use it? IMO, its an edge case >>> and I think more important areas, like external token exchange (realm >>> to realm, domain to domain) are being neglected. I'm quite unfamiliar >>> how consensus is reached in this WG or the IETF, so I hope I'm not >>> sounding rude. Just trying to provide some constructive feedback. >>> >>> >>> >>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones >>> wrote: >>> > Moving the actor claim to a separate specification would only make >>> things more complicated for developers. There already plenty of OAuth >>> specs. Needlessly adding another one will only make related things har= der >>> to find. >>> > >>> > Just like in the JWT [RFC 7519] spec itself in which use of all the >>> claims is optional, use of the actor claim in this spec. If you don't = need >>> it, don't use it. Just because some won't use it is no better an argum= ent >>> for moving it to a different spec than the argument that JWT should hav= e >>> defined each of its claims in different specs. That would have made th= ings >>> harder, not easier. >>> > >>> > -- Mike >>> > >>> > -----Original Message----- >>> > From: OAuth On Behalf Of Bill Burke >>> > Sent: Thursday, May 17, 2018 2:11 PM >>> > To: Brian Campbell >>> > Cc: oauth >>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang >>> e-12.txt >>> > >>> > My personal opinion is that I'm glad this actor stuff is optional. >>> > For one, none of our users have asked for it and really only do simpl= e >>> exchanges. Secondly, the rules for who can exchange what for what is >>> controlled and defined within our AS. Makes things a lot simpler on th= e >>> client. I kind of wish the actor stuff would be defined in a separate >>> specification. I don't see us implementing it unless users start askin= g us >>> to. >>> > >>> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >> Well, it's already called the "actor claim" so the claimed part is >>> >> kind of implied. And "claimed actor claim" is a rather awkward. >>> >> Really, all JWT claims are "claimed something" but they don't includ= e >>> >> the "claimed" bit in the name. RFC 7519, for example, defines the >>> >> subject claim but not the claimed subject claim. >>> >> >>> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: >>> >>> >>> >>> Brian, >>> >>> >>> >>> Eric said: "what is the RP supposed to do when they encounter it? >>> >>> This seems kind of under specified". >>> >>> >>> >>> After reading your explanations below, it looks like the RP can do >>> >>> anything he wants with the "actor". >>> >>> It is a "claimed actor" and, if we keep the concept, it should be >>> >>> called as such. Such a claim cannot be verified. >>> >>> A RP could copy and paste that claim in an audit log. No standard >>> >>> action related to the content of such a claim can be specified in t= he >>> >>> spec. If the content of a "claimed actor" is used by the RP, it >>> >>> should be only used as an hint and thus be subject to other >>> >>> verifications which are not specified in this specification. >>> >>> >>> >>> Denis >>> >>> >>> >>> Eric, I realize you weren't particularly impressed by my prior >>> >>> statements about the actor claim but, for lack of knowing what else >>> >>> to say, I'm going to kind of repeat what I said about it over in th= e >>> >>> Phabricator tool and add a little color. >>> >>> >>> >>> The actor claim is intended as a way to express that delegation has >>> >>> happened and identify the entities involved. Access control or othe= r >>> >>> decisions based on it are at the discretion of the consumer of the >>> >>> token based on whatever policy might be in place. >>> >>> >>> >>> There are JWT claims that have concise processing rules with respec= t >>> >>> to whether or not the JWT can be accepted as valid. Some examples >>> are "aud" >>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from RF= C >>> 7519. >>> >>> E.g. if the token is expired or was intended for someone or somethi= ng >>> >>> else, reject it. >>> >>> >>> >>> And there are JWT claims that appropriately don't specify such >>> >>> processing rules and are solely statements of fact or circumstance. >>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) claim= s >>> are good examples of such. >>> >>> There might be application or policy specific rules applied to the >>> >>> content of those kinds of claims (e.g. only subjects from a >>> >>> particular organization are able to access tenant specific data or, >>> >>> less realistic but still possible, disallow access for tokens issue= d >>> >>> outside of regular business >>> >>> hours) but that's all outside the scope of a specification's >>> >>> definition of the claim. >>> >>> >>> >>> The actor claim falls into the latter category. It's a way for the >>> >>> issuer of the token to tell the consumer of the token what is going >>> >>> on. But any action to take (or not) based on that information is at >>> >>> the discretion of the token consumer. I honestly don't know it coul= d >>> >>> be anything more. And don't think it should be. >>> >>> >>> >>> There are two main expected uses of the actor claim (that I'm aware >>> >>> of >>> >>> anyway) that describing here might help. Maybe. One is a human to >>> >>> human delegation case like a customer service rep doing something o= n >>> >>> behalf of an end user. The subject would be that user and the actor >>> >>> would be the customer service rep. And there wouldn't be any chaini= ng >>> >>> or nesting of the actor. The other case is so called service chaini= ng >>> >>> where a system might exchange a token it receives for a new token >>> >>> that it can use to call a downstream service. And that service in >>> >>> turn might do another exchange to get a new token suitable to call >>> >>> yet another downstream service. And again and so on and turtles all >>> >>> the way. I'm not necessarily endorsing that level of granularity in >>> >>> chaining but it's bound to happen somewhere/sometime. The nested >>> >>> actor claim is able to express that all that has happened with the >>> >>> top level or outermost one being the system currently using the tok= en >>> >>> and prior systems being nested.. What actually gets done with that >>> >>> information is up to the respective systems involved. There might b= e >>> >>> policy about what system is allowed to call what other system that = is >>> >>> enforced. Or maybe the info is just written to an audit log >>> >>> somewhere. Or something else. I don't know. But whatever it is >>> application/deployment/policy dependent and not specifiable by a spec. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla wrote= : >>> >>>> >>> >>>> Hi folks, >>> >>>> >>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem >>> >>>> generally OK. I do still have one remaining concern, which is abou= t >>> >>>> the actor claim. Specifically, what is the RP supposed to do when >>> >>>> they encounter it? This seems kind of underspecified. >>> >>>> >>> >>>> In particular: >>> >>>> >>> >>>> 1. What facts am I supposed to know here? Merely that everyone in >>> >>>> the chain signed off on the next person in the chain acting as >>> them? >>> >>>> >>> >>>> 2. Am I just supposed to pretend that the person presenting the >>> token >>> >>>> is the identity at the top of the chain? Say I have the >>> >>>> delegation A -> B -> C, and there is some resource which >>> >>>> B can access but A and C cannot, should I give access? >>> >>>> >>> >>>> I think the first question definitely needs an answer. The second >>> >>>> question I guess we could make not answer, but it's pretty hard to >>> >>>> know how to make a system with this left open.. >>> >>>> >>> >>>> -Ekr >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> OAuth mailing list >>> >>>> OAuth@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>>> >>> >>> >>> >>> >>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>> >>> privileged material for the sole use of the intended recipient(s). >>> >>> Any review, use, distribution or disclosure by others is strictly >>> >>> prohibited.. If you have received this communication in error, >>> >>> please notify the sender immediately by e-mail and delete the messa= ge >>> >>> and any file attachments from your computer. Thank you. >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >> >>> >> >>> >> CONFIDENTIALITY NOTICE: This email may contain confidential and >>> >> privileged material for the sole use of the intended recipient(s). A= ny >>> >> review, use, distribution or disclosure by others is strictly >>> >> prohibited.. If you have received this communication in error, plea= se >>> >> notify the sender immediately by e-mail and delete the message and a= ny >>> >> file attachments from your computer. Thank you. >>> >> _______________________________________________ >>> >> OAuth mailing list >>> >> OAuth@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/oauth >>> >> >>> > >>> > >>> > >>> > -- >>> > Bill Burke >>> > Red Hat >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> -- >>> Bill Burke >>> Red Hat >>> >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000c9c8cf056d99044e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Apologies for = my somewhat slow response. I've honestly been unsure of how else to try= and address the comment/question. But will continue trying...=C2=A0

My expectation would be that access control decisio= ns would be made based on the subject of the token itself or on the current= actor. And maybe a combination of both in some situations (like, for examp= le, the actor is an administrator and the token allows admin level access t= o the stuff the token subject would normally have access to).=C2=A0 However= , I don't believe that nested prior actors would or should be considere= d in access control decisions. The nesting is more just to express what has= happened for auditing or tracking or the like. To be honest, the nesting w= as added in the draft largely because the structure naturally and easily al= lowed for it and it seemed like it might be useful information to convey in= some cases.

So in that A->B->C case (t= he claims of such a token would, I think, look like the JSON below), B i= s not giving C his=C2=A0authority. B is just noted in the token as havi= ng been involved previously.=C2=A0 While A is identified as the subject of = the token and C is the current actor. 

    {
      "aud":"... ,"iss":... , "exp":...,=
 etc. etc. ...
      "sub":"A",
      "act":
      {
        "sub":"C",
        "act":
        {
          "sub":"B"
        }
      }
    }

Would some text explicitly saying that only the t= oken subject (top level sub and claims) and the party identified by the out= ermost "act" claim (the current actor) are to be considered in ac= cess control decisions address your concern?


On Tue, May 29, = 2018 at 4:19 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi Brian,

<= div>To be clear, I'm not opposing Delegation. My concern here is that w= e have a chain of signed assertions and I'm trying to understand how I = as a consumer of those assertions am supposed to evaluate it.
I don't think it's sufficient to just say that that the= access control rules are local policy, because then the entity generating = the signature has no way of knowing how its signature will be used.

To go back to the case I gave in my initial e-mail, say w= e have a chain A->B->C and a resource that A and C could ordinarily n= ot access, but B can. If C has this delegation, can C access the resource? = I.e., is B giving C his authority or just passing on A's authority? It = seems pretty important for B to know that before he gives the token to C.

-Ekr


On Thu, Ma= y 17, 2018 at 11:06 AM, Brian Campbell <bcampbell@pingidentity.co= m> wrote:
=
Delegation has been in the document= since its inception and throughout the three and a half years as a working= group document.

From a process point of view= , the document is now in=C2=A0AD Evaluation. I worked through a number of q= uestions and clarifications with Eric (said AD), however he raised the part= icular questions that started this thread on the WG list. And I responded w= ith an attempt at addressing those questions. That was about a month ago. <= br>

Eric, was my explanation helpful in clarify an= ything for you? Is there some text that you'd like to see added? Someth= ing else? I'm unsure how to proceed but would like to move things forwa= rd.


On Thu, May 17, 2018 at 8:03 A= M, Bill Burke <bburke@redhat.com> wrote:
This is an honest question: How important is the actor stuff= to the
players involved?=C2=A0 Are people going to use it?=C2=A0 IMO, its an edge = case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.=C2=A0 I'm quite unfami= liar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.=C2=A0 Just trying to provide some constructive feedback.



On Thu, May 17, 2018 at 9:26 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:
> Moving the actor claim to a separate specification would only make thi= ngs more complicated for developers.=C2=A0 There already plenty of OAuth sp= ecs.=C2=A0 Needlessly adding another one will only make related things hard= er to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the cl= aims is optional, use of the actor claim in this spec.=C2=A0 If you don'= ;t need it, don't use it.=C2=A0 Just because some won't use it is n= o better an argument for moving it to a different spec than the argument th= at JWT should have defined each of its claims in different specs.=C2=A0 Tha= t would have made things harder, not easier.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell <bcampbell@pingidentity.com>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.=
> For one, none of our users have asked for it and really only do simple= exchanges.=C2=A0 Secondly, the rules for who can exchange what for what is= controlled and defined within our AS.=C2=A0 Makes things a lot simpler on = the client.=C2=A0 I kind of wish the actor stuff would be defined in a sepa= rate specification.=C2=A0 I don't see us implementing it unless users s= tart asking us to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Well, it's already called the "actor claim" so the c= laimed part is
>> kind of implied. And "claimed actor claim" is a rather a= wkward.
>> Really, all JWT claims are "claimed something" but they = don't include
>> the "claimed" bit in the name. RFC 7519, for example, de= fines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encou= nter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP ca= n do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept,= it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No stand= ard
>>> action related to the content of such a claim can be specified= in the
>>> spec. If the content of a "claimed actor" is used by= the RP, it
>>> should be only used as an hint and thus be subject to other >>> verifications which are not specified in this specification. >>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my p= rior
>>> statements about the actor claim but, for lack of knowing what= else
>>> to say, I'm going to kind of repeat what I said about it o= ver in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegatio= n has
>>> happened and identify the entities involved. Access control or= other
>>> decisions based on it are at the discretion of the consumer of= the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with r= espect
>>> to whether or not the JWT can be accepted as valid. Some examp= les are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf&q= uot; (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or so= mething
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify = such
>>> processing rules and are solely statements of fact or circumst= ance.
>>> Also from RFC 7519, the "sub" (Subject) and "ia= t" (Issued At) claims are good examples of such.
>>> There might be application or policy specific rules applied to= the
>>> content of those kinds of claims (e.g. only subjects from a >>> particular organization are able to access tenant specific dat= a or,
>>> less realistic but still possible, disallow access for tokens = issued
>>> outside of regular business
>>> hours) but that's all outside the scope of a specification= 's
>>> definition of the claim.
>>>
>>> The actor claim falls into the latter category. It's a way= for the
>>> issuer of the token to tell the consumer of the token what is = going
>>> on. But any action to take (or not) based on that information = is at
>>> the discretion of the token consumer. I honestly don't kno= w it could
>>> be anything more. And don't think it should be.
>>>
>>> There are two main expected uses of the actor claim (that I= 9;m aware
>>> of
>>> anyway) that describing here might help. Maybe. One is a human= to
>>> human delegation case like a customer service rep doing someth= ing on
>>> behalf of an end user. The subject would be that user and the = actor
>>> would be the customer service rep. And there wouldn't be a= ny chaining
>>> or nesting of the actor. The other case is so called service c= haining
>>> where a system might exchange a token it receives for a new to= ken
>>> that it can use to call a downstream service. And that service= in
>>> turn might do another exchange to get a new token suitable to = call
>>> yet another downstream service. And again and so on and turtle= s all
>>> the way. I'm not necessarily endorsing that level of granu= larity in
>>> chaining but it's bound to happen somewhere/sometime. The = nested
>>> actor claim is able to express that all that has happened with= the
>>> top level or outermost one being the system currently using th= e token
>>> and prior systems being nested.. What actually gets done with = that
>>> information is up to the respective systems involved. There mi= ght be
>>> policy about what system is allowed to call what other system = that is
>>> enforced. Or maybe the info is just written to an audit log >>> somewhere. Or something else. I don't know. But whatever i= t is application/deployment/policy dependent and not specifiable by a spec.=
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I've gone over draft-ietf-oauth-token-exchange-12= and things seem
>>>> generally OK. I do still have one remaining concern, which= is about
>>>> the actor claim. Specifically, what is the RP supposed to = do when
>>>> they encounter it? This seems kind of underspecified.
>>>>
>>>> In particular:
>>>>
>>>> 1. What facts am I supposed to know here? Merely that ever= yone in
>>>>=C2=A0 =C2=A0 the chain signed off on the next person in th= e chain acting as them?
>>>>
>>>> 2. Am I just supposed to pretend that the person presentin= g the token
>>>>=C2=A0 =C2=A0 is the identity at the top of the chain? Say = I have the
>>>>=C2=A0 =C2=A0 delegation A -> B -> C, and there is so= me resource which
>>>>=C2=A0 =C2=A0 B can access but A and C cannot, should I giv= e access?
>>>>
>>>> I think the first question definitely needs an answer. The= second
>>>> question I guess we could make not answer, but it's pr= etty hard to
>>>> know how to make a system with this left open..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d
>>> privileged material for the sole use of the intended recipient= (s).
>>> Any review, use, distribution or disclosure by others is stric= tly
>>> prohibited..=C2=A0 If you have received this communication in = error,
>>> please notify the sender immediately by e-mail and delete the = message
>>> and any file attachments from your computer. Thank you.
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s).= Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited..=C2=A0 If you have received this communication in erro= r, please
>> notify the sender immediately by e-mail and delete the message and= any
>> file attachments from your computer. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth=



--
Bill Burke
Red Hat


CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000c9c8cf056d99044e-- From nobody Fri Jun 1 13:49:20 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B458512E040; Fri, 1 Jun 2018 13:49:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152788615069.14980.2173591179601354312@ietfa.amsl.com> Date: Fri, 01 Jun 2018 13:49:10 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-device-flow-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 20:49:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Device Flow for Browserless and Input Constrained Devices Authors : William Denniss John Bradley Michael B. Jones Hannes Tschofenig Filename : draft-ietf-oauth-device-flow-10.txt Pages : 19 Date : 2018-06-01 Abstract: This OAuth 2.0 authorization flow for browserless and input constrained devices, often referred to as the device flow, enables OAuth clients to request user authorization from devices that have an Internet connection, but don't have an easy input method (such as a smart TV, media console, picture frame, or printer), or lack a suitable browser for a more traditional OAuth flow. This authorization flow instructs the user to perform the authorization request on a secondary device, such as a smartphone. There is no requirement for communication between the constrained device and the user's secondary device. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-device-flow-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 1 13:56:25 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D64412DA4F for ; Fri, 1 Jun 2018 13:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H99siYllWijs for ; Fri, 1 Jun 2018 13:56:20 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB1112DA19 for ; Fri, 1 Jun 2018 13:56:19 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id c23-v6so11702350uan.3 for ; Fri, 01 Jun 2018 13:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rp/+Z2pEF9cV1Q91XiXMC+aSc0strB3tIo7dN5mSWjY=; b=CGNDVDfhOE0oi9zD6ICArQqX8Wi67JMjwvPE2SYcXf1BDZNTiBK7FITsNdMkIS0XtN FxHC0rT5VmE414DMocLqQQDJAzPw4wNAK7y6Tw5rtwJhLMsyN00yk2vA8PVzPM/J/Aqy xvvSS7MWk5JMLCWifU7g4B/ZY/HrP/3t+8x+LMNtLSzaekcY8/vgKqZz+eJxF2/nG4TU 92H7Fy3a8HLRExUuVIod2SmU61w496qxiUAEXg7K8TrhOnNzgeU6Zph9Ewz2gkFzUiMb +8c3TOuXtiwuMW+gRC24/oHH7FKNf0Nzf2ik7QaqL7kMg4q1CStWTlW/NbC27oHQdzI4 Hg9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rp/+Z2pEF9cV1Q91XiXMC+aSc0strB3tIo7dN5mSWjY=; b=rAmewfIy6LbVA6k3k6fgSXwDLydyq+YF2h0v7EzqBwkcmTXwf4kFnTABIeP008ahuq kgSseUeicQiauKzTUEBrdiiw7yPRvMG2qgfP7lfewygMDlz0iFcXyI5sQPBqEnFSfxm3 pOvGkvWGKoPfb2QnN6ezBrmaO9nvl63STs1fdimvKLrwX/bjGqbJeCpmQ4HnhJZDP4xt CIN1E8q6vpD1haUDT6oCDWS87c7tGh9sjAj1idGDdxo6/9PPPVyB7TY43PgcZxCNY1Jb Fm5D8viA/U6MjkM5oWxAuN08B7Gy705YRdGFF9L3m+JgeTc8eX+2GL4O818EgGluru8M N2rg== X-Gm-Message-State: APt69E3eEVSQJu3ZK8efoQ7WXfq5aOXwKDmddcx6hAjo2UKpZ+MdRD4P iXFP4ZtxvR3YdaCurI4d58JgvlcxErgdLI6bq75Nkg== X-Google-Smtp-Source: ADUXVKJraGpr4fhmxmZ/Tv4F1SiNYQ3+Nhk9Ptt5zxP2jxshq0k/1FwO0QhGhKjFxS6exY9zyC1WAsaj8k1ne7Y10Wo= X-Received: by 2002:a9f:3a47:: with SMTP id r7-v6mr1630993uag.198.1527886578309; Fri, 01 Jun 2018 13:56:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:2110:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 13:55:57 -0700 (PDT) In-Reply-To: References: <152763243091.27698.7723369435827878398.idtracker@ietfa.amsl.com> From: William Denniss Date: Fri, 1 Jun 2018 13:55:57 -0700 Message-ID: To: Brian Campbell Cc: William Denniss , Andrew Sciberras , draft-ietf-oauth-device-flow@ietf.org, oauth-chairs@ietf.org, ietf@ietf.org, oauth Content-Type: multipart/alternative; boundary="000000000000c26c65056d9ad09c" Archived-At: Subject: Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 20:56:23 -0000 --000000000000c26c65056d9ad09c Content-Type: text/plain; charset="UTF-8" On Thu, May 31, 2018 at 9:49 AM, Brian Campbell wrote: > > > On Wed, May 30, 2018 at 6:06 PM, William Denniss > wrote: > >> >> On Wed, May 30, 2018 at 3:48 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> I realize this is somewhat pedantic but I don't think referencing 4.1.2.1 >>> works given how RFC 6749 set things up. Rather I believe that the device >>> flow needs to define and register "access_denied" as a valid token >>> endpoint >>> response error code (it's not a token endpoint response error per RFC >>> 6749 >>> sec 5.2 nor has it been registered https://www.iana.org/assignmen >>> ts/oauth-parameters/oauth-parameters.xhtml#extensions-error >>> >>> ). Also >>> invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 >>> so >>> that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1 >>> defines errors >>> returned >>> from the authorization endpoint. But the device flow errors are from the >>> token endpoint. >>> >>> >> Yes, that's true. It's still the token endpoint, so 5.2 does in fact >> apply, it's just we're mixing in authorization-style actions which were not >> previously considered/used for that endpoint. >> >> Do you have any proposed text to resolve this? >> >> > > Sure, here's a crack at some text/changes: > > > Add this to the list of error codes in section 3.5.: > > "access_denied > The end-user denied the authorization request." > > > And add this to section 7.2.1.: > > "o Error name: access_denied > o Error usage location: Token endpoint response > o Related protocol extension: [[ this specification ]] > o Change controller: IETF > o Specification Document: Section 3.5 of [[ this specification ]]" > > > I might also slightly change this text in section 3.5: > > "In addition to the error codes defined in Section 5.2 of [RFC6749], > the following error codes are specific for the device flow:" > > to > > "In addition to the error codes defined in Section 5.2 of [RFC6749], > the following error codes are specified by the device flow:" > > so that the wording doesn't read as prohibiting the error codes from being > used outside the device flow (access_denied from the token endpoint might > well be useful for other grant types). > > > And add "Andrew Sciberras" to the Acknowledgements. > Thank you Andrew for raising the point about needing to explicitly document this error code, and Brian for your proposed text to resolve this, and for the other issues you raised. Version 10 has been posted by the authors to resolve the feedback received so far during this last call: https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10 --000000000000c26c65056d9ad09c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, May 31, 2018 at 9:49 AM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:


On Wed, May 30, 2018 at 6:06 PM, William Denniss <wdenniss@= google.com> wrote:

On Wed, May 30, 2018 at 3:48 PM, Brian Campbell &= lt;bcampbel= l@pingidentity.com> wrote:
I realize this is somewhat pedantic but I don't = think referencing 4.1.2.1
works given how RFC 6749 set things up. Rather I believe that the device flow needs to define and register "access_denied" as a valid toke= n endpoint
response error code (it's not a token endpoint response error per RFC 6= 749
sec 5.2 nor has it been registered https://www.iana.org/assignmen
ts/oauth-parameters/oauth-parameters.xhtml#extensions-error).= =C2=A0 Also
invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so=
that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
 <https://tools.ietf.org/html/rfc6749#sectio= n-4.1.2> defines errors returned
from the authorization endpoint. But the device flow errors are from the token endpoint.


Yes, that's true. It's still the token endpoint, so 5.2 does in fa= ct apply, it's just we're mixing in authorization-style actions whi= ch were not previously considered/used for that endpoint.

Do you have any proposed text to resolve this?
=C2=A0

Sure, here's a crack at some text/changes:


Add this to the list of error codes in section 3.5.= :

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "access_denied
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= The end-user denied the authorization request."


And add this to section 7.2.1.:

=C2=A0 "o=C2=A0 Error name: access_denied
=C2=A0=C2=A0= o=C2=A0 Error usage location: Token endpoint response
=C2=A0=C2=A0 o=C2= =A0 Related protocol extension: [[ this specification ]]
=C2=A0=C2=A0 o= =C2=A0 Change controller: IETF
=C2=A0=C2=A0 o=C2=A0 Specification Docume= nt: Section 3.5 of [[ this specification ]]"


I might also slightly change this text in section 3.5:

"In addition to the error codes defined in Section 5.2 of [RFC6749],<= br>=C2=A0=C2=A0 the following error codes are specific for the device flow:= "

to

"In addition to the error codes defined in Secti= on 5.2 of [RFC6749],
=C2=A0=C2=A0 the following error codes are s= pecified by the device flow:"

so that the wording doesn't read as prohib= iting the error codes from being used outside the device flow (access_denie= d from the token endpoint might well be useful for other grant types).
=


<= /div>
And add "Andrew Sciberras" to the= Acknowledgements.=C2=A0

Thank you Andrew for raising the point about needing to= explicitly document this error code, and Brian for your proposed text to r= esolve this, and for the other issues you raised.

Vers= ion 10 has been posted by the authors to resolve the feedback received so f= ar during this last call:=C2=A0https://tools.ietf.or= g/html/draft-ietf-oauth-device-flow-10


--000000000000c26c65056d9ad09c-- From nobody Fri Jun 1 14:48:09 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7797212DA1C for ; Fri, 1 Jun 2018 14:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzM3BmtQ6sIS for ; Fri, 1 Jun 2018 14:48:03 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCDA12DA54 for ; Fri, 1 Jun 2018 14:48:02 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id n1-v6so30928493otf.7 for ; Fri, 01 Jun 2018 14:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I4ZXuuYTlkO6V36B0AGbKVG4q/ciI3RStRNOaHRkcck=; b=VOfGEfGvgN2/CEB9kwgjYg+/xcVqegTvlk3iobAbceheg4WzBykjmSwg70ATTyvknR P8xdFTbzhRIcuPRwNMgRphXap/tMQpycGOFs/SoMHlqUjbjBCeDiyYkJHwbzLnjZdDBY 7CMu1g0xQ3AVurZBkQlPyE/HIlkOek4DPZ8qTRBiAIjyGXDT6I7OqUD+Pt91RwW4Uu14 r+73DC1z71ejY6H1AQ2Mqyyd5QGbBTqMQnKmeAWhAfht0j06Ek+9HgKLo9StjfhxfDz1 yAbkYuFLHIM0A2LzCDRQnRyDqFxOj44sga25/el+uv0MNX6Er6W95v9tCAg6Ll+sd2PQ sMyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I4ZXuuYTlkO6V36B0AGbKVG4q/ciI3RStRNOaHRkcck=; b=YE3Qt64o/7D5MBXGaE0b0AGtO4WK7glIlxylxiUcWgbFD5OoWEo/t7cbk4annoPbhQ Vk4MYecex7dwYGEV1gTWAq9/P0Ex4TSem6Up5k6AMO2NiYiOgrdnZQVGGjDYxbolDlYK 5aZajruVeZg7+Vxh0exh26GIhiDzZpuzsNx4A3YDoVQeE2x2TyOgrhEdeBARNX2JbcEC dTV0iptLFGUTDmXKtmAlOUyzseJpxefG6ecR5hfOaozkKq2xUCKFBRGvcmee8UZ2DuBA 3VXEYfJODigdk8DXe7NrugwfC72VcpyOLqygDgj9I8EojHiDscdB28RaailbMJM7nDDs 45CA== X-Gm-Message-State: APt69E0Qm8afOPgje9JqJocQ2a1hco3YpFOPJ5m/u4M8lcYl72n1tH+f bUVONW8kVuuOWisvss8gTjV6j1sRIsReHiM0QBlPSw== X-Google-Smtp-Source: ADUXVKLPexYdslT9B0WZzB1fxgAgBD9pw++OVpD0HHlbZUrI9+MHJTMkxJZChmrdQz8/JbFPMhJkfJcmgiWi872CuJg= X-Received: by 2002:a9d:2f45:: with SMTP id h63-v6mr2194861otb.371.1527889682018; Fri, 01 Jun 2018 14:48:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 14:47:21 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 1 Jun 2018 14:47:21 -0700 Message-ID: To: Brian Campbell Cc: Bill Burke , Mike Jones , oauth Content-Type: multipart/alternative; boundary="000000000000c0b770056d9b8943" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 21:48:08 -0000 --000000000000c0b770056d9b8943 Content-Type: text/plain; charset="UTF-8" That would go a long way, I think. Do you think that C's permissions matter at all? So, say that the resource is accessible to C but not A? -Ekr On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell wrote: > Hi Eric, > > Apologies for my somewhat slow response. I've honestly been unsure of how > else to try and address the comment/question. But will continue trying... > > My expectation would be that access control decisions would be made based > on the subject of the token itself or on the current actor. And maybe a > combination of both in some situations (like, for example, the actor is an > administrator and the token allows admin level access to the stuff the > token subject would normally have access to). However, I don't believe > that nested prior actors would or should be considered in access control > decisions. The nesting is more just to express what has happened for > auditing or tracking or the like. To be honest, the nesting was added in > the draft largely because the structure naturally and easily allowed for it > and it seemed like it might be useful information to convey in some cases. > > So in that A->B->C case (the claims of such a token would, I think, look > like the JSON below), B *is not* giving C his authority. B is just noted > in the token as having been involved previously. While A is identified as > the subject of the token and C is the current actor. > > { > "aud":"... ,"iss":... , "exp":..., etc. etc. ... > "sub":"A", > "act": > { > "sub":"C", > "act": > { > "sub":"B" > } > } > } > > > Would some text explicitly saying that only the token subject (top level > sub and claims) and the party identified by the outermost "act" claim (the > current actor) are to be considered in access control decisions address > your concern? > > > On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla wrote: > >> Hi Brian, >> >> To be clear, I'm not opposing Delegation. My concern here is that we have >> a chain of signed assertions and I'm trying to understand how I as a >> consumer of those assertions am supposed to evaluate it. >> >> I don't think it's sufficient to just say that that the access control >> rules are local policy, because then the entity generating the signature >> has no way of knowing how its signature will be used. >> >> To go back to the case I gave in my initial e-mail, say we have a chain >> A->B->C and a resource that A and C could ordinarily not access, but B can. >> If C has this delegation, can C access the resource? I.e., is B giving C >> his authority or just passing on A's authority? It seems pretty important >> for B to know that before he gives the token to C. >> >> -Ekr >> >> >> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> Delegation has been in the document since its inception and throughout >>> the three and a half years as a working group document. >>> >>> From a process point of view, the document is now in AD Evaluation. I >>> worked through a number of questions and clarifications with Eric (said >>> AD), however he raised the particular questions that started this thread on >>> the WG list. And I responded with an attempt at addressing those questions. >>> That was about a month ago. >>> >>> Eric, was my explanation helpful in clarify anything for you? Is there >>> some text that you'd like to see added? Something else? I'm unsure how to >>> proceed but would like to move things forward. >>> >>> >>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke wrote: >>> >>>> This is an honest question: How important is the actor stuff to the >>>> players involved? Are people going to use it? IMO, its an edge case >>>> and I think more important areas, like external token exchange (realm >>>> to realm, domain to domain) are being neglected. I'm quite unfamiliar >>>> how consensus is reached in this WG or the IETF, so I hope I'm not >>>> sounding rude. Just trying to provide some constructive feedback. >>>> >>>> >>>> >>>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones < >>>> Michael.Jones@microsoft.com> wrote: >>>> > Moving the actor claim to a separate specification would only make >>>> things more complicated for developers. There already plenty of OAuth >>>> specs. Needlessly adding another one will only make related things harder >>>> to find. >>>> > >>>> > Just like in the JWT [RFC 7519] spec itself in which use of all the >>>> claims is optional, use of the actor claim in this spec. If you don't need >>>> it, don't use it. Just because some won't use it is no better an argument >>>> for moving it to a different spec than the argument that JWT should have >>>> defined each of its claims in different specs. That would have made things >>>> harder, not easier. >>>> > >>>> > -- Mike >>>> > >>>> > -----Original Message----- >>>> > From: OAuth On Behalf Of Bill Burke >>>> > Sent: Thursday, May 17, 2018 2:11 PM >>>> > To: Brian Campbell >>>> > Cc: oauth >>>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang >>>> e-12.txt >>>> > >>>> > My personal opinion is that I'm glad this actor stuff is optional. >>>> > For one, none of our users have asked for it and really only do >>>> simple exchanges. Secondly, the rules for who can exchange what for what >>>> is controlled and defined within our AS. Makes things a lot simpler on the >>>> client. I kind of wish the actor stuff would be defined in a separate >>>> specification. I don't see us implementing it unless users start asking us >>>> to. >>>> > >>>> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >> Well, it's already called the "actor claim" so the claimed part is >>>> >> kind of implied. And "claimed actor claim" is a rather awkward. >>>> >> Really, all JWT claims are "claimed something" but they don't include >>>> >> the "claimed" bit in the name. RFC 7519, for example, defines the >>>> >> subject claim but not the claimed subject claim. >>>> >> >>>> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote: >>>> >>> >>>> >>> Brian, >>>> >>> >>>> >>> Eric said: "what is the RP supposed to do when they encounter it? >>>> >>> This seems kind of under specified". >>>> >>> >>>> >>> After reading your explanations below, it looks like the RP can do >>>> >>> anything he wants with the "actor". >>>> >>> It is a "claimed actor" and, if we keep the concept, it should be >>>> >>> called as such. Such a claim cannot be verified. >>>> >>> A RP could copy and paste that claim in an audit log. No standard >>>> >>> action related to the content of such a claim can be specified in >>>> the >>>> >>> spec. If the content of a "claimed actor" is used by the RP, it >>>> >>> should be only used as an hint and thus be subject to other >>>> >>> verifications which are not specified in this specification. >>>> >>> >>>> >>> Denis >>>> >>> >>>> >>> Eric, I realize you weren't particularly impressed by my prior >>>> >>> statements about the actor claim but, for lack of knowing what else >>>> >>> to say, I'm going to kind of repeat what I said about it over in the >>>> >>> Phabricator tool and add a little color. >>>> >>> >>>> >>> The actor claim is intended as a way to express that delegation has >>>> >>> happened and identify the entities involved. Access control or other >>>> >>> decisions based on it are at the discretion of the consumer of the >>>> >>> token based on whatever policy might be in place. >>>> >>> >>>> >>> There are JWT claims that have concise processing rules with respect >>>> >>> to whether or not the JWT can be accepted as valid. Some examples >>>> are "aud" >>>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from >>>> RFC 7519. >>>> >>> E.g. if the token is expired or was intended for someone or >>>> something >>>> >>> else, reject it. >>>> >>> >>>> >>> And there are JWT claims that appropriately don't specify such >>>> >>> processing rules and are solely statements of fact or circumstance. >>>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) >>>> claims are good examples of such. >>>> >>> There might be application or policy specific rules applied to the >>>> >>> content of those kinds of claims (e.g. only subjects from a >>>> >>> particular organization are able to access tenant specific data or, >>>> >>> less realistic but still possible, disallow access for tokens issued >>>> >>> outside of regular business >>>> >>> hours) but that's all outside the scope of a specification's >>>> >>> definition of the claim. >>>> >>> >>>> >>> The actor claim falls into the latter category. It's a way for the >>>> >>> issuer of the token to tell the consumer of the token what is going >>>> >>> on. But any action to take (or not) based on that information is at >>>> >>> the discretion of the token consumer. I honestly don't know it could >>>> >>> be anything more. And don't think it should be. >>>> >>> >>>> >>> There are two main expected uses of the actor claim (that I'm aware >>>> >>> of >>>> >>> anyway) that describing here might help. Maybe. One is a human to >>>> >>> human delegation case like a customer service rep doing something on >>>> >>> behalf of an end user. The subject would be that user and the actor >>>> >>> would be the customer service rep. And there wouldn't be any >>>> chaining >>>> >>> or nesting of the actor. The other case is so called service >>>> chaining >>>> >>> where a system might exchange a token it receives for a new token >>>> >>> that it can use to call a downstream service. And that service in >>>> >>> turn might do another exchange to get a new token suitable to call >>>> >>> yet another downstream service. And again and so on and turtles all >>>> >>> the way. I'm not necessarily endorsing that level of granularity in >>>> >>> chaining but it's bound to happen somewhere/sometime. The nested >>>> >>> actor claim is able to express that all that has happened with the >>>> >>> top level or outermost one being the system currently using the >>>> token >>>> >>> and prior systems being nested.. What actually gets done with that >>>> >>> information is up to the respective systems involved. There might be >>>> >>> policy about what system is allowed to call what other system that >>>> is >>>> >>> enforced. Or maybe the info is just written to an audit log >>>> >>> somewhere. Or something else. I don't know. But whatever it is >>>> application/deployment/policy dependent and not specifiable by a spec. >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla >>>> wrote: >>>> >>>> >>>> >>>> Hi folks, >>>> >>>> >>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things seem >>>> >>>> generally OK. I do still have one remaining concern, which is about >>>> >>>> the actor claim. Specifically, what is the RP supposed to do when >>>> >>>> they encounter it? This seems kind of underspecified. >>>> >>>> >>>> >>>> In particular: >>>> >>>> >>>> >>>> 1. What facts am I supposed to know here? Merely that everyone in >>>> >>>> the chain signed off on the next person in the chain acting as >>>> them? >>>> >>>> >>>> >>>> 2. Am I just supposed to pretend that the person presenting the >>>> token >>>> >>>> is the identity at the top of the chain? Say I have the >>>> >>>> delegation A -> B -> C, and there is some resource which >>>> >>>> B can access but A and C cannot, should I give access? >>>> >>>> >>>> >>>> I think the first question definitely needs an answer. The second >>>> >>>> question I guess we could make not answer, but it's pretty hard to >>>> >>>> know how to make a system with this left open.. >>>> >>>> >>>> >>>> -Ekr >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> OAuth mailing list >>>> >>>> OAuth@ietf.org >>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>> >>>> >>> >>>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> >>> privileged material for the sole use of the intended recipient(s). >>>> >>> Any review, use, distribution or disclosure by others is strictly >>>> >>> prohibited.. If you have received this communication in error, >>>> >>> please notify the sender immediately by e-mail and delete the >>>> message >>>> >>> and any file attachments from your computer. Thank you. >>>> >>> >>>> >>> _______________________________________________ >>>> >>> OAuth mailing list >>>> >>> OAuth@ietf.org >>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> OAuth mailing list >>>> >>> OAuth@ietf.org >>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> >>>> >> >>>> >> >>>> >> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> >> privileged material for the sole use of the intended recipient(s). >>>> Any >>>> >> review, use, distribution or disclosure by others is strictly >>>> >> prohibited.. If you have received this communication in error, >>>> please >>>> >> notify the sender immediately by e-mail and delete the message and >>>> any >>>> >> file attachments from your computer. Thank you. >>>> >> _______________________________________________ >>>> >> OAuth mailing list >>>> >> OAuth@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>> >> >>>> > >>>> > >>>> > >>>> > -- >>>> > Bill Burke >>>> > Red Hat >>>> > >>>> > _______________________________________________ >>>> > OAuth mailing list >>>> > OAuth@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> >>>> -- >>>> Bill Burke >>>> Red Hat >>>> >>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibited. >>> If you have received this communication in error, please notify the sender >>> immediately by e-mail and delete the message and any file attachments from >>> your computer. Thank you.* >> >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > --000000000000c0b770056d9b8943 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That would go a long way, I think. Do you think that = C's permissions matter at all? So, say that the resource is accessible = to C but not A?

-Ekr

=


On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <bc= ampbell@pingidentity.com> wrote:
Hi Eric,

Apologie= s for my somewhat slow response. I've honestly been unsure of how else = to try and address the comment/question. But will continue trying...=C2=A0 =

My expectation would be that access control d= ecisions would be made based on the subject of the token itself or on the c= urrent actor. And maybe a combination of both in some situations (like, for= example, the actor is an administrator and the token allows admin level ac= cess to the stuff the token subject would normally have access to).=C2=A0 H= owever, I don't believe that nested prior actors would or should be con= sidered in access control decisions. The nesting is more just to express wh= at has happened for auditing or tracking or the like. To be honest, the nes= ting was added in the draft largely because the structure naturally and eas= ily allowed for it and it seemed like it might be useful information to con= vey in some cases.

So in that A->B->C c= ase (the claims of such a token would, I think, look like the JSON below), = B is not giving C his=C2=A0authority. B is just noted in the token a= s having been involved previously.=C2=A0 While A is identified as the subje= ct of the token and C is the current actor.

<= pre class=3D"m_5377743870565981629gmail-m_8378560348234984766gmail-m_636945= 9926104603262m_842893421122832003gmail-m_3377091152811425824gmail-newpage">= { "aud":"... ,"iss":... , "exp":...,= etc. etc. ... "sub":"A", "act": { "sub":"C", "act": { "sub":"B" } } }
Would some text explicitly saying that only the t= oken subject (top level sub and claims) and the party identified by the out= ermost "act" claim (the current actor) are to be considered in ac= cess control decisions address your concern?


On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla <ekr@rtf= m.com> wrote:
Hi Brian,

To be clear, I'm not opposi= ng Delegation. My concern here is that we have a chain of signed assertions= and I'm trying to understand how I as a consumer of those assertions a= m supposed to evaluate it.

I don't think it= 9;s sufficient to just say that that the access control rules are local pol= icy, because then the entity generating the signature has no way of knowing= how its signature will be used.

To go back to the= case I gave in my initial e-mail, say we have a chain A->B->C and a = resource that A and C could ordinarily not access, but B can. If C has this= delegation, can C access the resource? I.e., is B giving C his authority o= r just passing on A's authority? It seems pretty important for B to kno= w that before he gives the token to C.

-Ekr


On Thu, May 17, 2018 at = 11:06 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Delegation has been in the d= ocument since its inception and throughout the three and a half years as a = working group document.

From a process point = of view, the document is now in=C2=A0AD Evaluation. I worked through a numb= er of questions and clarifications with Eric (said AD), however he raised t= he particular questions that started this thread on the WG list. And I resp= onded with an attempt at addressing those questions. That was about a month= ago.

Eric, was my explanation helpful in cla= rify anything for you? Is there some text that you'd like to see added?= Something else? I'm unsure how to proceed but would like to move thing= s forward.


On= Thu, May 17, 2018 at 8:03 AM, Bill Burke <bburke@redhat.com> wrote:
This is an honest question: How = important is the actor stuff to the
players involved?=C2=A0 Are people going to use it?=C2=A0 IMO, its an edge = case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.=C2=A0 I'm quite unfami= liar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.=C2=A0 Just trying to provide some constructive feedback.
<= div class=3D"m_5377743870565981629m_-5039242635228001560m_34756310847619902= 49m_-307576368905976843m_6870922798043245318m_5069623183765691108h5">


On Thu, May 17, 2018 at 9:26 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:
> Moving the actor claim to a separate specification would only make thi= ngs more complicated for developers.=C2=A0 There already plenty of OAuth sp= ecs.=C2=A0 Needlessly adding another one will only make related things hard= er to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the cl= aims is optional, use of the actor claim in this spec.=C2=A0 If you don'= ;t need it, don't use it.=C2=A0 Just because some won't use it is n= o better an argument for moving it to a different spec than the argument th= at JWT should have defined each of its claims in different specs.=C2=A0 Tha= t would have made things harder, not easier.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell <bcampbell@pingidentity.com>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.=
> For one, none of our users have asked for it and really only do simple= exchanges.=C2=A0 Secondly, the rules for who can exchange what for what is= controlled and defined within our AS.=C2=A0 Makes things a lot simpler on = the client.=C2=A0 I kind of wish the actor stuff would be defined in a sepa= rate specification.=C2=A0 I don't see us implementing it unless users s= tart asking us to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Well, it's already called the "actor claim" so the c= laimed part is
>> kind of implied. And "claimed actor claim" is a rather a= wkward.
>> Really, all JWT claims are "claimed something" but they = don't include
>> the "claimed" bit in the name. RFC 7519, for example, de= fines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encou= nter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP ca= n do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept,= it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No stand= ard
>>> action related to the content of such a claim can be specified= in the
>>> spec. If the content of a "claimed actor" is used by= the RP, it
>>> should be only used as an hint and thus be subject to other >>> verifications which are not specified in this specification. >>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my p= rior
>>> statements about the actor claim but, for lack of knowing what= else
>>> to say, I'm going to kind of repeat what I said about it o= ver in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegatio= n has
>>> happened and identify the entities involved. Access control or= other
>>> decisions based on it are at the discretion of the consumer of= the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with r= espect
>>> to whether or not the JWT can be accepted as valid. Some examp= les are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf&q= uot; (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or so= mething
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify = such
>>> processing rules and are solely statements of fact or circumst= ance.
>>> Also from RFC 7519, the "sub" (Subject) and "ia= t" (Issued At) claims are good examples of such.
>>> There might be application or policy specific rules applied to= the
>>> content of those kinds of claims (e.g. only subjects from a >>> particular organization are able to access tenant specific dat= a or,
>>> less realistic but still possible, disallow access for tokens = issued
>>> outside of regular business
>>> hours) but that's all outside the scope of a specification= 's
>>> definition of the claim.
>>>
>>> The actor claim falls into the latter category. It's a way= for the
>>> issuer of the token to tell the consumer of the token what is = going
>>> on. But any action to take (or not) based on that information = is at
>>> the discretion of the token consumer. I honestly don't kno= w it could
>>> be anything more. And don't think it should be.
>>>
>>> There are two main expected uses of the actor claim (that I= 9;m aware
>>> of
>>> anyway) that describing here might help. Maybe. One is a human= to
>>> human delegation case like a customer service rep doing someth= ing on
>>> behalf of an end user. The subject would be that user and the = actor
>>> would be the customer service rep. And there wouldn't be a= ny chaining
>>> or nesting of the actor. The other case is so called service c= haining
>>> where a system might exchange a token it receives for a new to= ken
>>> that it can use to call a downstream service. And that service= in
>>> turn might do another exchange to get a new token suitable to = call
>>> yet another downstream service. And again and so on and turtle= s all
>>> the way. I'm not necessarily endorsing that level of granu= larity in
>>> chaining but it's bound to happen somewhere/sometime. The = nested
>>> actor claim is able to express that all that has happened with= the
>>> top level or outermost one being the system currently using th= e token
>>> and prior systems being nested.. What actually gets done with = that
>>> information is up to the respective systems involved. There mi= ght be
>>> policy about what system is allowed to call what other system = that is
>>> enforced. Or maybe the info is just written to an audit log >>> somewhere. Or something else. I don't know. But whatever i= t is application/deployment/policy dependent and not specifiable by a spec.=
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I've gone over draft-ietf-oauth-token-exchange-12= and things seem
>>>> generally OK. I do still have one remaining concern, which= is about
>>>> the actor claim. Specifically, what is the RP supposed to = do when
>>>> they encounter it? This seems kind of underspecified.
>>>>
>>>> In particular:
>>>>
>>>> 1. What facts am I supposed to know here? Merely that ever= yone in
>>>>=C2=A0 =C2=A0 the chain signed off on the next person in th= e chain acting as them?
>>>>
>>>> 2. Am I just supposed to pretend that the person presentin= g the token
>>>>=C2=A0 =C2=A0 is the identity at the top of the chain? Say = I have the
>>>>=C2=A0 =C2=A0 delegation A -> B -> C, and there is so= me resource which
>>>>=C2=A0 =C2=A0 B can access but A and C cannot, should I giv= e access?
>>>>
>>>> I think the first question definitely needs an answer. The= second
>>>> question I guess we could make not answer, but it's pr= etty hard to
>>>> know how to make a system with this left open..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d
>>> privileged material for the sole use of the intended recipient= (s).
>>> Any review, use, distribution or disclosure by others is stric= tly
>>> prohibited..=C2=A0 If you have received this communication in = error,
>>> please notify the sender immediately by e-mail and delete the = message
>>> and any file attachments from your computer. Thank you.
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s).= Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited..=C2=A0 If you have received this communication in erro= r, please
>> notify the sender immediately by e-mail and delete the message and= any
>> file attachments from your computer. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth=



--
Bill Burke
Red Hat


CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.
--000000000000c0b770056d9b8943-- From nobody Fri Jun 1 15:16:14 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CE112DA72 for ; Fri, 1 Jun 2018 15:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOCNUJXGsyK5 for ; Fri, 1 Jun 2018 15:16:07 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8BF12DA6F for ; Fri, 1 Jun 2018 15:16:07 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 144-v6so3514535iti.5 for ; Fri, 01 Jun 2018 15:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DNMGnN+OEWnieyF229VnyJjMrv4tg95H9PtShRpg5sI=; b=cCM0z9gYGjVUrLRs2zPS6CFGW6il4FjC99WMqvju4dIZoMtUUzlHgH0sc+xYoeLa3f TFB0uDMP1DK0oeR/n7gPZQrrEHiM2PwmINKkqkiOa7GcxcPZUqLw/rVmNCXoeer4WmaS 1w0iV3/96ohQXJQjgfqdcS744PHkWLsSZc5ho= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DNMGnN+OEWnieyF229VnyJjMrv4tg95H9PtShRpg5sI=; b=rNJQJ6ITcdpXTyvOkveh3wALVKggWfRgt8SBfZvbOMBkmZ/W57B0TRiJ24Hjy9HRpo 4wKRHKkv+Dc13ZN6Isqhmc6ds0vlYoDPNH+JbkWajDUU1fkDbqkv7Jej0Q0OFkLeYjks tX19fC0O2DRMjfwgMga/yVt4oIS7b9s1W4wN0bSdax8EfM/ZnltekwduUVc6O5PYa6+4 TG1kkNB31MXoIm3P/lTrCS1TrwSVmEw7gh/jUj1+zhD9LtSVyZ1prHmvW1iseV9VumRX OhWxYUjBjMCRt9iAGppc69oLdr+/0OKjqjItiOvES03ZwmI9EhBHRQZh0cLDKx0n8u+c p7xQ== X-Gm-Message-State: ALKqPwffLt9gg+PqgQkpuNnzu40VsmLxU/kRqEHJJ7QlbbkPf2HI6qos LVQ5qnwYoNzFT8QS3FjbEpznv6DRSy38rbvpMI/l/trnnWCiyOvfsOcvTVKIKQzQfJJP/TOvrAy nqEYv3LtuOg0SRA== X-Google-Smtp-Source: ADUXVKLb1riTw0CjxYunaivgzndxILqI3bMElV5f4T0yVas1d5YatWVd3zBBlP/P0aaccB0odZQanF5/GPzQ3GL360U= X-Received: by 2002:a24:1f4a:: with SMTP id d71-v6mr6122366itd.53.1527891366634; Fri, 01 Jun 2018 15:16:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 15:15:35 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 1 Jun 2018 16:15:35 -0600 Message-ID: To: Eric Rescorla Cc: oauth Content-Type: multipart/alternative; boundary="0000000000002a089e056d9bee12" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 22:16:12 -0000 --0000000000002a089e056d9bee12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I suspect that the vast majority of time C's permissions won't matter at all. But I do think there are legitimate cases where they might be considered in the policy decision. One general example I can think of is a customer service rep or administrator taking override type corrective action on an end-user's account or transaction information (A is the end-user and C is the customer service rep) that the user on their own wouldn't have permission to change. On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla wrote: > That would go a long way, I think. Do you think that C's permissions > matter at all? So, say that the resource is accessible to C but not A? > > -Ekr > > > > > On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> Hi Eric, >> >> Apologies for my somewhat slow response. I've honestly been unsure of ho= w >> else to try and address the comment/question. But will continue trying..= . >> >> My expectation would be that access control decisions would be made base= d >> on the subject of the token itself or on the current actor. And maybe a >> combination of both in some situations (like, for example, the actor is = an >> administrator and the token allows admin level access to the stuff the >> token subject would normally have access to). However, I don't believe >> that nested prior actors would or should be considered in access control >> decisions. The nesting is more just to express what has happened for >> auditing or tracking or the like. To be honest, the nesting was added in >> the draft largely because the structure naturally and easily allowed for= it >> and it seemed like it might be useful information to convey in some case= s. >> >> So in that A->B->C case (the claims of such a token would, I think, look >> like the JSON below), B *is not* giving C his authority. B is just noted >> in the token as having been involved previously. While A is identified = as >> the subject of the token and C is the current actor. >> >> { >> "aud":"... ,"iss":... , "exp":..., etc. etc. ... >> "sub":"A", >> "act": >> { >> "sub":"C", >> "act": >> { >> "sub":"B" >> } >> } >> } >> >> >> Would some text explicitly saying that only the token subject (top level >> sub and claims) and the party identified by the outermost "act" claim (t= he >> current actor) are to be considered in access control decisions address >> your concern? >> >> >> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla wrote: >> >>> Hi Brian, >>> >>> To be clear, I'm not opposing Delegation. My concern here is that we >>> have a chain of signed assertions and I'm trying to understand how I as= a >>> consumer of those assertions am supposed to evaluate it. >>> >>> I don't think it's sufficient to just say that that the access control >>> rules are local policy, because then the entity generating the signatur= e >>> has no way of knowing how its signature will be used. >>> >>> To go back to the case I gave in my initial e-mail, say we have a chain >>> A->B->C and a resource that A and C could ordinarily not access, but B = can. >>> If C has this delegation, can C access the resource? I.e., is B giving = C >>> his authority or just passing on A's authority? It seems pretty importa= nt >>> for B to know that before he gives the token to C. >>> >>> -Ekr >>> >>> >>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> Delegation has been in the document since its inception and throughout >>>> the three and a half years as a working group document. >>>> >>>> From a process point of view, the document is now in AD Evaluation. I >>>> worked through a number of questions and clarifications with Eric (sai= d >>>> AD), however he raised the particular questions that started this thre= ad on >>>> the WG list. And I responded with an attempt at addressing those quest= ions. >>>> That was about a month ago. >>>> >>>> Eric, was my explanation helpful in clarify anything for you? Is there >>>> some text that you'd like to see added? Something else? I'm unsure how= to >>>> proceed but would like to move things forward. >>>> >>>> >>>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke wrote: >>>> >>>>> This is an honest question: How important is the actor stuff to the >>>>> players involved? Are people going to use it? IMO, its an edge case >>>>> and I think more important areas, like external token exchange (realm >>>>> to realm, domain to domain) are being neglected. I'm quite unfamilia= r >>>>> how consensus is reached in this WG or the IETF, so I hope I'm not >>>>> sounding rude. Just trying to provide some constructive feedback. >>>>> >>>>> >>>>> >>>>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones < >>>>> Michael.Jones@microsoft.com> wrote: >>>>> > Moving the actor claim to a separate specification would only make >>>>> things more complicated for developers. There already plenty of OAut= h >>>>> specs. Needlessly adding another one will only make related things h= arder >>>>> to find. >>>>> > >>>>> > Just like in the JWT [RFC 7519] spec itself in which use of all the >>>>> claims is optional, use of the actor claim in this spec. If you don'= t need >>>>> it, don't use it. Just because some won't use it is no better an arg= ument >>>>> for moving it to a different spec than the argument that JWT should h= ave >>>>> defined each of its claims in different specs. That would have made = things >>>>> harder, not easier. >>>>> > >>>>> > -- Mike >>>>> > >>>>> > -----Original Message----- >>>>> > From: OAuth On Behalf Of Bill Burke >>>>> > Sent: Thursday, May 17, 2018 2:11 PM >>>>> > To: Brian Campbell >>>>> > Cc: oauth >>>>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang >>>>> e-12.txt >>>>> > >>>>> > My personal opinion is that I'm glad this actor stuff is optional. >>>>> > For one, none of our users have asked for it and really only do >>>>> simple exchanges. Secondly, the rules for who can exchange what for = what >>>>> is controlled and defined within our AS. Makes things a lot simpler = on the >>>>> client. I kind of wish the actor stuff would be defined in a separat= e >>>>> specification. I don't see us implementing it unless users start ask= ing us >>>>> to. >>>>> > >>>>> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >> Well, it's already called the "actor claim" so the claimed part is >>>>> >> kind of implied. And "claimed actor claim" is a rather awkward. >>>>> >> Really, all JWT claims are "claimed something" but they don't >>>>> include >>>>> >> the "claimed" bit in the name. RFC 7519, for example, defines the >>>>> >> subject claim but not the claimed subject claim. >>>>> >> >>>>> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis wrote= : >>>>> >>> >>>>> >>> Brian, >>>>> >>> >>>>> >>> Eric said: "what is the RP supposed to do when they encounter it? >>>>> >>> This seems kind of under specified". >>>>> >>> >>>>> >>> After reading your explanations below, it looks like the RP can d= o >>>>> >>> anything he wants with the "actor". >>>>> >>> It is a "claimed actor" and, if we keep the concept, it should be >>>>> >>> called as such. Such a claim cannot be verified. >>>>> >>> A RP could copy and paste that claim in an audit log. No standard >>>>> >>> action related to the content of such a claim can be specified in >>>>> the >>>>> >>> spec. If the content of a "claimed actor" is used by the RP, it >>>>> >>> should be only used as an hint and thus be subject to other >>>>> >>> verifications which are not specified in this specification. >>>>> >>> >>>>> >>> Denis >>>>> >>> >>>>> >>> Eric, I realize you weren't particularly impressed by my prior >>>>> >>> statements about the actor claim but, for lack of knowing what el= se >>>>> >>> to say, I'm going to kind of repeat what I said about it over in >>>>> the >>>>> >>> Phabricator tool and add a little color. >>>>> >>> >>>>> >>> The actor claim is intended as a way to express that delegation h= as >>>>> >>> happened and identify the entities involved. Access control or >>>>> other >>>>> >>> decisions based on it are at the discretion of the consumer of th= e >>>>> >>> token based on whatever policy might be in place. >>>>> >>> >>>>> >>> There are JWT claims that have concise processing rules with >>>>> respect >>>>> >>> to whether or not the JWT can be accepted as valid. Some examples >>>>> are "aud" >>>>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from >>>>> RFC 7519. >>>>> >>> E.g. if the token is expired or was intended for someone or >>>>> something >>>>> >>> else, reject it. >>>>> >>> >>>>> >>> And there are JWT claims that appropriately don't specify such >>>>> >>> processing rules and are solely statements of fact or circumstanc= e. >>>>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) >>>>> claims are good examples of such. >>>>> >>> There might be application or policy specific rules applied to th= e >>>>> >>> content of those kinds of claims (e.g. only subjects from a >>>>> >>> particular organization are able to access tenant specific data o= r, >>>>> >>> less realistic but still possible, disallow access for tokens >>>>> issued >>>>> >>> outside of regular business >>>>> >>> hours) but that's all outside the scope of a specification's >>>>> >>> definition of the claim. >>>>> >>> >>>>> >>> The actor claim falls into the latter category. It's a way for th= e >>>>> >>> issuer of the token to tell the consumer of the token what is goi= ng >>>>> >>> on. But any action to take (or not) based on that information is = at >>>>> >>> the discretion of the token consumer. I honestly don't know it >>>>> could >>>>> >>> be anything more. And don't think it should be. >>>>> >>> >>>>> >>> There are two main expected uses of the actor claim (that I'm awa= re >>>>> >>> of >>>>> >>> anyway) that describing here might help. Maybe. One is a human to >>>>> >>> human delegation case like a customer service rep doing something >>>>> on >>>>> >>> behalf of an end user. The subject would be that user and the act= or >>>>> >>> would be the customer service rep. And there wouldn't be any >>>>> chaining >>>>> >>> or nesting of the actor. The other case is so called service >>>>> chaining >>>>> >>> where a system might exchange a token it receives for a new token >>>>> >>> that it can use to call a downstream service. And that service in >>>>> >>> turn might do another exchange to get a new token suitable to cal= l >>>>> >>> yet another downstream service. And again and so on and turtles a= ll >>>>> >>> the way. I'm not necessarily endorsing that level of granularity = in >>>>> >>> chaining but it's bound to happen somewhere/sometime. The nested >>>>> >>> actor claim is able to express that all that has happened with th= e >>>>> >>> top level or outermost one being the system currently using the >>>>> token >>>>> >>> and prior systems being nested.. What actually gets done with tha= t >>>>> >>> information is up to the respective systems involved. There might >>>>> be >>>>> >>> policy about what system is allowed to call what other system tha= t >>>>> is >>>>> >>> enforced. Or maybe the info is just written to an audit log >>>>> >>> somewhere. Or something else. I don't know. But whatever it is >>>>> application/deployment/policy dependent and not specifiable by a spec= . >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla >>>>> wrote: >>>>> >>>> >>>>> >>>> Hi folks, >>>>> >>>> >>>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things see= m >>>>> >>>> generally OK. I do still have one remaining concern, which is >>>>> about >>>>> >>>> the actor claim. Specifically, what is the RP supposed to do whe= n >>>>> >>>> they encounter it? This seems kind of underspecified. >>>>> >>>> >>>>> >>>> In particular: >>>>> >>>> >>>>> >>>> 1. What facts am I supposed to know here? Merely that everyone i= n >>>>> >>>> the chain signed off on the next person in the chain acting a= s >>>>> them? >>>>> >>>> >>>>> >>>> 2. Am I just supposed to pretend that the person presenting the >>>>> token >>>>> >>>> is the identity at the top of the chain? Say I have the >>>>> >>>> delegation A -> B -> C, and there is some resource which >>>>> >>>> B can access but A and C cannot, should I give access? >>>>> >>>> >>>>> >>>> I think the first question definitely needs an answer. The secon= d >>>>> >>>> question I guess we could make not answer, but it's pretty hard = to >>>>> >>>> know how to make a system with this left open.. >>>>> >>>> >>>>> >>>> -Ekr >>>>> >>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> OAuth mailing list >>>>> >>>> OAuth@ietf.org >>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> >>>>> >>> >>>>> >>> >>>>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> >>> privileged material for the sole use of the intended recipient(s)= . >>>>> >>> Any review, use, distribution or disclosure by others is strictly >>>>> >>> prohibited.. If you have received this communication in error, >>>>> >>> please notify the sender immediately by e-mail and delete the >>>>> message >>>>> >>> and any file attachments from your computer. Thank you. >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> OAuth mailing list >>>>> >>> OAuth@ietf.org >>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> OAuth mailing list >>>>> >>> OAuth@ietf.org >>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>> >>>>> >> >>>>> >> >>>>> >> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> >> privileged material for the sole use of the intended recipient(s). >>>>> Any >>>>> >> review, use, distribution or disclosure by others is strictly >>>>> >> prohibited.. If you have received this communication in error, >>>>> please >>>>> >> notify the sender immediately by e-mail and delete the message and >>>>> any >>>>> >> file attachments from your computer. Thank you. >>>>> >> _______________________________________________ >>>>> >> OAuth mailing list >>>>> >> OAuth@ietf.org >>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > Bill Burke >>>>> > Red Hat >>>>> > >>>>> > _______________________________________________ >>>>> > OAuth mailing list >>>>> > OAuth@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> -- >>>>> Bill Burke >>>>> Red Hat >>>>> >>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>> >>> >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000002a089e056d9bee12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I suspect that the vast majority of time C's perm= issions won't matter at all. But I do think there are legitimate cases = where they might be considered in the policy decision. One general example = I can think of is a customer service rep or administrator taking override t= ype corrective action on an end-user's account or transaction informati= on (A is the end-user and C is the customer service rep) that the user on t= heir own wouldn't have permission to change. =C2=A0

On Fri, Jun 1, 2018 = at 3:47 PM, Eric Rescorla <ekr@rtfm.com> wrote:
That would go a long way, I think. D= o you think that C's permissions matter at all? So, say that the resour= ce is accessible to C but not A?

-Ekr




On F= ri, Jun 1, 2018 at 11:47 AM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:
Hi Eric,

Apologies for my somew= hat slow response. I've honestly been unsure of how else to try and add= ress the comment/question. But will continue trying...=C2=A0

My expectation would be that access control decisions would= be made based on the subject of the token itself or on the current actor. = And maybe a combination of both in some situations (like, for example, the = actor is an administrator and the token allows admin level access to the st= uff the token subject would normally have access to).=C2=A0 However, I don&= #39;t believe that nested prior actors would or should be considered in acc= ess control decisions. The nesting is more just to express what has happene= d for auditing or tracking or the like. To be honest, the nesting was added= in the draft largely because the structure naturally and easily allowed fo= r it and it seemed like it might be useful information to convey in some ca= ses.

So in that A->B->C case (the claim= s of such a token would, I think, look like the JSON below), B is not giving C his=C2=A0authority. B is just noted in the token as having been = involved previously.=C2=A0 While A is identified as the subject of the toke= n and C is the current actor. 

    {
      "aud":"... ,"iss":... , "exp":...,=
 etc. etc. ...
      "sub":"A",
      "act":
      {
        "sub":"C",
        "act":
        {
          "sub":"B"
        }
      }
    }

Would some text explicitly saying that only the t= oken subject (top level sub and claims) and the party identified by the out= ermost "act" claim (the current actor) are to be considered in ac= cess control decisions address your concern?


On Tue,= May 29, 2018 at 4:19 PM, Eric Rescorla <ekr@rtfm.com> wrote:
=
Hi Brian,
To be clear, I'm not opposing Delegation. My concern here = is that we have a chain of signed assertions and I'm trying to understa= nd how I as a consumer of those assertions am supposed to evaluate it.

I don't think it's sufficient to just say that= that the access control rules are local policy, because then the entity ge= nerating the signature has no way of knowing how its signature will be used= .

To go back to the case I gave in my initial e-ma= il, say we have a chain A->B->C and a resource that A and C could ord= inarily not access, but B can. If C has this delegation, can C access the r= esource? I.e., is B giving C his authority or just passing on A's autho= rity? It seems pretty important for B to know that before he gives the toke= n to C.

-Ekr


On Thu, May 17, 2018 at 11:06 AM,= Brian Campbell <bcampbell@pingidentity.com> wrote:=
Delegation has = been in the document since its inception and throughout the three and a hal= f years as a working group document.

From a p= rocess point of view, the document is now in=C2=A0AD Evaluation. I worked t= hrough a number of questions and clarifications with Eric (said AD), howeve= r he raised the particular questions that started this thread on the WG lis= t. And I responded with an attempt at addressing those questions. That was = about a month ago.

Eric, was my explanation h= elpful in clarify anything for you? Is there some text that you'd like = to see added? Something else? I'm unsure how to proceed but would like = to move things forward.


On Thu, May 17, 2018 at 8:03 AM, Bill Burk= e <bburke@redhat.com> wrote:
This is an honest question: How important is the actor stuff to the
players involved?=C2=A0 Are people going to use it?=C2=A0 IMO, its an edge = case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.=C2=A0 I'm quite unfami= liar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.=C2=A0 Just trying to provide some constructive feedback.



On Thu, May 17, 2018 at 9:26 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:
> Moving the actor claim to a separate specification would only make thi= ngs more complicated for developers.=C2=A0 There already plenty of OAuth sp= ecs.=C2=A0 Needlessly adding another one will only make related things hard= er to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the cl= aims is optional, use of the actor claim in this spec.=C2=A0 If you don'= ;t need it, don't use it.=C2=A0 Just because some won't use it is n= o better an argument for moving it to a different spec than the argument th= at JWT should have defined each of its claims in different specs.=C2=A0 Tha= t would have made things harder, not easier.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell <bcampbell@pingidentity.com>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.=
> For one, none of our users have asked for it and really only do simple= exchanges.=C2=A0 Secondly, the rules for who can exchange what for what is= controlled and defined within our AS.=C2=A0 Makes things a lot simpler on = the client.=C2=A0 I kind of wish the actor stuff would be defined in a sepa= rate specification.=C2=A0 I don't see us implementing it unless users s= tart asking us to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Well, it's already called the "actor claim" so the c= laimed part is
>> kind of implied. And "claimed actor claim" is a rather a= wkward.
>> Really, all JWT claims are "claimed something" but they = don't include
>> the "claimed" bit in the name. RFC 7519, for example, de= fines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encou= nter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP ca= n do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept,= it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No stand= ard
>>> action related to the content of such a claim can be specified= in the
>>> spec. If the content of a "claimed actor" is used by= the RP, it
>>> should be only used as an hint and thus be subject to other >>> verifications which are not specified in this specification. >>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my p= rior
>>> statements about the actor claim but, for lack of knowing what= else
>>> to say, I'm going to kind of repeat what I said about it o= ver in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegatio= n has
>>> happened and identify the entities involved. Access control or= other
>>> decisions based on it are at the discretion of the consumer of= the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with r= espect
>>> to whether or not the JWT can be accepted as valid. Some examp= les are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf&q= uot; (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or so= mething
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify = such
>>> processing rules and are solely statements of fact or circumst= ance.
>>> Also from RFC 7519, the "sub" (Subject) and "ia= t" (Issued At) claims are good examples of such.
>>> There might be application or policy specific rules applied to= the
>>> content of those kinds of claims (e.g. only subjects from a >>> particular organization are able to access tenant specific dat= a or,
>>> less realistic but still possible, disallow access for tokens = issued
>>> outside of regular business
>>> hours) but that's all outside the scope of a specification= 's
>>> definition of the claim.
>>>
>>> The actor claim falls into the latter category. It's a way= for the
>>> issuer of the token to tell the consumer of the token what is = going
>>> on. But any action to take (or not) based on that information = is at
>>> the discretion of the token consumer. I honestly don't kno= w it could
>>> be anything more. And don't think it should be.
>>>
>>> There are two main expected uses of the actor claim (that I= 9;m aware
>>> of
>>> anyway) that describing here might help. Maybe. One is a human= to
>>> human delegation case like a customer service rep doing someth= ing on
>>> behalf of an end user. The subject would be that user and the = actor
>>> would be the customer service rep. And there wouldn't be a= ny chaining
>>> or nesting of the actor. The other case is so called service c= haining
>>> where a system might exchange a token it receives for a new to= ken
>>> that it can use to call a downstream service. And that service= in
>>> turn might do another exchange to get a new token suitable to = call
>>> yet another downstream service. And again and so on and turtle= s all
>>> the way. I'm not necessarily endorsing that level of granu= larity in
>>> chaining but it's bound to happen somewhere/sometime. The = nested
>>> actor claim is able to express that all that has happened with= the
>>> top level or outermost one being the system currently using th= e token
>>> and prior systems being nested.. What actually gets done with = that
>>> information is up to the respective systems involved. There mi= ght be
>>> policy about what system is allowed to call what other system = that is
>>> enforced. Or maybe the info is just written to an audit log >>> somewhere. Or something else. I don't know. But whatever i= t is application/deployment/policy dependent and not specifiable by a spec.=
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I've gone over draft-ietf-oauth-token-exchange-12= and things seem
>>>> generally OK. I do still have one remaining concern, which= is about
>>>> the actor claim. Specifically, what is the RP supposed to = do when
>>>> they encounter it? This seems kind of underspecified.
>>>>
>>>> In particular:
>>>>
>>>> 1. What facts am I supposed to know here? Merely that ever= yone in
>>>>=C2=A0 =C2=A0 the chain signed off on the next person in th= e chain acting as them?
>>>>
>>>> 2. Am I just supposed to pretend that the person presentin= g the token
>>>>=C2=A0 =C2=A0 is the identity at the top of the chain? Say = I have the
>>>>=C2=A0 =C2=A0 delegation A -> B -> C, and there is so= me resource which
>>>>=C2=A0 =C2=A0 B can access but A and C cannot, should I giv= e access?
>>>>
>>>> I think the first question definitely needs an answer. The= second
>>>> question I guess we could make not answer, but it's pr= etty hard to
>>>> know how to make a system with this left open..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d
>>> privileged material for the sole use of the intended recipient= (s).
>>> Any review, use, distribution or disclosure by others is stric= tly
>>> prohibited..=C2=A0 If you have received this communication in = error,
>>> please notify the sender immediately by e-mail and delete the = message
>>> and any file attachments from your computer. Thank you.
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s).= Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited..=C2=A0 If you have received this communication in erro= r, please
>> notify the sender immediately by e-mail and delete the message and= any
>> file attachments from your computer. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth=



--
Bill Burke
Red Hat


CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000002a089e056d9bee12-- From nobody Fri Jun 1 21:03:17 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F64A1250B8 for ; Fri, 1 Jun 2018 21:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU3TJtJfyJjX for ; Fri, 1 Jun 2018 21:03:10 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F47D126B7E for ; Fri, 1 Jun 2018 21:03:10 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id l13-v6so31582523otk.9 for ; Fri, 01 Jun 2018 21:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vgReGYszJrQoiPO6TGr6G0aCKE+3j3lCqE3w0LoAXyI=; b=2Fq9cKEOEazwxGLddaV6JNX0dIltXe3mfr6UD/itEznZecTC6aB7cDg0KfrI6r9BLL 3qOAcBSTFLlrQWBhkG4Mw2cU4ObShXa2j86Q5/sJ2/gMxVpNg1LmewuWzDwPdOsKHkia UOsNiXG7ZhcAAkDQeBw8PT3m72ns0LT1TLUcBl75xI/xz7n5Xl1WGQ35KFewJK36QF+e VBbZppCWbXkRVwRc4b+0mr+7ZQlbgqDK7rVjixzIYv1TKfJg22jag5WOMS6iQ+pb5+mV XJhB6xC3JEQn8hhh1AQuta67pTBWiQ0EksfStZbfYlWbFJBC3WaE08U5w0XqZ2iD7DRt yFHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vgReGYszJrQoiPO6TGr6G0aCKE+3j3lCqE3w0LoAXyI=; b=VZfzG1PjenIiABWv6/mBeDMO1T5TxaxtLHs4PFnwu+OpwZYw0YAjduPTfdx5tGlZPl Iey9aN88vRQ4jhZcFedGFSpUuduzM/B3CvR7JilHBmBpkp+RXdzyG5l79e8w+pu0VpfR NQxJPrikat7wyDnZl8TOSNFGd8CzxYvf70wmhdY9hHXQV44jFCggyGUPxKiPDrZoA0hv fmBLZO4SzLmcizAHWcf86b+VArSETkF2VHzSSL2P+n3TxwFH5JRilkFMiyqMeGec+fAb NM7CkwHF4dWlSlg6YC+Om3vVfHzEYidBK2vKe5lkXhYUVhbS+JyWhen/Sv9Jjq4GfghJ EWKw== X-Gm-Message-State: ALKqPwdzY/1Xz1H7w7xV1PicTDzGMj5f6TLziZqo6b8/3VnGFwgeo8bF LWrxVNyyCs9cXEn4gWpGRjNaTQw7BPa4uzaPrB9Afg== X-Google-Smtp-Source: ADUXVKKwiLYgN1r3fxLDunO6XRGjobrHAc4mcL2+691L4D3S2ViBweIFRYi21x3f8RX0qmx22PRvxiq+keG3S8G6uR0= X-Received: by 2002:a9d:72c6:: with SMTP id d6-v6mr8794568otk.392.1527912189295; Fri, 01 Jun 2018 21:03:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:66:0:0:0:0:0 with HTTP; Fri, 1 Jun 2018 21:02:28 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 1 Jun 2018 21:02:28 -0700 Message-ID: To: Brian Campbell Cc: oauth Content-Type: multipart/alternative; boundary="0000000000004a908c056da0c74c" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2018 04:03:15 -0000 --0000000000004a908c056da0c74c Content-Type: text/plain; charset="UTF-8" OK, well, it seems like it ought to say that that generator of the token can expect that the RP will apply an access control policy that s the union of the capabilities of the two ends of the chain -- and that while it might be less it won't be more. -Ekr On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell wrote: > I suspect that the vast majority of time C's permissions won't matter at > all. But I do think there are legitimate cases where they might be > considered in the policy decision. One general example I can think of is a > customer service rep or administrator taking override type corrective > action on an end-user's account or transaction information (A is the > end-user and C is the customer service rep) that the user on their own > wouldn't have permission to change. > > On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla wrote: > >> That would go a long way, I think. Do you think that C's permissions >> matter at all? So, say that the resource is accessible to C but not A? >> >> -Ekr >> >> >> >> >> On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> Hi Eric, >>> >>> Apologies for my somewhat slow response. I've honestly been unsure of >>> how else to try and address the comment/question. But will continue >>> trying... >>> >>> My expectation would be that access control decisions would be made >>> based on the subject of the token itself or on the current actor. And maybe >>> a combination of both in some situations (like, for example, the actor is >>> an administrator and the token allows admin level access to the stuff the >>> token subject would normally have access to). However, I don't believe >>> that nested prior actors would or should be considered in access control >>> decisions. The nesting is more just to express what has happened for >>> auditing or tracking or the like. To be honest, the nesting was added in >>> the draft largely because the structure naturally and easily allowed for it >>> and it seemed like it might be useful information to convey in some cases. >>> >>> So in that A->B->C case (the claims of such a token would, I think, look >>> like the JSON below), B *is not* giving C his authority. B is just >>> noted in the token as having been involved previously. While A is >>> identified as the subject of the token and C is the current actor. >>> >>> { >>> "aud":"... ,"iss":... , "exp":..., etc. etc. ... >>> "sub":"A", >>> "act": >>> { >>> "sub":"C", >>> "act": >>> { >>> "sub":"B" >>> } >>> } >>> } >>> >>> >>> Would some text explicitly saying that only the token subject (top level >>> sub and claims) and the party identified by the outermost "act" claim (the >>> current actor) are to be considered in access control decisions address >>> your concern? >>> >>> >>> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla wrote: >>> >>>> Hi Brian, >>>> >>>> To be clear, I'm not opposing Delegation. My concern here is that we >>>> have a chain of signed assertions and I'm trying to understand how I as a >>>> consumer of those assertions am supposed to evaluate it. >>>> >>>> I don't think it's sufficient to just say that that the access control >>>> rules are local policy, because then the entity generating the signature >>>> has no way of knowing how its signature will be used. >>>> >>>> To go back to the case I gave in my initial e-mail, say we have a chain >>>> A->B->C and a resource that A and C could ordinarily not access, but B can. >>>> If C has this delegation, can C access the resource? I.e., is B giving C >>>> his authority or just passing on A's authority? It seems pretty important >>>> for B to know that before he gives the token to C. >>>> >>>> -Ekr >>>> >>>> >>>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell < >>>> bcampbell@pingidentity.com> wrote: >>>> >>>>> Delegation has been in the document since its inception and throughout >>>>> the three and a half years as a working group document. >>>>> >>>>> From a process point of view, the document is now in AD Evaluation. I >>>>> worked through a number of questions and clarifications with Eric (said >>>>> AD), however he raised the particular questions that started this thread on >>>>> the WG list. And I responded with an attempt at addressing those questions. >>>>> That was about a month ago. >>>>> >>>>> Eric, was my explanation helpful in clarify anything for you? Is there >>>>> some text that you'd like to see added? Something else? I'm unsure how to >>>>> proceed but would like to move things forward. >>>>> >>>>> >>>>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke wrote: >>>>> >>>>>> This is an honest question: How important is the actor stuff to the >>>>>> players involved? Are people going to use it? IMO, its an edge case >>>>>> and I think more important areas, like external token exchange (realm >>>>>> to realm, domain to domain) are being neglected. I'm quite unfamiliar >>>>>> how consensus is reached in this WG or the IETF, so I hope I'm not >>>>>> sounding rude. Just trying to provide some constructive feedback. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones < >>>>>> Michael.Jones@microsoft.com> wrote: >>>>>> > Moving the actor claim to a separate specification would only make >>>>>> things more complicated for developers. There already plenty of OAuth >>>>>> specs. Needlessly adding another one will only make related things harder >>>>>> to find. >>>>>> > >>>>>> > Just like in the JWT [RFC 7519] spec itself in which use of all the >>>>>> claims is optional, use of the actor claim in this spec. If you don't need >>>>>> it, don't use it. Just because some won't use it is no better an argument >>>>>> for moving it to a different spec than the argument that JWT should have >>>>>> defined each of its claims in different specs. That would have made things >>>>>> harder, not easier. >>>>>> > >>>>>> > -- Mike >>>>>> > >>>>>> > -----Original Message----- >>>>>> > From: OAuth On Behalf Of Bill Burke >>>>>> > Sent: Thursday, May 17, 2018 2:11 PM >>>>>> > To: Brian Campbell >>>>>> > Cc: oauth >>>>>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchang >>>>>> e-12.txt >>>>>> > >>>>>> > My personal opinion is that I'm glad this actor stuff is optional. >>>>>> > For one, none of our users have asked for it and really only do >>>>>> simple exchanges. Secondly, the rules for who can exchange what for what >>>>>> is controlled and defined within our AS. Makes things a lot simpler on the >>>>>> client. I kind of wish the actor stuff would be defined in a separate >>>>>> specification. I don't see us implementing it unless users start asking us >>>>>> to. >>>>>> > >>>>>> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell < >>>>>> bcampbell@pingidentity.com> wrote: >>>>>> >> Well, it's already called the "actor claim" so the claimed part is >>>>>> >> kind of implied. And "claimed actor claim" is a rather awkward. >>>>>> >> Really, all JWT claims are "claimed something" but they don't >>>>>> include >>>>>> >> the "claimed" bit in the name. RFC 7519, for example, defines the >>>>>> >> subject claim but not the claimed subject claim. >>>>>> >> >>>>>> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis >>>>>> wrote: >>>>>> >>> >>>>>> >>> Brian, >>>>>> >>> >>>>>> >>> Eric said: "what is the RP supposed to do when they encounter it? >>>>>> >>> This seems kind of under specified". >>>>>> >>> >>>>>> >>> After reading your explanations below, it looks like the RP can do >>>>>> >>> anything he wants with the "actor". >>>>>> >>> It is a "claimed actor" and, if we keep the concept, it should be >>>>>> >>> called as such. Such a claim cannot be verified. >>>>>> >>> A RP could copy and paste that claim in an audit log. No standard >>>>>> >>> action related to the content of such a claim can be specified in >>>>>> the >>>>>> >>> spec. If the content of a "claimed actor" is used by the RP, it >>>>>> >>> should be only used as an hint and thus be subject to other >>>>>> >>> verifications which are not specified in this specification. >>>>>> >>> >>>>>> >>> Denis >>>>>> >>> >>>>>> >>> Eric, I realize you weren't particularly impressed by my prior >>>>>> >>> statements about the actor claim but, for lack of knowing what >>>>>> else >>>>>> >>> to say, I'm going to kind of repeat what I said about it over in >>>>>> the >>>>>> >>> Phabricator tool and add a little color. >>>>>> >>> >>>>>> >>> The actor claim is intended as a way to express that delegation >>>>>> has >>>>>> >>> happened and identify the entities involved. Access control or >>>>>> other >>>>>> >>> decisions based on it are at the discretion of the consumer of the >>>>>> >>> token based on whatever policy might be in place. >>>>>> >>> >>>>>> >>> There are JWT claims that have concise processing rules with >>>>>> respect >>>>>> >>> to whether or not the JWT can be accepted as valid. Some examples >>>>>> are "aud" >>>>>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) from >>>>>> RFC 7519. >>>>>> >>> E.g. if the token is expired or was intended for someone or >>>>>> something >>>>>> >>> else, reject it. >>>>>> >>> >>>>>> >>> And there are JWT claims that appropriately don't specify such >>>>>> >>> processing rules and are solely statements of fact or >>>>>> circumstance. >>>>>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) >>>>>> claims are good examples of such. >>>>>> >>> There might be application or policy specific rules applied to the >>>>>> >>> content of those kinds of claims (e.g. only subjects from a >>>>>> >>> particular organization are able to access tenant specific data >>>>>> or, >>>>>> >>> less realistic but still possible, disallow access for tokens >>>>>> issued >>>>>> >>> outside of regular business >>>>>> >>> hours) but that's all outside the scope of a specification's >>>>>> >>> definition of the claim. >>>>>> >>> >>>>>> >>> The actor claim falls into the latter category. It's a way for the >>>>>> >>> issuer of the token to tell the consumer of the token what is >>>>>> going >>>>>> >>> on. But any action to take (or not) based on that information is >>>>>> at >>>>>> >>> the discretion of the token consumer. I honestly don't know it >>>>>> could >>>>>> >>> be anything more. And don't think it should be. >>>>>> >>> >>>>>> >>> There are two main expected uses of the actor claim (that I'm >>>>>> aware >>>>>> >>> of >>>>>> >>> anyway) that describing here might help. Maybe. One is a human to >>>>>> >>> human delegation case like a customer service rep doing something >>>>>> on >>>>>> >>> behalf of an end user. The subject would be that user and the >>>>>> actor >>>>>> >>> would be the customer service rep. And there wouldn't be any >>>>>> chaining >>>>>> >>> or nesting of the actor. The other case is so called service >>>>>> chaining >>>>>> >>> where a system might exchange a token it receives for a new token >>>>>> >>> that it can use to call a downstream service. And that service in >>>>>> >>> turn might do another exchange to get a new token suitable to call >>>>>> >>> yet another downstream service. And again and so on and turtles >>>>>> all >>>>>> >>> the way. I'm not necessarily endorsing that level of granularity >>>>>> in >>>>>> >>> chaining but it's bound to happen somewhere/sometime. The nested >>>>>> >>> actor claim is able to express that all that has happened with the >>>>>> >>> top level or outermost one being the system currently using the >>>>>> token >>>>>> >>> and prior systems being nested.. What actually gets done with that >>>>>> >>> information is up to the respective systems involved. There might >>>>>> be >>>>>> >>> policy about what system is allowed to call what other system >>>>>> that is >>>>>> >>> enforced. Or maybe the info is just written to an audit log >>>>>> >>> somewhere. Or something else. I don't know. But whatever it is >>>>>> application/deployment/policy dependent and not specifiable by a spec. >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla >>>>>> wrote: >>>>>> >>>> >>>>>> >>>> Hi folks, >>>>>> >>>> >>>>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things >>>>>> seem >>>>>> >>>> generally OK. I do still have one remaining concern, which is >>>>>> about >>>>>> >>>> the actor claim. Specifically, what is the RP supposed to do when >>>>>> >>>> they encounter it? This seems kind of underspecified. >>>>>> >>>> >>>>>> >>>> In particular: >>>>>> >>>> >>>>>> >>>> 1. What facts am I supposed to know here? Merely that everyone in >>>>>> >>>> the chain signed off on the next person in the chain acting >>>>>> as them? >>>>>> >>>> >>>>>> >>>> 2. Am I just supposed to pretend that the person presenting the >>>>>> token >>>>>> >>>> is the identity at the top of the chain? Say I have the >>>>>> >>>> delegation A -> B -> C, and there is some resource which >>>>>> >>>> B can access but A and C cannot, should I give access? >>>>>> >>>> >>>>>> >>>> I think the first question definitely needs an answer. The second >>>>>> >>>> question I guess we could make not answer, but it's pretty hard >>>>>> to >>>>>> >>>> know how to make a system with this left open.. >>>>>> >>>> >>>>>> >>>> -Ekr >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> _______________________________________________ >>>>>> >>>> OAuth mailing list >>>>>> >>>> OAuth@ietf.org >>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>> >>>>>> >>> >>>>>> >>> >>>>>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> >>> privileged material for the sole use of the intended recipient(s). >>>>>> >>> Any review, use, distribution or disclosure by others is strictly >>>>>> >>> prohibited.. If you have received this communication in error, >>>>>> >>> please notify the sender immediately by e-mail and delete the >>>>>> message >>>>>> >>> and any file attachments from your computer. Thank you. >>>>>> >>> >>>>>> >>> _______________________________________________ >>>>>> >>> OAuth mailing list >>>>>> >>> OAuth@ietf.org >>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> _______________________________________________ >>>>>> >>> OAuth mailing list >>>>>> >>> OAuth@ietf.org >>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>> >>>>>> >> >>>>>> >> >>>>>> >> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> >> privileged material for the sole use of the intended recipient(s). >>>>>> Any >>>>>> >> review, use, distribution or disclosure by others is strictly >>>>>> >> prohibited.. If you have received this communication in error, >>>>>> please >>>>>> >> notify the sender immediately by e-mail and delete the message and >>>>>> any >>>>>> >> file attachments from your computer. Thank you. >>>>>> >> _______________________________________________ >>>>>> >> OAuth mailing list >>>>>> >> OAuth@ietf.org >>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >> >>>>>> > >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Bill Burke >>>>>> > Red Hat >>>>>> > >>>>>> > _______________________________________________ >>>>>> > OAuth mailing list >>>>>> > OAuth@ietf.org >>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Bill Burke >>>>>> Red Hat >>>>>> >>>>> >>>>> >>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>> privileged material for the sole use of the intended recipient(s). Any >>>>> review, use, distribution or disclosure by others is strictly prohibited. >>>>> If you have received this communication in error, please notify the sender >>>>> immediately by e-mail and delete the message and any file attachments from >>>>> your computer. Thank you.* >>>> >>>> >>>> >>> >>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>> privileged material for the sole use of the intended recipient(s). Any >>> review, use, distribution or disclosure by others is strictly prohibited. >>> If you have received this communication in error, please notify the sender >>> immediately by e-mail and delete the message and any file attachments from >>> your computer. Thank you.* >>> >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > --0000000000004a908c056da0c74c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, well, it seems like it ought to say that that gen= erator of the token can expect that the RP will apply an access control pol= icy that s the union of the capabilities of the two ends of the chain -- an= d that while it might be less it won't be more.

-Ekr


On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
I suspect that the vast majority of time C= 's permissions won't matter at all. But I do think there are legiti= mate cases where they might be considered in the policy decision. One gener= al example I can think of is a customer service rep or administrator taking= override type corrective action on an end-user's account or transactio= n information (A is the end-user and C is the customer service rep) that th= e user on their own wouldn't have permission to change. =C2=A0
=
On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
That would go a long way, I think. Do you think that C's= permissions matter at all? So, say that the resource is accessible to C bu= t not A?

-Ekr




On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <bc= ampbell@pingidentity.com> wrote:
Hi Eric,

Apologie= s for my somewhat slow response. I've honestly been unsure of how else = to try and address the comment/question. But will continue trying...=C2=A0 =

My expectation would be that access control d= ecisions would be made based on the subject of the token itself or on the c= urrent actor. And maybe a combination of both in some situations (like, for= example, the actor is an administrator and the token allows admin level ac= cess to the stuff the token subject would normally have access to).=C2=A0 H= owever, I don't believe that nested prior actors would or should be con= sidered in access control decisions. The nesting is more just to express wh= at has happened for auditing or tracking or the like. To be honest, the nes= ting was added in the draft largely because the structure naturally and eas= ily allowed for it and it seemed like it might be useful information to con= vey in some cases.

So in that A->B->C c= ase (the claims of such a token would, I think, look like the JSON below), = B is not giving C his=C2=A0authority. B is just noted in the token a= s having been involved previously.=C2=A0 While A is identified as the subje= ct of the token and C is the current actor.

<= pre class=3D"m_2013390948615437533m_-1582878555692439640m_53777438705659816= 29gmail-m_8378560348234984766gmail-m_6369459926104603262m_84289342112283200= 3gmail-m_3377091152811425824gmail-newpage"> { "aud":"... ,"iss":... , "exp":...,= etc. etc. ... "sub":"A", "act": { "sub":"C", "act": { "sub":"B" } } }
Would some text explicitly saying that only the t= oken subject (top level sub and claims) and the party identified by the out= ermost "act" claim (the current actor) are to be considered in ac= cess control decisions address your concern?


On Tue, May 29, 2018 at 4:19 PM, Eric Re= scorla <ekr@rtfm.com> wrote:
Hi Brian,

To be clear, I'm= not opposing Delegation. My concern here is that we have a chain of signed= assertions and I'm trying to understand how I as a consumer of those a= ssertions am supposed to evaluate it.

I don't = think it's sufficient to just say that that the access control rules ar= e local policy, because then the entity generating the signature has no way= of knowing how its signature will be used.

To go = back to the case I gave in my initial e-mail, say we have a chain A->B-&= gt;C and a resource that A and C could ordinarily not access, but B can. If= C has this delegation, can C access the resource? I.e., is B giving C his = authority or just passing on A's authority? It seems pretty important f= or B to know that before he gives the token to C.

<= div>-Ekr


On Thu, May 17, 2018 at 11:06 AM, Brian Campb= ell <bcampbell@pingidentity.com> wrote:
Delega= tion has been in the document since its inception and throughout the three = and a half years as a working group document.

From a process point of view, the document is now in=C2=A0AD Evaluation. I= worked through a number of questions and clarifications with Eric (said AD= ), however he raised the particular questions that started this thread on t= he WG list. And I responded with an attempt at addressing those questions. = That was about a month ago.

Eric, was my expl= anation helpful in clarify anything for you? Is there some text that you= 9;d like to see added? Something else? I'm unsure how to proceed but wo= uld like to move things forward.


On Thu, May = 17, 2018 at 8:03 AM, Bill Burke <bburke@redhat.com> wrote:
This is an honest question: How important = is the actor stuff to the
players involved?=C2=A0 Are people going to use it?=C2=A0 IMO, its an edge = case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.=C2=A0 I'm quite unfami= liar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.=C2=A0 Just trying to provide some constructive feedback.



On Thu, May 17, 2018 at 9:26 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:
> Moving the actor claim to a separate specification would only make thi= ngs more complicated for developers.=C2=A0 There already plenty of OAuth sp= ecs.=C2=A0 Needlessly adding another one will only make related things hard= er to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the cl= aims is optional, use of the actor claim in this spec.=C2=A0 If you don'= ;t need it, don't use it.=C2=A0 Just because some won't use it is n= o better an argument for moving it to a different spec than the argument th= at JWT should have defined each of its claims in different specs.=C2=A0 Tha= t would have made things harder, not easier.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell <bcampbell@pingidentity.com>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.=
> For one, none of our users have asked for it and really only do simple= exchanges.=C2=A0 Secondly, the rules for who can exchange what for what is= controlled and defined within our AS.=C2=A0 Makes things a lot simpler on = the client.=C2=A0 I kind of wish the actor stuff would be defined in a sepa= rate specification.=C2=A0 I don't see us implementing it unless users s= tart asking us to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Well, it's already called the "actor claim" so the c= laimed part is
>> kind of implied. And "claimed actor claim" is a rather a= wkward.
>> Really, all JWT claims are "claimed something" but they = don't include
>> the "claimed" bit in the name. RFC 7519, for example, de= fines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encou= nter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP ca= n do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept,= it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No stand= ard
>>> action related to the content of such a claim can be specified= in the
>>> spec. If the content of a "claimed actor" is used by= the RP, it
>>> should be only used as an hint and thus be subject to other >>> verifications which are not specified in this specification. >>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my p= rior
>>> statements about the actor claim but, for lack of knowing what= else
>>> to say, I'm going to kind of repeat what I said about it o= ver in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegatio= n has
>>> happened and identify the entities involved. Access control or= other
>>> decisions based on it are at the discretion of the consumer of= the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with r= espect
>>> to whether or not the JWT can be accepted as valid. Some examp= les are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf&q= uot; (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or so= mething
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify = such
>>> processing rules and are solely statements of fact or circumst= ance.
>>> Also from RFC 7519, the "sub" (Subject) and "ia= t" (Issued At) claims are good examples of such.
>>> There might be application or policy specific rules applied to= the
>>> content of those kinds of claims (e.g. only subjects from a >>> particular organization are able to access tenant specific dat= a or,
>>> less realistic but still possible, disallow access for tokens = issued
>>> outside of regular business
>>> hours) but that's all outside the scope of a specification= 's
>>> definition of the claim.
>>>
>>> The actor claim falls into the latter category. It's a way= for the
>>> issuer of the token to tell the consumer of the token what is = going
>>> on. But any action to take (or not) based on that information = is at
>>> the discretion of the token consumer. I honestly don't kno= w it could
>>> be anything more. And don't think it should be.
>>>
>>> There are two main expected uses of the actor claim (that I= 9;m aware
>>> of
>>> anyway) that describing here might help. Maybe. One is a human= to
>>> human delegation case like a customer service rep doing someth= ing on
>>> behalf of an end user. The subject would be that user and the = actor
>>> would be the customer service rep. And there wouldn't be a= ny chaining
>>> or nesting of the actor. The other case is so called service c= haining
>>> where a system might exchange a token it receives for a new to= ken
>>> that it can use to call a downstream service. And that service= in
>>> turn might do another exchange to get a new token suitable to = call
>>> yet another downstream service. And again and so on and turtle= s all
>>> the way. I'm not necessarily endorsing that level of granu= larity in
>>> chaining but it's bound to happen somewhere/sometime. The = nested
>>> actor claim is able to express that all that has happened with= the
>>> top level or outermost one being the system currently using th= e token
>>> and prior systems being nested.. What actually gets done with = that
>>> information is up to the respective systems involved. There mi= ght be
>>> policy about what system is allowed to call what other system = that is
>>> enforced. Or maybe the info is just written to an audit log >>> somewhere. Or something else. I don't know. But whatever i= t is application/deployment/policy dependent and not specifiable by a spec.=
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I've gone over draft-ietf-oauth-token-exchange-12= and things seem
>>>> generally OK. I do still have one remaining concern, which= is about
>>>> the actor claim. Specifically, what is the RP supposed to = do when
>>>> they encounter it? This seems kind of underspecified.
>>>>
>>>> In particular:
>>>>
>>>> 1. What facts am I supposed to know here? Merely that ever= yone in
>>>>=C2=A0 =C2=A0 the chain signed off on the next person in th= e chain acting as them?
>>>>
>>>> 2. Am I just supposed to pretend that the person presentin= g the token
>>>>=C2=A0 =C2=A0 is the identity at the top of the chain? Say = I have the
>>>>=C2=A0 =C2=A0 delegation A -> B -> C, and there is so= me resource which
>>>>=C2=A0 =C2=A0 B can access but A and C cannot, should I giv= e access?
>>>>
>>>> I think the first question definitely needs an answer. The= second
>>>> question I guess we could make not answer, but it's pr= etty hard to
>>>> know how to make a system with this left open..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d
>>> privileged material for the sole use of the intended recipient= (s).
>>> Any review, use, distribution or disclosure by others is stric= tly
>>> prohibited..=C2=A0 If you have received this communication in = error,
>>> please notify the sender immediately by e-mail and delete the = message
>>> and any file attachments from your computer. Thank you.
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s).= Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited..=C2=A0 If you have received this communication in erro= r, please
>> notify the sender immediately by e-mail and delete the message and= any
>> file attachments from your computer. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth=



--
Bill Burke
Red Hat


CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.

--0000000000004a908c056da0c74c-- From nobody Fri Jun 1 21:46:49 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069D0126C3D for ; Fri, 1 Jun 2018 21:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5MSM-WsJDUq for ; Fri, 1 Jun 2018 21:46:45 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0125.outbound.protection.outlook.com [104.47.37.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0A6D126C19 for ; Fri, 1 Jun 2018 21:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=plea0gXWKacsu4zLoFttdJfJRIYYNqKCf9XFFOQl+5c=; b=GPnN9Wx6Tnzrfwhjyg0/R5fYSAXqy6WRcCKWVdp4ewLpLWFkxoo3ESNwlNOVzqk9duZZ4QORPkrOkR6tW66qAHNBr6S7d1zbMR6q1/2gjPapGvF//ldGiFKmakmH+M8M+WdCU7Q7qJyihqnwD6PaxTj+5ojCQYiCiDglKqGDCVI= Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.866.0; Sat, 2 Jun 2018 04:46:39 +0000 Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::aca1:f57b:1ff5:d616]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::aca1:f57b:1ff5:d616%2]) with mapi id 15.20.0866.000; Sat, 2 Jun 2018 04:46:39 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Device Flow spec addressing initial IETF last call feedback Thread-Index: AdP6KcjgkUDGdlROQiGr8D/Q+m5Bww== Date: Sat, 2 Jun 2018 04:46:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.47.80.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR00MB0292; 7:Rczoob9geEs1puLOXxWbIi1aKav734TXcjF+fnMM9YtsgNo41bAgf4nBlSZQKgEu0xC4XQ64O9uHIWIJtlfOheXorHRp/dgK0FtnXfAQAcrtl0IZ8NUkwP5eB6s4B2iP2kEmUzgYXpKs/JrNStTjvo4mAik4nSfxQzy9SO61bufLR/rqKm0Haellw8skw72CNPz30OLZVcIrw2SwKuFGn0H+OYMmRJnf4XGmSVTmjAaueG76LmpDs11Mii35+Bql; 20:PHbI3JAO6DaPKUVaPQVISljBSXBIjEU1GPZGCC5vkATaailz+zNnI3L9K8WT/GHxLYFxMDpUI1iqo1oBNNPi1P+jyQGYPtUa1hA+Xj4ix5m7UT6hpfhWZCAfBmF77O2acp2Ocrl16HY+Ce5V2aqLhCuS9KaaUKGJgHw9seFklis= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7193020); SRVR:BL0PR00MB0292; x-ms-traffictypediagnostic: BL0PR00MB0292: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(31418570063057)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(3231254)(2018427008)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BL0PR00MB0292; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0292; x-forefront-prvs: 06911FE69E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(346002)(396003)(376002)(366004)(209900001)(199004)(189003)(2900100001)(68736007)(5630700001)(1730700003)(8936002)(8990500004)(3660700001)(3280700002)(8676002)(53376002)(81166006)(81156014)(53936002)(476003)(86362001)(2501003)(486006)(236005)(7696005)(26005)(6506007)(99286004)(186003)(86612001)(6306002)(9686003)(2906002)(54896002)(59450400001)(5250100002)(21615005)(66066001)(102836004)(790700001)(3846002)(606006)(10290500003)(6116002)(2351001)(55016002)(33656002)(14454004)(106356001)(105586002)(966005)(72206003)(478600001)(7736002)(25786009)(6916009)(316002)(74316002)(22452003)(97736004)(6436002)(5660300001)(10090500001)(5640700003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0292; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: MyYv4XgNLG1WWbcLP54OToc1zZpn3XwFoMxb0tMT58ew2WRFEpnfpr+5XnY4Pj+uvDNBAtwzPbgvW4TqFDXNypSG7Jwyz0kdD3rvrFuH8StO6kjSfI/hyNle81qTXCW3SsmjZRC5PN98HjTSDaSIkjHDKhmBCxABijDoEGWOQyFtLjNDDmOZS0m+uVSVfNDt spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292AA578541577799FDE804F5610BL0PR00MB0292namp_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: fe73d352-9045-426a-337c-08d5c843d466 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe73d352-9045-426a-337c-08d5c843d466 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2018 04:46:39.3894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0292 Archived-At: Subject: [OAUTH-WG] OAuth Device Flow spec addressing initial IETF last call feedback X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2018 04:46:48 -0000 --_000_BL0PR00MB0292AA578541577799FDE804F5610BL0PR00MB0292namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth Device Flow specification (full name "OAuth 2.0 Device Flow for B= rowserless and Input Constrained Devices") has been updated to address comm= ents received to date from the IETF last call. Thanks to William Denniss for taking the pen for this set of revisions. Changes were: * Added a missing definition of access_denied for use on the token endp= oint. * Corrected text documenting which error code should be returned for ex= pired tokens (it's "expired_token", not "invalid_grant"). * Corrected section reference to RFC 8252 (the section numbers had chan= ged after the initial reference was made). * Fixed line length of one diagram (was causing xml2rfc warnings). * Added line breaks so the URN grant_type is presented on an unbroken l= ine. * Typos fixed and other stylistic improvements. The specification is available at: * https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-device-flow-10.html -- Mike P.S. This notice was also published at http://self-issued.info/?p=3D1873 a= nd as @selfissued. --_000_BL0PR00MB0292AA578541577799FDE804F5610BL0PR00MB0292namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The OAuth Device Flow specification (full name ̶= 0;OAuth 2.0 Device Flow for Browserless and Input Constrained Devices”= ;) has been updated to address comments received to date from the IETF last= call.  Thanks to William Denniss for taking the pen for this set of revisions.  Cha= nges were:

  • Added a missing definition of access_denied for use on the token endp= oint.
  • Corrected text documenting which error code should be= returned for expired tokens (it's "expired_token", not "inv= alid_grant").
  • Corrected section reference to RFC 8252 (the section = numbers had changed after the initial reference was made).
  • Fixed line length of one diagram (was causing xml2rfc= warnings).
  • Added line breaks so the URN grant_type is presented = on an unbroken line.
  • Typos fixed and other stylistic improvements.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

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

 

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

 

--_000_BL0PR00MB0292AA578541577799FDE804F5610BL0PR00MB0292namp_-- From nobody Mon Jun 4 07:06:46 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74487127058; Mon, 4 Jun 2018 07:06:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152812119841.20920.13722113888347703998@ietfa.amsl.com> Date: Mon, 04 Jun 2018 07:06:38 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-09.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 14:06:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens Authors : Brian Campbell John Bradley Nat Sakimura Torsten Lodderstedt Filename : draft-ietf-oauth-mtls-09.txt Pages : 21 Date : 2018-06-04 Abstract: This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization sever using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-mtls-09 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 4 09:30:10 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F72F1286CD for ; Mon, 4 Jun 2018 09:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6wcGglsW2c1 for ; Mon, 4 Jun 2018 09:30:00 -0700 (PDT) Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5155A126CE2 for ; Mon, 4 Jun 2018 09:30:00 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fPsMn-0002n7-Hc; Mon, 04 Jun 2018 18:29:57 +0200 From: Torsten Lodderstedt Message-Id: <2F83959E-1CE4-46D8-9AEF-F35F5B958D29@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_63161726-6057-4794-8B84-A6E99A6A0E41"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Mon, 4 Jun 2018 18:29:48 +0200 In-Reply-To: <37aa8ce8-c999-57bd-e4d5-387c6e365adc@aol.com> Cc: oauth To: George Fletcher References: <152752608213.4961.1659822390005305046.idtracker@ietfa.amsl.com> <4D24E05B-EDC1-458C-A106-662345090399@lodderstedt.net> <37aa8ce8-c999-57bd-e4d5-387c6e365adc@aol.com> X-Mailer: Apple Mail (2.3445.6.18) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 16:30:09 -0000 --Apple-Mail=_63161726-6057-4794-8B84-A6E99A6A0E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi George,=20 > Am 01.06.2018 um 17:41 schrieb George Fletcher : >=20 > What is the expectation if the RS requests a signed JWT response but = the AS doesn't support it? Should getting a signed response require = both? (meaning the Accept header and an AS config that that RP wants = it)? That may be the safest from a backward compatibility perspective. we assume the RS is set up with the AS in advance, so the RS should know = whether the AS supports signing.=20 >=20 > I have some concerns around relying on 'iss' and 'aud' to prevent = abuse It=E2=80=99s iss + aud + all replay prevention means you can think of = (including token binding). > and wonder if a JWT Header claim describing the context of the JWT = might be better.=20 Any suggestions (cty)? I=E2=80=99m not sure abuse can be prevented that = way since developers need to consider this header claim. best regards, Torsten.=20 >=20 > Thanks, > George >=20 > On 5/28/18 12:58 PM, Torsten Lodderstedt wrote: >> Hi all,=20 >>=20 >> I just published a new revision of the JWT Introspection response = draft. Based on the feedback in London, the draft entirely focuses on = use cases where the RS requires stronger assurance that the respective = AS issued the token, including cases where the AS assumes liability for = the token=E2=80=99s content.=20 >>=20 >> We incorporated the following changes: >> =E2=80=A2 fixed typos in client meta data field names (thanks = Petteri!) >> =E2=80=A2 added OAuth Server Metadata parameters to publish = algorithms supported for signing and encrypting the introspection = response >> =E2=80=A2 added registration of new parameters for OAuth Server = Metadata and Client Registration >> =E2=80=A2 added explicit request for JWT introspection response >> =E2=80=A2 made iss and aud claims mandatory in introspection = response (thanks Neil!) >> =E2=80=A2 Stylistic and clarifying edits, updates references >>=20 >> Thanks to all reviewers! >>=20 >> Vladimir and I are on the fence whether the Introspection Response = format should be determined by the AS based on its policy and/or = RS-related registration metadata or whether the RS should explicitly = request a JWT response by including an Accept header = =E2=80=9Eapplication/jwt=E2=80=9C in the respective request.=20 >>=20 >> What do you think? >>=20 >> kind regards, >> Torsten. >>=20 >>> Anfang der weitergeleiteten Nachricht: >>>=20 >>> Von: internet-drafts@ietf.org >>> Betreff: New Version Notification for = draft-lodderstedt-oauth-jwt-introspection-response-01.txt >>> Datum: 28. Mai 2018 um 18:48:02 MESZ >>> An: "Vladimir Dzhuvinov" , "Torsten = Lodderstedt" >>>=20 >>>=20 >>> A new version of I-D, = draft-lodderstedt-oauth-jwt-introspection-response-01.txt >>> has been successfully submitted by Torsten Lodderstedt and posted to = the >>> IETF repository. >>>=20 >>> Name: = draft-lodderstedt-oauth-jwt-introspection-response >>> Revision: 01 >>> Title: JWT Response for OAuth Token Introspection >>> Document date: 2018-05-28 >>> Group: Individual Submission >>> Pages: 10 >>> URL: = https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspec= tion-response-01.txt >>> Status: = https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection= -response/ >>> Htmlized: = https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-resp= onse-01 >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspe= ction-response >>> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-lodderstedt-oauth-jwt-introspect= ion-response-01 >>>=20 >>> Abstract: >>> This draft proposes an additional JSON Web Token (JWT) based = response >>> for OAuth 2.0 Token Introspection. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_63161726-6057-4794-8B84-A6E99A6A0E41 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNjA0MTYyOTQ5WjAjBgkqhkiG9w0BCQQxFgQUJhWfiW9I/vSc JyHfmHZBevmRwTEwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAJKu8DM1wUkT8hddTFkPC13VghAxxxXjOwo5woeqYbLotqDaxVQk WFI5k+yvaWAlvw57CAJOLXK2wPm6oYtBpATOKfqO4rZXkBX4sokvj1pAmto3RaVTRMdPaS6rDgsD lH1kvcgHj0qnkIH3GcJzK7NLPcEE8kin5bGgBNsFiKOZYIitzhVUoPRJmzvIOVntur4iyhruu0Rb kJV8LxvTgT993uTuU6HjnhVcQQjLoZuYhONUrtDsHp/IxvlLl4Krht10ozE++m4LIUj5aiNFgQUr aZXo4M6CpANhcWmR9AIai8gye6ggCvl6Pqub9CEiKCChN4CQ9n2Ek57febLhKGoAAAAAAAA= --Apple-Mail=_63161726-6057-4794-8B84-A6E99A6A0E41-- From nobody Mon Jun 4 13:37:47 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6530A130E3C; Mon, 4 Jun 2018 13:37:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152814465537.30758.5136831560435531523@ietfa.amsl.com> Date: Mon, 04 Jun 2018 13:37:35 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-14.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 20:37:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-14.txt Pages : 33 Date : 2018-06-04 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-exchange-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 4 13:45:48 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1A1130DE1 for ; Mon, 4 Jun 2018 13:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9eYLdEK-wA9 for ; Mon, 4 Jun 2018 13:45:41 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8111130DC0 for ; Mon, 4 Jun 2018 13:45:40 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id l19-v6so615294ioj.5 for ; Mon, 04 Jun 2018 13:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yhDZ0vLPpJt2O9IvYA4YJ3apN9wTp+ApAcjNsVWUKcA=; b=nNo5Pz2qON5mCiPytfktzILlaGQUHquredKHd6qbF893VdF+4pC0fXOKIbBYP3S353 c0MBwRmRZFi20vW40R/iISCguKrj0Ma+RIhTN68slk3r+8a+tbMpGvQ8W0pnSPYJMPuW 5l1CltcRr9tPV0Dp3K1BfnpezDwKWtCN5xbRE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yhDZ0vLPpJt2O9IvYA4YJ3apN9wTp+ApAcjNsVWUKcA=; b=IwT5NYhmGRj1teSfy6NLkrbHgOz04Vq2rftOFKWaPRFTtRPsOTNakL438wkP+eWKZq /IFuaRvmDbot8Hlr7iTF9f+pAg7SwQwzYpbmrd9pBdGnaxcPGALs2hLBoFx1NPh4VyF3 k7mea3FNvI2OWMoL8BQ6q0Mex46aabzOArGGJQGcK+4jD0FQg4GC1/Zwbunf5GTGQ5K+ kyzFCdmvKYqAGEY5xsYh7mJYsMqeZ04vvjEabiPKFC2Ta3FCwIfAEQFh0zNhG5eSfrDS VThZGr9WXv0FDFtYgqfRdrQfy2YVlJipYP2S9l91Ek0pddMk6qO00lXeDHL9DV95d1zu Qftg== X-Gm-Message-State: APt69E2xptr5MaLRLhnH6tz8KFkVnuJ2WWQBwJhqXaz5XeRH/tC56b+5 tr0/bcVXa/oFZiVJyXBvlRNix7O4OLX4xFjFhJVKvpqP78vP+l1SABO/h0786y526G24c8ZW0j5 5ZRIZVC4TTfEkbNck X-Google-Smtp-Source: ADUXVKIuZEFwhvfS/RfgQNfRrKv/XXRyzz5JHYIo76IbtYsaPM/zDi1TQzfRJ2ha0LxTgp7Osc+2sE4gbV9bd/Jt67E= X-Received: by 2002:a6b:588:: with SMTP id 130-v6mr15616021iof.282.1528145139677; Mon, 04 Jun 2018 13:45:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:144a:0:0:0:0:0 with HTTP; Mon, 4 Jun 2018 13:45:08 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 4 Jun 2018 14:45:08 -0600 Message-ID: To: Eric Rescorla Cc: oauth Content-Type: multipart/alternative; boundary="000000000000375c49056dd70451" Archived-At: Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2018 20:45:46 -0000 --000000000000375c49056dd70451 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Eric, I've added text in the just submitted -14 saying that only the two ends of the chain are to be considered in access control policy decisions. diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-exchange-14 htmlized: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-14 On Fri, Jun 1, 2018 at 10:02 PM, Eric Rescorla wrote: > OK, well, it seems like it ought to say that that generator of the token > can expect that the RP will apply an access control policy that s the uni= on > of the capabilities of the two ends of the chain -- and that while it mig= ht > be less it won't be more. > > -Ekr > > > On Fri, Jun 1, 2018 at 3:15 PM, Brian Campbell > wrote: > >> I suspect that the vast majority of time C's permissions won't matter at >> all. But I do think there are legitimate cases where they might be >> considered in the policy decision. One general example I can think of is= a >> customer service rep or administrator taking override type corrective >> action on an end-user's account or transaction information (A is the >> end-user and C is the customer service rep) that the user on their own >> wouldn't have permission to change. >> >> On Fri, Jun 1, 2018 at 3:47 PM, Eric Rescorla wrote: >> >>> That would go a long way, I think. Do you think that C's permissions >>> matter at all? So, say that the resource is accessible to C but not A? >>> >>> -Ekr >>> >>> >>> >>> >>> On Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell < >>> bcampbell@pingidentity.com> wrote: >>> >>>> Hi Eric, >>>> >>>> Apologies for my somewhat slow response. I've honestly been unsure of >>>> how else to try and address the comment/question. But will continue >>>> trying... >>>> >>>> My expectation would be that access control decisions would be made >>>> based on the subject of the token itself or on the current actor. And = maybe >>>> a combination of both in some situations (like, for example, the actor= is >>>> an administrator and the token allows admin level access to the stuff = the >>>> token subject would normally have access to). However, I don't believ= e >>>> that nested prior actors would or should be considered in access contr= ol >>>> decisions. The nesting is more just to express what has happened for >>>> auditing or tracking or the like. To be honest, the nesting was added = in >>>> the draft largely because the structure naturally and easily allowed f= or it >>>> and it seemed like it might be useful information to convey in some ca= ses. >>>> >>>> So in that A->B->C case (the claims of such a token would, I think, >>>> look like the JSON below), B *is not* giving C his authority. B is >>>> just noted in the token as having been involved previously. While A i= s >>>> identified as the subject of the token and C is the current actor. >>>> >>>> { >>>> "aud":"... ,"iss":... , "exp":..., etc. etc. ... >>>> "sub":"A", >>>> "act": >>>> { >>>> "sub":"C", >>>> "act": >>>> { >>>> "sub":"B" >>>> } >>>> } >>>> } >>>> >>>> >>>> Would some text explicitly saying that only the token subject (top >>>> level sub and claims) and the party identified by the outermost "act" = claim >>>> (the current actor) are to be considered in access control decisions >>>> address your concern? >>>> >>>> >>>> On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla wrote: >>>> >>>>> Hi Brian, >>>>> >>>>> To be clear, I'm not opposing Delegation. My concern here is that we >>>>> have a chain of signed assertions and I'm trying to understand how I = as a >>>>> consumer of those assertions am supposed to evaluate it. >>>>> >>>>> I don't think it's sufficient to just say that that the access contro= l >>>>> rules are local policy, because then the entity generating the signat= ure >>>>> has no way of knowing how its signature will be used. >>>>> >>>>> To go back to the case I gave in my initial e-mail, say we have a >>>>> chain A->B->C and a resource that A and C could ordinarily not access= , but >>>>> B can. If C has this delegation, can C access the resource? I.e., is = B >>>>> giving C his authority or just passing on A's authority? It seems pre= tty >>>>> important for B to know that before he gives the token to C. >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> On Thu, May 17, 2018 at 11:06 AM, Brian Campbell < >>>>> bcampbell@pingidentity.com> wrote: >>>>> >>>>>> Delegation has been in the document since its inception and >>>>>> throughout the three and a half years as a working group document. >>>>>> >>>>>> From a process point of view, the document is now in AD Evaluation. = I >>>>>> worked through a number of questions and clarifications with Eric (s= aid >>>>>> AD), however he raised the particular questions that started this th= read on >>>>>> the WG list. And I responded with an attempt at addressing those que= stions. >>>>>> That was about a month ago. >>>>>> >>>>>> Eric, was my explanation helpful in clarify anything for you? Is >>>>>> there some text that you'd like to see added? Something else? I'm un= sure >>>>>> how to proceed but would like to move things forward. >>>>>> >>>>>> >>>>>> On Thu, May 17, 2018 at 8:03 AM, Bill Burke >>>>>> wrote: >>>>>> >>>>>>> This is an honest question: How important is the actor stuff to the >>>>>>> players involved? Are people going to use it? IMO, its an edge ca= se >>>>>>> and I think more important areas, like external token exchange (rea= lm >>>>>>> to realm, domain to domain) are being neglected. I'm quite >>>>>>> unfamiliar >>>>>>> how consensus is reached in this WG or the IETF, so I hope I'm not >>>>>>> sounding rude. Just trying to provide some constructive feedback. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, May 17, 2018 at 9:26 AM, Mike Jones < >>>>>>> Michael.Jones@microsoft.com> wrote: >>>>>>> > Moving the actor claim to a separate specification would only mak= e >>>>>>> things more complicated for developers. There already plenty of OA= uth >>>>>>> specs. Needlessly adding another one will only make related things= harder >>>>>>> to find. >>>>>>> > >>>>>>> > Just like in the JWT [RFC 7519] spec itself in which use of all >>>>>>> the claims is optional, use of the actor claim in this spec. If yo= u don't >>>>>>> need it, don't use it. Just because some won't use it is no better= an >>>>>>> argument for moving it to a different spec than the argument that J= WT >>>>>>> should have defined each of its claims in different specs. That wo= uld have >>>>>>> made things harder, not easier. >>>>>>> > >>>>>>> > -- Mike >>>>>>> > >>>>>>> > -----Original Message----- >>>>>>> > From: OAuth On Behalf Of Bill Burke >>>>>>> > Sent: Thursday, May 17, 2018 2:11 PM >>>>>>> > To: Brian Campbell >>>>>>> > Cc: oauth >>>>>>> > Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchan= g >>>>>>> e-12.txt >>>>>>> > >>>>>>> > My personal opinion is that I'm glad this actor stuff is optional= . >>>>>>> > For one, none of our users have asked for it and really only do >>>>>>> simple exchanges. Secondly, the rules for who can exchange what fo= r what >>>>>>> is controlled and defined within our AS. Makes things a lot simple= r on the >>>>>>> client. I kind of wish the actor stuff would be defined in a separ= ate >>>>>>> specification. I don't see us implementing it unless users start a= sking us >>>>>>> to. >>>>>>> > >>>>>>> > On Wed, May 16, 2018 at 6:11 PM, Brian Campbell < >>>>>>> bcampbell@pingidentity.com> wrote: >>>>>>> >> Well, it's already called the "actor claim" so the claimed part = is >>>>>>> >> kind of implied. And "claimed actor claim" is a rather awkward. >>>>>>> >> Really, all JWT claims are "claimed something" but they don't >>>>>>> include >>>>>>> >> the "claimed" bit in the name. RFC 7519, for example, defines th= e >>>>>>> >> subject claim but not the claimed subject claim. >>>>>>> >> >>>>>>> >> On Fri, Apr 20, 2018 at 11:38 AM, Denis >>>>>>> wrote: >>>>>>> >>> >>>>>>> >>> Brian, >>>>>>> >>> >>>>>>> >>> Eric said: "what is the RP supposed to do when they encounter i= t? >>>>>>> >>> This seems kind of under specified". >>>>>>> >>> >>>>>>> >>> After reading your explanations below, it looks like the RP can >>>>>>> do >>>>>>> >>> anything he wants with the "actor". >>>>>>> >>> It is a "claimed actor" and, if we keep the concept, it should = be >>>>>>> >>> called as such. Such a claim cannot be verified. >>>>>>> >>> A RP could copy and paste that claim in an audit log. No standa= rd >>>>>>> >>> action related to the content of such a claim can be specified >>>>>>> in the >>>>>>> >>> spec. If the content of a "claimed actor" is used by the RP, it >>>>>>> >>> should be only used as an hint and thus be subject to other >>>>>>> >>> verifications which are not specified in this specification. >>>>>>> >>> >>>>>>> >>> Denis >>>>>>> >>> >>>>>>> >>> Eric, I realize you weren't particularly impressed by my prior >>>>>>> >>> statements about the actor claim but, for lack of knowing what >>>>>>> else >>>>>>> >>> to say, I'm going to kind of repeat what I said about it over i= n >>>>>>> the >>>>>>> >>> Phabricator tool and add a little color. >>>>>>> >>> >>>>>>> >>> The actor claim is intended as a way to express that delegation >>>>>>> has >>>>>>> >>> happened and identify the entities involved. Access control or >>>>>>> other >>>>>>> >>> decisions based on it are at the discretion of the consumer of >>>>>>> the >>>>>>> >>> token based on whatever policy might be in place. >>>>>>> >>> >>>>>>> >>> There are JWT claims that have concise processing rules with >>>>>>> respect >>>>>>> >>> to whether or not the JWT can be accepted as valid. Some >>>>>>> examples are "aud" >>>>>>> >>> (Audience), "exp" (Expiration Time), and "nbf" (Not Before) fro= m >>>>>>> RFC 7519. >>>>>>> >>> E.g. if the token is expired or was intended for someone or >>>>>>> something >>>>>>> >>> else, reject it. >>>>>>> >>> >>>>>>> >>> And there are JWT claims that appropriately don't specify such >>>>>>> >>> processing rules and are solely statements of fact or >>>>>>> circumstance. >>>>>>> >>> Also from RFC 7519, the "sub" (Subject) and "iat" (Issued At) >>>>>>> claims are good examples of such. >>>>>>> >>> There might be application or policy specific rules applied to >>>>>>> the >>>>>>> >>> content of those kinds of claims (e.g. only subjects from a >>>>>>> >>> particular organization are able to access tenant specific data >>>>>>> or, >>>>>>> >>> less realistic but still possible, disallow access for tokens >>>>>>> issued >>>>>>> >>> outside of regular business >>>>>>> >>> hours) but that's all outside the scope of a specification's >>>>>>> >>> definition of the claim. >>>>>>> >>> >>>>>>> >>> The actor claim falls into the latter category. It's a way for >>>>>>> the >>>>>>> >>> issuer of the token to tell the consumer of the token what is >>>>>>> going >>>>>>> >>> on. But any action to take (or not) based on that information i= s >>>>>>> at >>>>>>> >>> the discretion of the token consumer. I honestly don't know it >>>>>>> could >>>>>>> >>> be anything more. And don't think it should be. >>>>>>> >>> >>>>>>> >>> There are two main expected uses of the actor claim (that I'm >>>>>>> aware >>>>>>> >>> of >>>>>>> >>> anyway) that describing here might help. Maybe. One is a human = to >>>>>>> >>> human delegation case like a customer service rep doing >>>>>>> something on >>>>>>> >>> behalf of an end user. The subject would be that user and the >>>>>>> actor >>>>>>> >>> would be the customer service rep. And there wouldn't be any >>>>>>> chaining >>>>>>> >>> or nesting of the actor. The other case is so called service >>>>>>> chaining >>>>>>> >>> where a system might exchange a token it receives for a new tok= en >>>>>>> >>> that it can use to call a downstream service. And that service = in >>>>>>> >>> turn might do another exchange to get a new token suitable to >>>>>>> call >>>>>>> >>> yet another downstream service. And again and so on and turtles >>>>>>> all >>>>>>> >>> the way. I'm not necessarily endorsing that level of granularit= y >>>>>>> in >>>>>>> >>> chaining but it's bound to happen somewhere/sometime. The neste= d >>>>>>> >>> actor claim is able to express that all that has happened with >>>>>>> the >>>>>>> >>> top level or outermost one being the system currently using the >>>>>>> token >>>>>>> >>> and prior systems being nested.. What actually gets done with >>>>>>> that >>>>>>> >>> information is up to the respective systems involved. There >>>>>>> might be >>>>>>> >>> policy about what system is allowed to call what other system >>>>>>> that is >>>>>>> >>> enforced. Or maybe the info is just written to an audit log >>>>>>> >>> somewhere. Or something else. I don't know. But whatever it is >>>>>>> application/deployment/policy dependent and not specifiable by a sp= ec. >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla >>>>>>> wrote: >>>>>>> >>>> >>>>>>> >>>> Hi folks, >>>>>>> >>>> >>>>>>> >>>> I've gone over draft-ietf-oauth-token-exchange-12 and things >>>>>>> seem >>>>>>> >>>> generally OK. I do still have one remaining concern, which is >>>>>>> about >>>>>>> >>>> the actor claim. Specifically, what is the RP supposed to do >>>>>>> when >>>>>>> >>>> they encounter it? This seems kind of underspecified. >>>>>>> >>>> >>>>>>> >>>> In particular: >>>>>>> >>>> >>>>>>> >>>> 1. What facts am I supposed to know here? Merely that everyone >>>>>>> in >>>>>>> >>>> the chain signed off on the next person in the chain acting >>>>>>> as them? >>>>>>> >>>> >>>>>>> >>>> 2. Am I just supposed to pretend that the person presenting th= e >>>>>>> token >>>>>>> >>>> is the identity at the top of the chain? Say I have the >>>>>>> >>>> delegation A -> B -> C, and there is some resource which >>>>>>> >>>> B can access but A and C cannot, should I give access? >>>>>>> >>>> >>>>>>> >>>> I think the first question definitely needs an answer. The >>>>>>> second >>>>>>> >>>> question I guess we could make not answer, but it's pretty har= d >>>>>>> to >>>>>>> >>>> know how to make a system with this left open.. >>>>>>> >>>> >>>>>>> >>>> -Ekr >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> _______________________________________________ >>>>>>> >>>> OAuth mailing list >>>>>>> >>>> OAuth@ietf.org >>>>>>> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> >>> privileged material for the sole use of the intended >>>>>>> recipient(s). >>>>>>> >>> Any review, use, distribution or disclosure by others is strict= ly >>>>>>> >>> prohibited.. If you have received this communication in error, >>>>>>> >>> please notify the sender immediately by e-mail and delete the >>>>>>> message >>>>>>> >>> and any file attachments from your computer. Thank you. >>>>>>> >>> >>>>>>> >>> _______________________________________________ >>>>>>> >>> OAuth mailing list >>>>>>> >>> OAuth@ietf.org >>>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> _______________________________________________ >>>>>>> >>> OAuth mailing list >>>>>>> >>> OAuth@ietf.org >>>>>>> >>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>> >>>>>>> >> >>>>>>> >> >>>>>>> >> CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>>> >> privileged material for the sole use of the intended >>>>>>> recipient(s). Any >>>>>>> >> review, use, distribution or disclosure by others is strictly >>>>>>> >> prohibited.. If you have received this communication in error, >>>>>>> please >>>>>>> >> notify the sender immediately by e-mail and delete the message >>>>>>> and any >>>>>>> >> file attachments from your computer. Thank you. >>>>>>> >> _______________________________________________ >>>>>>> >> OAuth mailing list >>>>>>> >> OAuth@ietf.org >>>>>>> >> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >> >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > Bill Burke >>>>>>> > Red Hat >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > OAuth mailing list >>>>>>> > OAuth@ietf.org >>>>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Bill Burke >>>>>>> Red Hat >>>>>>> >>>>>> >>>>>> >>>>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>>>> privileged material for the sole use of the intended recipient(s). A= ny >>>>>> review, use, distribution or disclosure by others is strictly prohib= ited. >>>>>> If you have received this communication in error, please notify the = sender >>>>>> immediately by e-mail and delete the message and any file attachment= s from >>>>>> your computer. Thank you.* >>>>> >>>>> >>>>> >>>> >>>> *CONFIDENTIALITY NOTICE: This email may contain confidential and >>>> privileged material for the sole use of the intended recipient(s). Any >>>> review, use, distribution or disclosure by others is strictly prohibit= ed. >>>> If you have received this communication in error, please notify the se= nder >>>> immediately by e-mail and delete the message and any file attachments = from >>>> your computer. Thank you.* >>>> >>> >>> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited= . >> If you have received this communication in error, please notify the send= er >> immediately by e-mail and delete the message and any file attachments fr= om >> your computer. Thank you.* >> > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000375c49056dd70451 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Eric, I've added text in the just submitte= d -14 saying that only the two ends of the chain are to be considered in ac= cess control policy decisions.



On Fri, Jun 1, 2018 at 10:0= 2 PM, Eric Rescorla <ekr@rtfm.com> wrote:
OK, well, it seems like it ought to say th= at that generator of the token can expect that the RP will apply an access = control policy that s the union of the capabilities of the two ends of the = chain -- and that while it might be less it won't be more.

-Ekr


On F= ri, Jun 1, 2018 at 3:15 PM, Brian Campbell <bcampbell@pingidentit= y.com> wrote:
I suspect that the vast majority of time C's permissions won&#= 39;t matter at all. But I do think there are legitimate cases where they mi= ght be considered in the policy decision. One general example I can think o= f is a customer service rep or administrator taking override type correctiv= e action on an end-user's account or transaction information (A is the = end-user and C is the customer service rep) that the user on their own woul= dn't have permission to change. =C2=A0

On Fri, Jun 1, 2018 at 3:4= 7 PM, Eric Rescorla <ekr@rtfm.com> wrote:
That would go a long way, I think. Do you = think that C's permissions matter at all? So, say that the resource is = accessible to C but not A?

-Ekr

=



O= n Fri, Jun 1, 2018 at 11:47 AM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:
Hi Eric,

Apologies for my somew= hat slow response. I've honestly been unsure of how else to try and add= ress the comment/question. But will continue trying...=C2=A0

My expectation would be that access control decisions would= be made based on the subject of the token itself or on the current actor. = And maybe a combination of both in some situations (like, for example, the = actor is an administrator and the token allows admin level access to the st= uff the token subject would normally have access to).=C2=A0 However, I don&= #39;t believe that nested prior actors would or should be considered in acc= ess control decisions. The nesting is more just to express what has happene= d for auditing or tracking or the like. To be honest, the nesting was added= in the draft largely because the structure naturally and easily allowed fo= r it and it seemed like it might be useful information to convey in some ca= ses.

So in that A->B->C case (the claim= s of such a token would, I think, look like the JSON below), B is not giving C his=C2=A0authority. B is just noted in the token as having been = involved previously.=C2=A0 While A is identified as the subject of the toke= n and C is the current actor. 

    {
      "aud":"... ,"iss":... , "exp":...,=
 etc. etc. ...
      "sub":"A",
      "act":
      {
        "sub":"C",
        "act":
        {
          "sub":"B"
        }
      }
    }

Would some text explicitly saying that only the t= oken subject (top level sub and claims) and the party identified by the out= ermost "act" claim (the current actor) are to be considered in ac= cess control decisions address your concern?


On Tue, May 29, 2018 at 4:19 PM, Eric Rescorla <ekr@rtfm.com> w= rote:
Hi Brian,

To be clear, I'm not opposing Delegation. My conc= ern here is that we have a chain of signed assertions and I'm trying to= understand how I as a consumer of those assertions am supposed to evaluate= it.

I don't think it's sufficient to just= say that that the access control rules are local policy, because then the = entity generating the signature has no way of knowing how its signature wil= l be used.

To go back to the case I gave in my ini= tial e-mail, say we have a chain A->B->C and a resource that A and C = could ordinarily not access, but B can. If C has this delegation, can C acc= ess the resource? I.e., is B giving C his authority or just passing on A= 9;s authority? It seems pretty important for B to know that before he gives= the token to C.

-Ekr


On Thu, May 17, 2018 at 11:06 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
Delegation has been in the document since its inception and throughout t= he three and a half years as a working group document.

<= /div>
From a process point of view, the document is now in=C2=A0AD Eval= uation. I worked through a number of questions and clarifications with Eric= (said AD), however he raised the particular questions that started this th= read on the WG list. And I responded with an attempt at addressing those qu= estions. That was about a month ago.

Eric, wa= s my explanation helpful in clarify anything for you? Is there some text th= at you'd like to see added? Something else? I'm unsure how to proce= ed but would like to move things forward.


On Thu, May 17, 2018 at 8:03 AM, Bill Burke <bburke@redh= at.com> wrote:
This is an h= onest question: How important is the actor stuff to the
players involved?=C2=A0 Are people going to use it?=C2=A0 IMO, its an edge = case
and I think more important areas, like external token exchange (realm
to realm, domain to domain) are being neglected.=C2=A0 I'm quite unfami= liar
how consensus is reached in this WG or the IETF, so I hope I'm not
sounding rude.=C2=A0 Just trying to provide some constructive feedback.



On Thu, May 17, 2018 at 9:26 AM, Mike Jones <Michael.Jones@microsoft.com> w= rote:
> Moving the actor claim to a separate specification would only make thi= ngs more complicated for developers.=C2=A0 There already plenty of OAuth sp= ecs.=C2=A0 Needlessly adding another one will only make related things hard= er to find.
>
> Just like in the JWT [RFC 7519] spec itself in which use of all the cl= aims is optional, use of the actor claim in this spec.=C2=A0 If you don'= ;t need it, don't use it.=C2=A0 Just because some won't use it is n= o better an argument for moving it to a different spec than the argument th= at JWT should have defined each of its claims in different specs.=C2=A0 Tha= t would have made things harder, not easier.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Mike
>
> -----Original Message-----
> From: OAuth <oauth-bounces@ietf.org> On Behalf Of Bill Burke
> Sent: Thursday, May 17, 2018 2:11 PM
> To: Brian Campbell <bcampbell@pingidentity.com>
> Cc: oauth <oaut= h@ietf.org>
> Subject: Re: [OAUTH-WG] Followup on draft-ietf-oauth-token-exchange-12.txt
>
> My personal opinion is that I'm glad this actor stuff is optional.=
> For one, none of our users have asked for it and really only do simple= exchanges.=C2=A0 Secondly, the rules for who can exchange what for what is= controlled and defined within our AS.=C2=A0 Makes things a lot simpler on = the client.=C2=A0 I kind of wish the actor stuff would be defined in a sepa= rate specification.=C2=A0 I don't see us implementing it unless users s= tart asking us to.
>
> On Wed, May 16, 2018 at 6:11 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
>> Well, it's already called the "actor claim" so the c= laimed part is
>> kind of implied. And "claimed actor claim" is a rather a= wkward.
>> Really, all JWT claims are "claimed something" but they = don't include
>> the "claimed" bit in the name. RFC 7519, for example, de= fines the
>> subject claim but not the claimed subject claim.
>>
>> On Fri, Apr 20, 2018 at 11:38 AM, Denis <denis.ietf@free.fr> wrote:
>>>
>>> Brian,
>>>
>>> Eric said: "what is the RP supposed to do when they encou= nter it?
>>> This seems kind of under specified".
>>>
>>> After reading your explanations below, it looks like the RP ca= n do
>>> anything he wants with the "actor".
>>> It is a "claimed actor" and, if we keep the concept,= it should be
>>> called as such. Such a claim cannot be verified.
>>> A RP could copy and paste that claim in an audit log. No stand= ard
>>> action related to the content of such a claim can be specified= in the
>>> spec. If the content of a "claimed actor" is used by= the RP, it
>>> should be only used as an hint and thus be subject to other >>> verifications which are not specified in this specification. >>>
>>> Denis
>>>
>>> Eric, I realize you weren't particularly impressed by my p= rior
>>> statements about the actor claim but, for lack of knowing what= else
>>> to say, I'm going to kind of repeat what I said about it o= ver in the
>>> Phabricator tool and add a little color.
>>>
>>> The actor claim is intended as a way to express that delegatio= n has
>>> happened and identify the entities involved. Access control or= other
>>> decisions based on it are at the discretion of the consumer of= the
>>> token based on whatever policy might be in place.
>>>
>>> There are JWT claims that have concise processing rules with r= espect
>>> to whether or not the JWT can be accepted as valid. Some examp= les are "aud"
>>> (Audience), "exp" (Expiration Time), and "nbf&q= uot; (Not Before) from RFC 7519.
>>> E.g. if the token is expired or was intended for someone or so= mething
>>> else, reject it.
>>>
>>> And there are JWT claims that appropriately don't specify = such
>>> processing rules and are solely statements of fact or circumst= ance.
>>> Also from RFC 7519, the "sub" (Subject) and "ia= t" (Issued At) claims are good examples of such.
>>> There might be application or policy specific rules applied to= the
>>> content of those kinds of claims (e.g. only subjects from a >>> particular organization are able to access tenant specific dat= a or,
>>> less realistic but still possible, disallow access for tokens = issued
>>> outside of regular business
>>> hours) but that's all outside the scope of a specification= 's
>>> definition of the claim.
>>>
>>> The actor claim falls into the latter category. It's a way= for the
>>> issuer of the token to tell the consumer of the token what is = going
>>> on. But any action to take (or not) based on that information = is at
>>> the discretion of the token consumer. I honestly don't kno= w it could
>>> be anything more. And don't think it should be.
>>>
>>> There are two main expected uses of the actor claim (that I= 9;m aware
>>> of
>>> anyway) that describing here might help. Maybe. One is a human= to
>>> human delegation case like a customer service rep doing someth= ing on
>>> behalf of an end user. The subject would be that user and the = actor
>>> would be the customer service rep. And there wouldn't be a= ny chaining
>>> or nesting of the actor. The other case is so called service c= haining
>>> where a system might exchange a token it receives for a new to= ken
>>> that it can use to call a downstream service. And that service= in
>>> turn might do another exchange to get a new token suitable to = call
>>> yet another downstream service. And again and so on and turtle= s all
>>> the way. I'm not necessarily endorsing that level of granu= larity in
>>> chaining but it's bound to happen somewhere/sometime. The = nested
>>> actor claim is able to express that all that has happened with= the
>>> top level or outermost one being the system currently using th= e token
>>> and prior systems being nested.. What actually gets done with = that
>>> information is up to the respective systems involved. There mi= ght be
>>> policy about what system is allowed to call what other system = that is
>>> enforced. Or maybe the info is just written to an audit log >>> somewhere. Or something else. I don't know. But whatever i= t is application/deployment/policy dependent and not specifiable by a spec.=
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 6:38 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>
>>>> Hi folks,
>>>>
>>>> I've gone over draft-ietf-oauth-token-exchange-12= and things seem
>>>> generally OK. I do still have one remaining concern, which= is about
>>>> the actor claim. Specifically, what is the RP supposed to = do when
>>>> they encounter it? This seems kind of underspecified.
>>>>
>>>> In particular:
>>>>
>>>> 1. What facts am I supposed to know here? Merely that ever= yone in
>>>>=C2=A0 =C2=A0 the chain signed off on the next person in th= e chain acting as them?
>>>>
>>>> 2. Am I just supposed to pretend that the person presentin= g the token
>>>>=C2=A0 =C2=A0 is the identity at the top of the chain? Say = I have the
>>>>=C2=A0 =C2=A0 delegation A -> B -> C, and there is so= me resource which
>>>>=C2=A0 =C2=A0 B can access but A and C cannot, should I giv= e access?
>>>>
>>>> I think the first question definitely needs an answer. The= second
>>>> question I guess we could make not answer, but it's pr= etty hard to
>>>> know how to make a system with this left open..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@= ietf.org
>>>> https://www.ietf.org/mailman/listin= fo/oauth
>>>>
>>>
>>>
>>> CONFIDENTIALITY NOTICE: This email may contain confidential an= d
>>> privileged material for the sole use of the intended recipient= (s).
>>> Any review, use, distribution or disclosure by others is stric= tly
>>> prohibited..=C2=A0 If you have received this communication in = error,
>>> please notify the sender immediately by e-mail and delete the = message
>>> and any file attachments from your computer. Thank you.
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf= .org
>>> https://www.ietf.org/mailman/listinfo/o= auth
>>>
>>
>>
>> CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s).= Any
>> review, use, distribution or disclosure by others is strictly
>> prohibited..=C2=A0 If you have received this communication in erro= r, please
>> notify the sender immediately by e-mail and delete the message and= any
>> file attachments from your computer. Thank you.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org=
>> https://www.ietf.org/mailman/listinfo/oauth=
>>
>
>
>
> --
> Bill Burke
> Red Hat
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth=



--
Bill Burke
Red Hat


CONFIDENTIALITY NOTICE: This email may contai= n confidential and privileged material for the sole use of the intended rec= ipient(s). Any review, use, distribution or disclosure by others is strictl= y prohibited.=C2=A0 If you have received this communication in error, pleas= e notify the sender immediately by e-mail and delete the message and any fi= le attachments from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you.



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000375c49056dd70451-- From nobody Tue Jun 5 21:08:31 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0053130E21 for ; Tue, 5 Jun 2018 21:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HTZWbkKKn-s for ; Tue, 5 Jun 2018 21:08:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91F33130DDA for ; Tue, 5 Jun 2018 21:08:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E090CB81D9E; Tue, 5 Jun 2018 21:07:56 -0700 (PDT) To: dick.hardt@gmail.com, kaduk@mit.edu, ekr@rtfm.com, Hannes.Tschofenig@gmx.net, rifaat.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: james.h.manger@team.telstra.com, oauth@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180606040756.E090CB81D9E@rfc-editor.org> Date: Tue, 5 Jun 2018 21:07:56 -0700 (PDT) Archived-At: Subject: [OAUTH-WG] [Editorial Errata Reported] RFC6749 (5379) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 04:08:30 -0000 The following errata report has been submitted for RFC6749, "The OAuth 2.0 Authorization Framework". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5379 -------------------------------------- Type: Editorial Reported by: James Manger Section: 5.1, 4.2.2 Original Text ------------- expires_in RECOMMENDED. The lifetime in seconds of the access token. For example, the value "3600" denotes ... Corrected Text -------------- expires_in RECOMMENDED. The lifetime in seconds of the access token. For example, the value 3600 denotes ... Notes ----- The "expires_in" member in JSON must be a numeric value, not a string. Unfortunately quite a few implementations have got this wrong. A likely reason is the quoted value "3600" in the RFC where "expires_in" is defined. The quotes in the text version of the RFC are only an artefact of the marked-up as a protocol value in the RFC production chain. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6749 (draft-ietf-oauth-v2-31) -------------------------------------- Title : The OAuth 2.0 Authorization Framework Publication Date : October 2012 Author(s) : D. Hardt, Ed. Category : PROPOSED STANDARD Source : Web Authorization Protocol Area : Security Stream : IETF Verifying Party : IESG From nobody Sun Jun 10 09:33:56 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C76C130E81 for ; Sun, 10 Jun 2018 09:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsqKQubD8Vrw for ; Sun, 10 Jun 2018 09:33:51 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AD0130E7C for ; Sun, 10 Jun 2018 09:33:51 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fS3Hm-0000NG-UO; Sun, 10 Jun 2018 18:33:46 +0200 From: Torsten Lodderstedt Message-Id: <8A4E5C43-8A7D-4219-B92C-993BB4F042AB@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_8D4994E1-A1DA-4D4C-AD83-A18EE5AA54BA"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sun, 10 Jun 2018 18:33:44 +0200 In-Reply-To: Cc: oauth@ietf.org To: Johan Peeters References: X-Mailer: Apple Mail (2.3445.8.2) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 16:33:54 -0000 --Apple-Mail=_8D4994E1-A1DA-4D4C-AD83-A18EE5AA54BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Johan, thanks for your proposal. I=E2=80=99m not sure whether it should go to = 3.7.1.4. The reason audience restriction turns up as a subsection of 3.7 = is our document is organized by attacks instead of security controls. I = could image to add a section on audience/action restriction as sub = section of 2. What is the mean reason for restricting access tokens to certain = actions? Is it about least privileges? Is it to limit the impact of a = token leakage/replay? ... best regards, Torsten. =20 > Am 07.04.2018 um 19:11 schrieb Johan Peeters : >=20 > Thanks for doing this great work, Torsten. As discussed in a private > email conversation, I think an access token should not only be > explicit about which resource server is the intended consumer > (audience), but also which actions are permitted on the targeted > resources: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D3.7.1.4. Action Restricted Access = Tokens=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > An action restriction restricts the action a > particular access token can be used for. The authorization server > associates the access token with a certain action and every > resource server is obliged to verify for every request, whether the > access token sent with that request was meant to be used for that > particular action. If not, the resource server must refuse > to serve the respective request. Action > restrictions limit the impact of a token leakage and prevent a > malicious client to use the token for unintended actions. >=20 > The action attribute in can be expressed as the HTTP verb used to > make the request. >=20 > The client needs to tell the authorization server, for which actions = it > will use the access token it is requesting. It should encode > the information in the scope value. >=20 > Action restrictions are essential both to enforce scope > restrictions as established through user dialog and policy decisions > by the authorization server. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >=20 > Yo > --=20 > Johan Peeters > https://www.johanpeeters.com --Apple-Mail=_8D4994E1-A1DA-4D4C-AD83-A18EE5AA54BA Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNjEwMTYzMzQ1WjAjBgkqhkiG9w0BCQQxFgQUqt2pg3MfqcbL LW90+5j0o5tHHr0wgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBAFSGY7NCSvrA903wOcLZLkiFynLmdtuOthOMCMIMvzliAjYz2XLW G/+f7mlmCw9dUdL0ZbwS+SzMLr2YRapcnkOS8X6Qa0baYVq+/om4a6OCwKtA7V+g0k2WBJnUauVr n7OrJj41axfpvKntjiEwYIoo1TWY0wmH+VAUXvOA4BswomtQ1mXRSxMQ/hb85uvQRtxhwLtyMvFH bLuz3j8ZVn71UGg6ylICD3wQeJS/Ov8Rc9o5R0Npa9hTfdeHD87GW3df8HXKob2b5bg/9pbah9oB mt4bDOWZZjdQciNzb6W41/8RXI0MywXBD57SNTQR3EZJ5LiZi5dNxnnqBYZDHsoAAAAAAAA= --Apple-Mail=_8D4994E1-A1DA-4D4C-AD83-A18EE5AA54BA-- From nobody Sun Jun 10 10:23:40 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45640130E9F for ; Sun, 10 Jun 2018 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAF-g31sQ5mI for ; Sun, 10 Jun 2018 10:23:35 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3EBA130E9A for ; Sun, 10 Jun 2018 10:23:35 -0700 (PDT) Received: from [84.158.233.58] (helo=Torstens-MacBook-Pro.local) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fS43v-0000pg-IF; Sun, 10 Jun 2018 19:23:31 +0200 To: "McDorman, Doug" References: Cc: oauth@ietf.org From: Torsten Lodderstedt Message-ID: <6b27c559-2518-38ce-46e4-88a2963421e4@lodderstedt.net> Date: Sun, 10 Jun 2018 19:23:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] draft-ietf-oauth-security-topics X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 17:23:39 -0000 Hi Doug, Am 22.05.18 um 07:48 schrieb McDorman, Doug: > I attached 2 diffs which should help highlight the changes. thanks, that helped a lot! > > To summarize: > Added 1.1. Notational Conventions > > Section 3.1.1. Attacks on Authorization Code Grant > FROM > control, say "https://www.evil.com". > TO > control, say "https://www.evil.example.com". > > Section 3.1.2. Attacks on Implicit Grant > FROM > attacker's control, say "https://www.evil.com". > TO > attacker's control, say "https://www.evil.test.com". > > FROM > "redirect_to=https://client.evil.com" into the redirect URI and > TO > "redirect_to=https://client.evil.test.com" into the redirect > > FROM > %253Dhttps%253A%252F%252Fclient.evil.com%252Fcb HTTP/1.1 > TO > %253Dhttps%253A%252F%252Fclient.evil.test.com%252Fcb HTTP/1.1 > > FROM > redirect_to%3Dhttps%3A%2F%2Fclient.evil.com%2Fcb > TO > redirect_to%3Dhttps%3A%2F%2Fclient.evil.test.com%2Fcb# > > FROM > the URL "https://evil.example.com/cb". > TO > the URL "https://client.evil.test.com/cb". > > FROM > Location: https://client.evil.com/cb > TO > Location: https://client.evil.test.com/cb > > FROM > https://client.evil.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&... > TO > https://client.evil.test.com/cb# > access_token=2YotnFZFEjr1zCsicMWpAA&... > > FROM > (4) The attacker's page at client.evil.com can access the fragment > and obtain the access token. > TO > (4) The attacker's page at client.evil.test.com can access the > fragment and obtain the access token. I took the liberty to use the "example" TLD in all examples as recommended in RFC 2606. > > Section 3.3.2. Access token in browser history > FROM > Actually [RFC6750]discourages this practice and asks to transfer > TO > Actually [RFC6750] discourages this practice and asks to transfer done > Section 3.7.1.1. Metadata (line break added to avoid line too long) > FROM > "access_token_resource_server":"https://hostedresource.example.com/path1", > TO > "access_token_resource_server": > "https://hostedresource.example.com/path1", done > > Section 3.8.2. Clients as Open Redirector (uppercase the NOT) > FROM > Client MUST not expose URLs which could be utilized as open > TO > Client MUST NOT expose URLs which could be utilized as open done > > Added section 3.10. Cryptographic Agility > NEW > Cryptographic agility is the ability to change algorithms if the need > arises. For example RS256 does not have the same formal validation > that PS256 does, so vulnerabilities might be found in RS256. > Similarly quantum computing may make elliptic curve ES256 or EdDSA > [RFC8037] a better option than RS256. So the protocol must be able to > adapt to other cryptographic algorithms. Over time cryptographic > algorithms are expected to become obsolete (DES, RC4, MD5, SHA1) often > with long time frames but new research and vulnerabilities can sometimes > shorten the time dramatically. > > The implementations SHOULD implement and test additional cryptographic > algorithms to support cryptographic agility. Typically implementations > indicate that they MUST implement RS256 (RSASSA-PKCS-v1_5 using SHA-256 > hash algorithm) but PS256 (RSASSA-PSS using SHA-256 hash algorithm and > MGF1 mask generation) has a better mathematical foundation of security > and [RFC8017] recommends a gradual transition to EMSA-PSS in PS256 is > recommended as a precaution against future developments. I agree crypto agility is a very important topic. I'm not quite sure whether this topic should be discussed in this document for two reasons: - this draft is about OAuth-specific security threats, I don't see a direct relationship - the draft nowhere talk about any crypto algorithms What does the WG think? > > Section 7.1. Normative References > NEW > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, > . done > > [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, > "PKCS #1: RSA Cryptography Specifications Version 2.2", > RFC 8017, DOI 10.17487/RFC8017, November 2016, > . > > [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) > and Signatures in JSON Object Signing and Encryption (JOSE)", > RFC 8037, DOI 10.17487/RFC8037, January 2017, > . related to your text proposal - not adopted for the moment > > Section 7.2. Informative References > FROM > draft-ietf-oauth-jwsreq-15 (work in progress), July 2017. > TO > draft-ietf-oauth-jwsreq-16 (work in progress), April 2018. thanks for pointing this out. My local environment somehow fetched outdated data. It's been corrected now. > > FROM > mtls-07 (work in progress), January 2018. > TO > mtls-08 (work in progress), May 2018. > > FROM > tokbind-https-12 (work in progress), January 2018. > TO > tokbind-https-14 (work in progress), May 2018. > > Does that help? yes! best regards, Torsten. > > Thanks, > > Doug > > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Sunday, May 20, 2018 4:30 AM > To: McDorman, Doug > Cc: draft-ietf-oauth-security-topics@ietf.org > Subject: Re: draft-ietf-oauth-security-topics > > Hi Doug, > > thanks for your feedback. I changed the names to comply to RFC 2606. > > Can you please add all proposals to the body of your posting (including section/page references)? Otherwise, it’s nearly impossible to discuss proposals on the list. > > best regards, > Torsten. > >> Am 08.05.2018 um 08:48 schrieb McDorman, Doug : >> >> Hi working group, I made some edits to the current draft of this document. Edited version attached. >> >> The changes probably are not in the exact desired format, I have not edited an RFC before and I am not familiar with the tools and process. >> >> Summary: >> • I added a section 3.10. Cryptographic Agility >> • The domain evil.com is used but that is a real URL so I changed references to be evil.test.com, According to https://tools.ietf.org/html/rfc2606 test.com should be safe to use in documentation. >> • There was one wrong URL of https://evil.example.com/cb, which should have been https://client.evil.com/cbalthough I changed to https://client.evil.test.com/cb to be consistent with the other changes from evil.com to test.com >> • Updated some of the references to newer versions >> • A few other minor spacing issues >> >> Let me know if I can clarify anything or provide additional assistance. >> >> Thanks, >> >> Doug >> >> Doug McDorman >> Principal Architect, Security >> >> >> douglas.mcdorman@t-mobile.com >> www.t-mobile.com >> >> From nobody Mon Jun 11 09:21:00 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7385131068; Mon, 11 Jun 2018 09:20:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-oauth-device-flow.all@ietf.org, ietf@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152873404689.2672.12557627140070509936@ietfa.amsl.com> Date: Mon, 11 Jun 2018 09:20:46 -0700 Archived-At: Subject: [OAUTH-WG] Genart last call review of draft-ietf-oauth-device-flow-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2018 16:20:53 -0000 Reviewer: Robert Sparks Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-oauth-device-flow-10 Reviewer: Robert Sparks Review Date: 2018-06-11 IETF LC End Date: 2018-06-12 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as a Proposed Standard RFC, but with nits to consider Nits/editorial comments: In 3.5 "the client MUST use a reasonable default polling interval" is not testable. Who determines "reasonable"? At the very least, you should add some text about how to determine what "reasonable" is for a given device, and add some text that says don't poll faster than earlier responses limited you to. For example, if the response at step B in the introductory diagram had an explicit interval of 15, but a slow-down response to an E message didn't have an explicit interval, you don't want them to default to, say 5 seconds (because that's what the example in section 3.2 said, so it must be reasonable). In 3.3, you say the device_code MUST NOT be displayed or communicated. Is there a security property that's lost if there is? Or is this just saying "Don't waste space or the user's time"? The last paragraph of section 6.1 feels like a recipe for false positives, and for bug-entrenched code. Please reconsider it. You need line-folding in the example in section 3.2 From nobody Tue Jun 12 04:25:43 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0197130E2C; Tue, 12 Jun 2018 04:25:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Qin Wu To: Cc: draft-ietf-oauth-device-flow.all@ietf.org, ietf@ietf.org, oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152880273680.9205.1844934984494262436@ietfa.amsl.com> Date: Tue, 12 Jun 2018 04:25:36 -0700 Archived-At: Subject: [OAUTH-WG] Opsdir last call review of draft-ietf-oauth-device-flow-10 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 11:25:37 -0000 Reviewer: Qin Wu Review result: Ready I have reviewed this document as part of the Operational directorate¡¯s ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed: draft-ietf-oauth-device-flow Summary: This document defines device flow among browserless and input constrained devices, end user at browser and authorization server. This device flow allows OAuth clients to request user authorization from devices that have an Internet connection, but don't have an easy input method. This document is well written, especially security consideration section. I think it is ready for publication. Major issue: None Minor issue: Editorial Section 3.3.1 The short name for NFV needs to be expanded, maybe add reference. QR code also needs to be expanded. Section 3.5: Who is token endpoint, how token endpoint is related to authorization server? Would it be great to add some clarification text about this. Section 4: Would it be great to clarify the relationship between device_authorization_endpoint defined in this document and authorization_endpoint defined in draft-ietf-oauth-discovery-10 and explain why authorization_endpoint is not sufficient,e.g., draft-ietf-oauth-discovery-10 has already defined authorization server metadata value authorization_endpoint, however ¡­¡­ From nobody Tue Jun 12 12:28:55 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B81130E91 for ; Tue, 12 Jun 2018 12:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw2GQvo1OKT7 for ; Tue, 12 Jun 2018 12:28:49 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92606130E8E for ; Tue, 12 Jun 2018 12:28:49 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id y8-v6so43476pfm.10 for ; Tue, 12 Jun 2018 12:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=OYHXhHw392h2q9Ati+m6rP01+vm2hT2dwjupUQYDCWk=; b=sKh1IJf7jzT9ZMtI/9QChI9s6XDCgMA7pPtrRTAuiRkmyXJUMat5gasp1OL6n+x7tb INJmneRftfnP1bZcgqW9XjZa6PYyET2mvabu1HjQ6uNNONgwLbRguMqadF5WSqoilHEl 8BKmpjFZR75j6SmUXHW0mtMfRqL1FR3YBoBhqOSeHXlVvUyfJEjUqfpsH4XsmuW5RA06 KE7rSuoZyH6JL06M1hqvRaEHEdfWllXtv/aCq8L1VPFdzADs76YnUVXtdLnzxwHLa/du J2mRAKq9hvKyzKLZjJxbTJHy7vMYcscFBvhX70GIHifnv51Rh/z7ndU13Do0JPVorg9V 5N2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=OYHXhHw392h2q9Ati+m6rP01+vm2hT2dwjupUQYDCWk=; b=ihJ6I8w8/7atjbuR6zUxn0oOyPzO/MnoKgpz/9NcwwRkm6nDQJJmtOucG9gQ4zWUU4 1qHWrYxYu8sRtbcNh6CuvqN2wGdkgE78242jReSLrLJhGGF0aFhwfjaGEaQEqqt6tPwf VO43E4u5uNyMrQBpan78eyEZZ9b2xW9s9/ummpqVDIDqoSwmzx5Fnc1UJ/TfslHvwCzw nLfBKJSNh2148bOIgpu/6WeZen5USYsTqNg+SwmwMxxJ2MQYRf6jUIGAyfpjRvKbmqHE Uy6bKL8NkG3emwDhGyDwWhuKwG4tZ5NpwCwI7cvYvfKlSpxLdI7NJIcj5Png4OzHFnq9 3IQw== X-Gm-Message-State: APt69E2XWYrpciPKKuI14kx9pkqdM+TD2KZV6o3v7vkk3IQYyJtHB6Es QgaaMA2s4nh5ORTKjTQ/jietsUIAGEfjkInajnWG8w== X-Google-Smtp-Source: ADUXVKJs9MoflXtDWE0hP+HgNBr+tAqCQ+IwCoTVB+T1KxrjFUXby6y2ZHx/Ov8AeVCsKVaTSMy5NnSabL6DuN0iAF8= X-Received: by 2002:a62:bd03:: with SMTP id a3-v6mr1758463pff.138.1528831728744; Tue, 12 Jun 2018 12:28:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:8992:0:0:0:0 with HTTP; Tue, 12 Jun 2018 12:28:28 -0700 (PDT) From: Dick Hardt Date: Tue, 12 Jun 2018 12:28:28 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="0000000000001d0161056e76e0ca" Archived-At: Subject: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 19:28:53 -0000 --0000000000001d0161056e76e0ca Content-Type: text/plain; charset="UTF-8" Hey OAuth WG I have worked with Nat and Brian to merge our concepts and those are captured in the updated draft. https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ We are hopeful the WG will adopt this draft as a WG document. Any comments and feedback are welcome! /Dick --0000000000001d0161056e76e0ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey OAuth WG

I have worked with Nat and= Brian to merge our concepts and those are captured in the updated draft.


We are hopeful the WG will a= dopt this draft as a WG document.

Any comments and= feedback are welcome!

/Dick
--0000000000001d0161056e76e0ca-- From nobody Tue Jun 12 15:57:23 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD9A130EA4 for ; Tue, 12 Jun 2018 15:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrvx2K1riDkP for ; Tue, 12 Jun 2018 15:57:15 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C578128CF3 for ; Tue, 12 Jun 2018 15:57:15 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id h10-v6so679389wrq.8 for ; Tue, 12 Jun 2018 15:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mxLKSs+PxQqhO1MZlZbX/ClThljDPcV7uDdI5aePzM8=; b=BL/dE2PX8fMEyoa3b4AZ9sKHKowiBTUFCoPWpiDJcwrLpzwcoLWiS/5t1tWUTmWGgg VPSWIkyhE5twoWY65asIflV1CyCEo3EkTdYKG2L/dQNkWxwqDFyNp0Y5y0vWx0I7Paq1 ntOD4xBeg46xn/HDCvoPVemgh7rPjJq6+uDd1+HSRvQmAb/yABi2yfbCyV4iNxB/5HyQ /k2VEK7MHIUUTWOMvyAwXxUl7fib9SBAIajpFpFSb4wRMWoBCF5wKVlcLAYRQ0Igs8ym pW54owC5bzPo/DwnpUX1T9Uu9g4CSTDBmSpxTWJNDGO3iyWgKeqMBalKGIHWU+jJe0EC Eu7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mxLKSs+PxQqhO1MZlZbX/ClThljDPcV7uDdI5aePzM8=; b=pGtD15naBXkEP8oDM0Fry/ykbLUCuA/CXwdWrhiTq3+7kb/h/VP+vDkWSUyNOLWg+9 wPbiCoPJ0jIlwia17ym1tIS4aYgNTEUaSIgHsFyus2zvFQ2vMxsMvKdktbyuOtnQ3kwm DShzCBFpN2QDyRP/f7m0xjTR0xSNJLLqE3mAmFDw7kyaxA7ElGNXrSxVwe+k2Glhb80G ++oBtbzuR8+TwpuwRCKQxXRzI6wFYMefz0gEs66mZBfw2XttdHrSm0gmaqo+NKIqgTj9 +LwExwTf1aSaaQLgfnwImqXfxnz6Rn4okGMOQicReRYxGysbbBW4oQ1JUPPSbdBqLFMh 5ZDA== X-Gm-Message-State: APt69E0C4+gtssJcyZxnT0QXP2N6acvaJn4m5SAEIu0OFY4QMRAXpw7c D0ZXZjm0s0JRN1lrTwvP6JEjFOekvioVvAGQ9g7IzOY2 X-Google-Smtp-Source: ADUXVKJJGXOz5fxQiHtoxBqBWF6MYDzakhor1Z7CBXXWgR6+GHfDHU9rZ/8GahekahSN4zNOny2tfqo2nWkyhsMSwkQ= X-Received: by 2002:adf:9c12:: with SMTP id f18-v6mr2192617wrc.40.1528844233333; Tue, 12 Jun 2018 15:57:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:8718:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 15:57:12 -0700 (PDT) From: Jared Hanson Date: Tue, 12 Jun 2018 15:57:12 -0700 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary="00000000000071e150056e79c93e" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2018 22:57:20 -0000 --00000000000071e150056e79c93e Content-Type: text/plain; charset="UTF-8" Thanks Dick, Nat and Brian for your work on this ID. I have a couple improvements I would like to discuss: I would suggest replacing the "oauth_server_metadata_uri" link relation with "oauth2-isser", and dropping the ".well-known" suffix from the value. For example: Link: ; rel="oauth2-issuer" The rationale for this are two-fold: 1. It allows the discovery mechanism to be more flexible, or application specific. For instance, OpenID Connect discovery could be used and take advantage of already deployed ".well-known/openid-configuration" documents. Applications could also take advantage of other discovery mechanisms, either now (such as LRDD and WebFinger) or in the future. 2. It aligns the syntax (underscores vs dash) with https://tools.ietf.org/html/draft-wmills-oauth-lrdd-07 (which I also think should be revived as link relations). Also, existing conventions with registered link relations seem to prefer dashes rather than underscores. I would suggest replacing the "resource_uri" link relation with "canonical" (RFC6596), which seems to fit the purpose and avoids registering a potentially duplicative link relation value. There is language in the draft requiring the client to check "host" values between TLS certificates and link relation values. This seems unnecessary to me, for a couple reasons. 1. It unnecessarily constrains the logical organization of resources, which may be hosted on multiple domains and yet have a canonical URL by which other systems, including the authorization server, identify them. Allowing the canonical URL to differ from the host of the initial request will avoid these limitations. 2. The resource server must ultimately do audience checking in order to validate the access token. I believe this accounts for all the security considerations, and alleviates the burden from the client to do any checking itself. Jared Hanson Auth0 Inc. -- Jared Hanson --00000000000071e150056e79c93e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Dick, Nat and Brian for your work on this ID.= =C2=A0 I have a couple improvements I would like to discuss:

=
I would suggest replacing the "oauth_server_metadata_uri&qu= ot; link relation with "oauth2-isser", and dropping the ".we= ll-known" suffix from the value.=C2=A0 For example:




(which I also think should be revived a= s link relations).=C2=A0 Also, existing conventions with registered link re= lations seem to prefer dashes rather than underscores.

=
I would suggest replacing the "resource_uri" link relation w= ith "canonical" (RFC6596), which seems to fit the purpose and avo= ids registering a potentially duplicative link relation value.
= =C2=A0 =C2=A0
There is language in the draft requiring the client= to check "host" values between TLS certificates and link relatio= n values.=C2=A0 This seems unnecessary to me, for a couple reasons.

1. It unnecessarily constrains the logical organization o= f resources, which may be hosted on multiple domains and yet have a canonic= al URL by which other systems, including the authorization server, identify= them.=C2=A0 Allowing the canonical URL to differ from the host of the init= ial request will avoid these limitations.

2. The r= esource server must ultimately do audience checking in order to validate th= e access token.=C2=A0 I believe this accounts for all the security consider= ations, and alleviates the burden from the client to do any checking itself= .

Jared Hanson
Auth0 Inc.

=
--
Jared Hanson <http://jaredhanson.net/>
--00000000000071e150056e79c93e-- From nobody Tue Jun 12 22:27:42 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FD0130DDC for ; Tue, 12 Jun 2018 22:27:39 -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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYa-o5K82agA for ; Tue, 12 Jun 2018 22:27:35 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22FA126F72 for ; Tue, 12 Jun 2018 22:27:34 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id i83-v6so1896232lfh.5 for ; Tue, 12 Jun 2018 22:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KMj5VB6PH07uqjSOi7GzE5fVrjX5FzwFKgSaENpJWfM=; b=G2dSzUOhLv7RHOyepsyIgNp3mgx+6zDt8NqaTw/qtk8pIVXX82SyZkfD/QRYyp4ZCY Gl8Bof0PpNYg6DHIkPWgbbuFbChI/lLLwiIabMg2Bh5ercLqO66erBnG8RCEpuomTvY/ Tq/yjnwm4ez8oP65HU7vAg/xo+QRyVXYAazyo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KMj5VB6PH07uqjSOi7GzE5fVrjX5FzwFKgSaENpJWfM=; b=inEZ+7EkviumR4xfEcQe9Kq6IU/kSBmfpi6xTP6KSb5JvB8SSNUG2sdVvzp204d/7P 8YpxY3Amdwb6YtSNpqmsIg+nyDwYCQd/KJ3WOCIZRmSDxU2NQdrrmIBut8EygA5hYL4n 8coe36KoFSuhafo6KtaMlA6C7U7aOa30qsZhGxm3PTr7H6ShtxwczCRXp1CoAQj/sALr NX8CMfl1B2JllL+6aUxBO+1fUyW7JhWUTCd9VO9i21Hw36CEbEw+tk+2yFIquo/sZ8vm r/Pxf6vh7yaVk6Bhbo1tVGw6Uc5g2yT72O3qbmwbtbJRgcaVgp+EhHBKVmrOp1QiTUfo Apxg== X-Gm-Message-State: APt69E0QBJLxKBrPTjqdAmp1NmeOcYuqFO/MLb6Y1IJdc3YkGihnD9KW nI3bAiwulhiHuTbk7wBV1w4c+CVJffDLnUVlS4iH4w== X-Google-Smtp-Source: ADUXVKKPCE7IYEm0wivZER58b1vAKa5netjom3zMfv/DsDxp17eKGa0ehBhhwSjkoFBig+Xu0EKfWqtWhhl/yGMzZuA= X-Received: by 2002:a19:9f95:: with SMTP id i143-v6mr1981286lfe.125.1528867653017; Tue, 12 Jun 2018 22:27:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:860a:0:0:0:0:0 with HTTP; Tue, 12 Jun 2018 22:27:12 -0700 (PDT) In-Reply-To: <3d432797-4645-7215-d855-3f33cfd2efb3@aol.com> References: <59B07252-0FEA-433F-9DD7-F3C5A5B8CF66@stfc.ac.uk> <3d432797-4645-7215-d855-3f33cfd2efb3@aol.com> From: Dave Tonge Date: Wed, 13 Jun 2018 07:27:12 +0200 Message-ID: To: George Fletcher Cc: Matt Pryor - UKRI STFC , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005dfd7a056e7f3d4c" Archived-At: Subject: Re: [OAUTH-WG] Dynamic Client Registration in trusted federation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 05:27:40 -0000 --0000000000005dfd7a056e7f3d4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Matt To add to George's point I think software statements solve your issue. For an example of how they are being used by UK OpenBanking please look here: https://bitbucket.org/openid/obuk/src/4630771db004da59992fb201641f5c4ff2c88= 1f1/uk-openbanking-registration-profile.md?at=3Dmaster&fileviewer=3Dfile-vi= ew-default Dave On 1 June 2018 at 17:21, George Fletcher wrote: > Hi Matt, > > I think your use case is fully within the use cases enabled by > software-statements. > > A per client software-statement allows you to tighten the security model > (if desired). For example binding the software-statement to the client > presenting it in such a way as to have a cryptographic trust chain. > Unfortunately, the specifications are not clear about the best way to do > this. The Client Registration Request does allow for "extension parameter= s" > so that may be a way to add what's necessary. > > Thanks, > George > > On 6/1/18 10:33 AM, Matt Pryor - UKRI STFC wrote: > > Hi George, > > That did occur to me. It seemed like a bit of an abuse of the software-st= atement system, but maybe it is partially intended for this. > > It still needs us to securely distribute the software statement as well. = Would you envisage a single software-statement for all installations, with = each installation specifying their own client-specific metadata, or would y= ou issue a software-statement per installation. The second sounds like it w= ould allow us to exert more control. > > Thanks for your help! > Matt > > =EF=BB=BFOn 01/06/2018, 15:28, "George Fletcher" wrote: > > Given that you have a federation, could not the federation issue the > signed software-statement to each of the relying parties (existing or > old) and the AS will trust the dynamic client registration if and onl= y > if the signed software-statement is signed by the federation. This fi= ts > more closely with the trust framework model. > > Thanks, > George > > On 6/1/18 9:57 AM, Matt Pryor - UKRI STFC wrote: > > Hi, > > > > I am working on a use case of OAuth 2.0 in a federation and am afte= r some advice about bootstrapping trust. > > > > Each site in the federation has an OAuth 2.0 authorization server a= nd an OAuth 2.0 relying party. The relying party at each site needs to be r= egistered with all the authorization servers in the federation. We want to = automate as much of this process as possible, but restrict client registrat= ion to trusted members of the federation. We also want to make onboarding a= new federation member as easy as possible. > > > > This seems an ideal use case for the Dynamic Client Registration Pr= otocol (RFC 7591). The RFC permits the client registration endpoint to requ= ire a pre-existing token in order to register a new client which gives us o= ur security (only trusted federation members can register a client). > > > > The challenge seems to be in bootstrapping the initial trust. It se= ems cumbersome to require that a new federation member must manually obtain= a token from each authorization server before registering - they may as we= ll manually register their client. I'd be interested to know if anyone has = any ideas for a solution other than securely distributing a shared secret t= o new federation members. > > > > One possible option is to piggy-back on the legacy authn/z we alrea= dy have - users can obtain an X509 certificate from their home idp, which i= s then trusted by all the other sites. We can then obtain SAML assertions a= bout their permissions based on that certificate. We could use this mechani= sm to maintain a list of trusted admins, requiring authentication with an X= 509 certificate with the correct SAML assertion for the client registration= endpoint. However, we are hoping to retire the X509 support in the short-t= o-medium term, so I'm also looking for solutions that do not use it. I'm al= so not sure how the use of X509 certificates would fit in with an RFC-compl= iant implementation of the Dynamic Client Registration Protocol. > > > > Thanks in advance for your help, > > Matt > > > > > > _______________________________________________ > > OAuth mailing 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 Dave Tonge --0000000000005dfd7a056e7f3d4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matt

For an example of how they are being used by UK OpenBank= ing please look here:
https://bitbucket.org/openi= d/obuk/src/4630771db004da59992fb201641f5c4ff2c881f1/uk-openbanking-registra= tion-profile.md?at=3Dmaster&fileviewer=3Dfile-view-default
Dave

On 1 June 2018 at 17:21, George Fletcher <= ;g= ffletch=3D40aol.com@dmarc.ietf.org> wrote:
=20 =20 =20
Hi Matt,

I think your use case is fully within the use cases enabled by software-statements.

A per client software-statement allows you to tighten the security model (if desired). For example binding the software-statement to the client presenting it in such a way as to have a cryptographic trust chain. Unfortunately, the specifications are not clear about the best way to do this. The Client Registration Request does allow for "extension parameters" so that may be a way to ad= d what's necessary.

Thanks,
George

On 6/1/18 10:33 AM, = Matt Pryor - UKRI STFC wrote:
Hi George,

That did occur to me. It seemed like a bit of an abuse of the software-stat=
ement system, but maybe it is partially intended for this.

It still needs us to securely distribute the software statement as well. Wo=
uld you envisage a single software-statement for all installations, with ea=
ch installation specifying their own client-specific metadata, or would you=
 issue a software-statement per installation. The second sounds like it wou=
ld allow us to exert more control.

Thanks for your help!
Matt

=EF=BB=BFOn 01/06/2018, 15:28, "George Fletcher" <gffletch@aol.com> wrote:

    Given that you have a federation, could not the federation issue the=20
    signed software-statement to each of the relying parties (existing or=
=20
    old) and the AS will trust the dynamic client registration if and only=
=20
    if the signed software-statement is signed by the federation. This fits=
=20
    more closely with the trust framework model.
   =20
    Thanks,
    George
   =20
    On 6/1/18 9:57 AM, Matt Pryor - UKRI STFC wrote:
    > Hi,
    >
    > I am working on a use case of OAuth 2.0 in a federation and am aft=
er some advice about bootstrapping trust.
    >
    > Each site in the federation has an OAuth 2.0 authorization server =
and an OAuth 2.0 relying party. The relying party at each site needs to be =
registered with all the authorization servers in the federation. We want to=
 automate as much of this process as possible, but restrict client registra=
tion to trusted members of the federation. We also want to make onboarding =
a new federation member as easy as possible.
    >
    > This seems an ideal use case for the Dynamic Client Registration P=
rotocol (RFC 7591). The RFC permits the client registration endpoint to req=
uire a pre-existing token in order to register a new client which gives us =
our security (only trusted federation members can register a client).
    >
    > The challenge seems to be in bootstrapping the initial trust. It s=
eems cumbersome to require that a new federation member must manually obtai=
n a token from each authorization server before registering - they may as w=
ell manually register their client. I'd be interested to know if anyone=
 has any ideas for a solution other than securely distributing a shared sec=
ret to new federation members.
    >
    > One possible option is to piggy-back on the legacy authn/z we alre=
ady have - users can obtain an X509 certificate from their home idp, which =
is then trusted by all the other sites. We can then obtain SAML assertions =
about their permissions based on that certificate. We could use this mechan=
ism to maintain a list of trusted admins, requiring authentication with an =
X509 certificate with the correct SAML assertion for the client registratio=
n endpoint. However, we are hoping to retire the X509 support in the short-=
to-medium term, so I'm also looking for solutions that do not use it. I=
'm also not sure how the use of X509 certificates would fit in with an =
RFC-compliant implementation of the Dynamic Client Registration Protocol.
    >
    > Thanks in advance for your help,
    > Matt
    >
    >
    > _______________________________________________
    > OAuth mailing list
    > OAuth@ietf.org
    > https://www.iet=
f.org/mailman/listinfo/oauth
    >
   =20
   =20


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




--
=
<= div style=3D"font-size:14px;font-weight:normal;color:rgb(51,51,51);font-fam= ily:lato,"open sans",arial,sans-serif;line-height:normal">
Dave Tonge

<= /div>
--0000000000005dfd7a056e7f3d4c-- From nobody Wed Jun 13 14:44:04 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215F5130E8F for ; Wed, 13 Jun 2018 14:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n18g-PAWVFSm for ; Wed, 13 Jun 2018 14:43:59 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958281271FF for ; Wed, 13 Jun 2018 14:43:59 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id d185-v6so5061801ioe.0 for ; Wed, 13 Jun 2018 14:43:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cCwchyvUlXEuvRTPisuXWH7I8X6svJy4FZSRMCsqfpA=; b=nZodvxLYajRCR8A+COfNxdbfvH9obzqsxry2wd36u0/GJpMeAr5cqQbLKEyrBFG/Fi c4XFS0PXnyWUt7Q9gB71uIZqA3Eeq0kcXD/fFKLXZfaJnu3UnJDEKxdoCGTPwAStf2hS HzyZG67/qef1bORyUOeaADQC5C73xI/12FBjY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cCwchyvUlXEuvRTPisuXWH7I8X6svJy4FZSRMCsqfpA=; b=Wzx74QPehA0uNPfqwdsfaQLG8/6yfjNOu4XGTvaUtyppEbmgvSJWPxnIy4WH0Cwpn6 rLKUrHLt+TsVkqd3ILQmC029sQYCOZT7o1ru6ZQdqCMD92SZXD6IFsf0D2L32RbzmCUS ZQx/vvdB25ahXxeRqRLnjFXnonVSoAb0SFZBdV8c/UWsJni8lMQ/OY6uQM1jjsE//KL3 fg+3jDId4t7thDVpjDoDr6NeytWvpsS88MgAZtsxzDZRlgqZiHquIK5A3MNO2uo+lBDQ aKV+ur5kdMoJPUJ9BVXjwrLukE1UvJ2VEYNWymKNhl7dr3WzsA23pqAaISOcS+JYQT6A PVZg== X-Gm-Message-State: APt69E2++ZKNljWLJjpdeqoi/vjktIBCTVV3vg2PUxnROAHvcIOYt7sT NuqB1xp/B8SU9CKqLITpms1cElzOscfQ00wZeIAB1xkIacTVu1Chm8PesNw3AeLzGE7ei16Xzdr NInLrl1ZipZxxaQ== X-Google-Smtp-Source: ADUXVKJlKzrKTGokkleRnC2jrDVzVbLIJe3HXWAqyYUooTbtLmFLEauxj76oI+RQolikKO9l0q8u1x7WxbmglWKTZWs= X-Received: by 2002:a6b:d90e:: with SMTP id r14-v6mr6683015ioc.247.1528926238805; Wed, 13 Jun 2018 14:43:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:9785:0:0:0:0:0 with HTTP; Wed, 13 Jun 2018 14:43:28 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 13 Jun 2018 15:43:28 -0600 Message-ID: To: Jared Hanson Cc: oauth Content-Type: multipart/alternative; boundary="0000000000005a2941056e8ce1fb" Archived-At: Subject: Re: [OAUTH-WG] updated Distributed OAuth ID X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 21:44:03 -0000 --0000000000005a2941056e8ce1fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review and suggestions, Jared. A token (pun intended!) attempt at addressing your comments follows. Though I don't think I actually discussed it with my co-authors, I did think about the link relation for the AS being the issuer rather than pointing to the metadata document under ".well-known". I must admit that I kinda liked using the full URL to the metadata because it relieved the client from having to figure it out from the issuer. Which could be cumbersome for clients given that there's both ".well-known/openid-configuration" and the soon to be ".well-known/oauth-authorization-server" as well as different procedures for forming the full metadata URL from the issuer value when the issuer contains a path component. Having said that though, I'm inclined to agree with you that the *right* thing to do here is have the link relation to the AS be just the issuer value. Or at lest invite more discussion about it. "oauth2-isser" seems a perfectly reasonable relation name, should we take that route. The idea behind the "resource_uri" link relation (and this likely needs to be expanded on better in the document) is that it is like the base URL of the application or set of protected resources. So, for example, both a request to https://api.example.com/someapp/stuff/abc123 and https://api.example.com/someapp/stuff/xyz789 might get a 401 with resource_uri link relation value of . Or a requests to https://resources.example.com/some/deeper/path/here and https://resources.example.com/things might both get a 401 with resource_uri link relation value of . RFC6596 says in the abstract that the "canonical" Link Relation is used to "designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content". "canonical" doesn't seem to fit the purpose from that text and reading RFC6596 didn't help me see it fit either. I looked through the registry for Link Relation Types and nothing jumped out at me as being applicable for this. The client check of the host in the link relation to the host where the request was made is intended to protect against what the draft calls Resource Server Impersonation in 6.2 where a bad RS would return a 401 with a link relation for a different sever which would result in the client asking for a token for that different server but using it with the bad server, who in turn could replay it at the different server. PoP tokens could also prevent such replay in a different way but for bearer tokens I think the check is needed to ensure the right audience gets into the token. On Tue, Jun 12, 2018 at 4:57 PM, Jared Hanson wrote= : > Thanks Dick, Nat and Brian for your work on this ID. I have a couple > improvements I would like to discuss: > > I would suggest replacing the "oauth_server_metadata_uri" link relation > with "oauth2-isser", and dropping the ".well-known" suffix from the value= . > For example: > > Link: ; rel=3D"oauth2-issuer" > > The rationale for this are two-fold: > > 1. It allows the discovery mechanism to be more flexible, or application > specific. For instance, OpenID Connect discovery could be used and take > advantage of already deployed ".well-known/openid-configuration" > documents. Applications could also take advantage of other discovery > mechanisms, either now (such as LRDD and WebFinger) or in the future. > > 2.. It aligns the syntax (underscores vs dash) with > https://tools.ietf.org/html/draft-wmills-oauth-lrdd-07 > (which I also think should be revived as link relations). Also, existing > conventions with registered link relations seem to prefer dashes rather > than underscores. > > I would suggest replacing the "resource_uri" link relation with > "canonical" (RFC6596), which seems to fit the purpose and avoids > registering a potentially duplicative link relation value. > > There is language in the draft requiring the client to check "host" value= s > between TLS certificates and link relation values. This seems unnecessar= y > to me, for a couple reasons. > > 1. It unnecessarily constrains the logical organization of resources, > which may be hosted on multiple domains and yet have a canonical URL by > which other systems, including the authorization server, identify them. > Allowing the canonical URL to differ from the host of the initial request > will avoid these limitations. > > 2. The resource server must ultimately do audience checking in order to > validate the access token. I believe this accounts for all the security > considerations, and alleviates the burden from the client to do any > checking itself.. > > Jared Hanson > Auth0 Inc. > > -- > Jared Hanson > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000005a2941056e8ce1fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review and suggestions, Jared. A token (pun= intended!) attempt at addressing your comments follows.

Though I do= n't think I actually discussed it with my co-authors, I did think about= the link relation for the AS being the issuer rather than pointing to the = metadata document under ".well-known".=C2=A0 I must admit that I = kinda liked using the full URL to the metadata because it relieved the clie= nt from having to figure it out from the issuer. Which could be cumbersome = for clients given that there's both ".well-known/openid-confi= guration" and the soon to be ".well-known/oauth-authorizatio= n-server" as well as different procedures for forming the full metadat= a URL from the issuer value when the issuer contains a path component. Havi= ng said that though, I'm inclined to agree with you that the *right* th= ing to do here is have the link relation to the AS be just the issuer value= . Or at lest invite more discussion about it. "oauth2-isser" seem= s a perfectly reasonable relation name, should we take that route.

T= he idea behind the "resource_uri" link relation (and this likely = needs to be expanded on better in the document) is that it is like the base= URL of the application or set of protected resources. So, for example, bot= h a request to https://api.example.com/someapp/stuff/abc123 and ht= tps://api.example.com/someapp/stuff/xyz789 might get a 401 with re= source_uri link relation value of <https://api.example.com/someapp/>. Or= a requests to https://resources.example.com/some/deeper/path/h= ere and https://resources.example.com/things might both get a 401 with= resource_uri link relation value of <https://resources.example.com/>. RFC= 6596 says in the abstract that the "canonical" Link Relation is u= sed to "designate an Internationalized Resource Identifier (IRI) as pr= eferred over resources with duplicative content". =C2=A0"canonica= l" doesn't seem to fit the purpose from that text and reading RFC6= 596 didn't help me see it fit either. I looked through the registry for= Link Relation Types and nothing jumped out at me as being applicable for t= his.

The client check of the host in the link relation to the host w= here the request was made is intended to protect against what the draft cal= ls Resource Server Impersonation in 6.2 where a bad RS would return a 401 w= ith a link relation for a different sever which would result in the client = asking for a token for that different server but using it with the bad serv= er, who in turn could replay it at the different server. PoP tokens could a= lso prevent such replay in a different way but for bearer tokens I think th= e check is needed to ensure the right audience gets into the token.



On= Tue, Jun 12, 2018 at 4:57 PM, Jared Hanson <jaredhanson@gmail.com> wrote:
Thanks Dick, Nat and Brian for your work on this ID.=C2=A0 I have a coupl= e improvements I would like to discuss:

I would su= ggest replacing the "oauth_server_metadata_uri" link relation wit= h "oauth2-isser", and dropping the ".well-known" suffix= from the value.=C2=A0 For example:

Link: <https://as.example.com= >; rel=3D"oauth2-issuer"

The rational= e for this are two-fold:

1. It allows the discover= y mechanism to be more flexible, or application specific.=C2=A0 For instanc= e, OpenID Connect discovery could be used and take advantage of already dep= loyed ".well-known/openid-configuration" documents.=C2=A0 Ap= plications could also take advantage of other discovery mechanisms, either = now (such as LRDD and WebFinger) or in the future.

2.. It aligns the syntax (underscores vs dash) with https://tool= s.ietf.org/html/draft-wmills-oauth-lrdd-07
(which I also= think should be revived as link relations).=C2=A0 Also, existing conventio= ns with registered link relations seem to prefer dashes rather than undersc= ores.

I would suggest replacing the "resource= _uri" link relation with "canonical" (RFC6596), which seems = to fit the purpose and avoids registering a potentially duplicative link re= lation value.
=C2=A0 =C2=A0
There is language in the dr= aft requiring the client to check "host" values between TLS certi= ficates and link relation values.=C2=A0 This seems unnecessary to me, for a= couple reasons.

1. It unnecessarily constrains th= e logical organization of resources, which may be hosted on multiple domain= s and yet have a canonical URL by which other systems, including the author= ization server, identify them.=C2=A0 Allowing the canonical URL to differ f= rom the host of the initial request will avoid these limitations.

2. The resource server must ultimately do audience checking= in order to validate the access token.=C2=A0 I believe this accounts for a= ll the security considerations, and alleviates the burden from the client t= o do any checking itself..

Jared Hanson
Auth0 Inc.

--
Jared Hanson = <http://jaredhanso= n.net/>

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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000005a2941056e8ce1fb-- From nobody Mon Jun 18 08:34:35 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80049130ED7 for ; Mon, 18 Jun 2018 08:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2vHFAvbixzw for ; Mon, 18 Jun 2018 08:34:16 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472FF12872C for ; Mon, 18 Jun 2018 08:34:10 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fUwAQ-0003Nz-4m for oauth@ietf.org; Mon, 18 Jun 2018 17:34:06 +0200 From: Torsten Lodderstedt Content-Type: multipart/signed; boundary="Apple-Mail=_76B68401-AE3F-47F9-BBA8-89094742DC2F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> Date: Mon, 18 Jun 2018 17:34:05 +0200 To: oauth X-Mailer: Apple Mail (2.3445.8.2) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 15:34:33 -0000 --Apple-Mail=_76B68401-AE3F-47F9-BBA8-89094742DC2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I have been working lately on use cases where OAuth is used to authorize = transactions in the financial sector and electronic signing. What I = learned is there is always the need to pass resource ids (e.g. account = numbers) or transaction-specific values (e.g. amount or hash to be = signed) to the OAuth authorization process to further qualify the scope = of the requested access token.=20 It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor = =E2=80=9Esign=E2=80=9C, won=E2=80=99t do the job. For example in case of = electronic signing, one must bind the authorization/access token to a = particular document, typically represented by its hash. I would like to get your feedback on what you consider a good practice = to cope with that challenge. As a starting point for a discussion, I = have assembled a list of patterns I have seen in the wild (feel free to = extend).=20 (1) Parameter is part of the scope value, e.g. = =E2=80=9Esign:=E2=80=9C or = "payments:" - I think this is an obvious way to = represent such parameters in OAuth, as it extends the scope parameter, = which is intended to represent the requested scope of an access token. I = used this pattern in the OAuth SCA mode in Berlin Group's PSD API.=20 (2) One could also use additional query parameter to add further details = re the requested authorization, e.g.=20 GET /authorize? ... &scope=3Dsign ... &hash_to_be_signed=3D It seems to be robust (easier to implement?) but means the scope only = represents the static part of the action. The AS needs to look into a = further parameter to fully understand the requested authorization.=20 (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80=9C= parameter to carry additional data.=20 Example: =20 "claims": { "id_token": { "acr": { "essential": true, "value": "..." }, "hash_to_be_signed": { "essential": true, "value": "" } }, "userinfo": { "hash_to_be_signed": { "essential": true, "value": "" } } } I=E2=80=98m looking forward for your feedback. Please also indicated = whether you think we should flush out a BCP on that topic.=20 kind regards, Torsten.= --Apple-Mail=_76B68401-AE3F-47F9-BBA8-89094742DC2F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNjE4MTUzNDA2WjAjBgkqhkiG9w0BCQQxFgQUFrY65h/smCkK UqV0lP8Oqj3wRuEwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBALvZtg1dY71xU2fWa79hihxuzynwIIQPf8le63rIv8wkUB6EYEjq BvlSDlabjSkeizJCeXl4uh77hzF7QDhpMCHF8tQkoBQPE49tvk/W1TC8ykDP3HKqz7nl9GTnqvCV yj9QGSSy9E3YytwgwwVTqvC63OizS3PK87dz6pdaNsJdC5B7PXTTfb4eLdvtyj3g675ig6O9mkgy e+IzJ71/TeA4QMaSNSqMxzVUf8w7d31l2HfW/oR1Jea+Y3Hrfzcmwibp9D/Y7jUZI1klbs3KJIxE xhz220aooUnoOqLVZjSWvW+Ng5U1NVi3/FbqW88fA93lOps4IiRSW3LZoMJgKskAAAAAAAA= --Apple-Mail=_76B68401-AE3F-47F9-BBA8-89094742DC2F-- From nobody Mon Jun 18 09:47:51 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFE5130DCD for ; Mon, 18 Jun 2018 09:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DK50QpedEVG for ; Mon, 18 Jun 2018 09:47:46 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A46130E0E for ; Mon, 18 Jun 2018 09:47:46 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id p185-v6so12935347itp.4 for ; Mon, 18 Jun 2018 09:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=adBo4qAJyiUlPtAsEj0UJAJ4JnjDXRsmMJNRv8P5Jw0=; b=O3RSgnjG49QykNLVxKWQ9/9857k4lcr9p/M/AeNGnJTKxFG32D7Jg/L/czNUqv7YqW EXRJ/hxK1c2Rg8+Mbqswf4Rrd2/k3b19EKDf4CzrcHBRwtofa/DCwFM8XAN0/WSC/MdR 7s9wqe36wOlOnRLErxbM1PiJEcjNnZLbSl36w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=adBo4qAJyiUlPtAsEj0UJAJ4JnjDXRsmMJNRv8P5Jw0=; b=M5S54uGlBW4FhFdwa0ldDog+7xs9dEnhNO9aCFtB6DiF2WHcwkVilH0+2T0pN2SL1w 7rDLFOmrheAUU2XfU1iv3vP8pZheX/jN0wv8GwSzhUgv1cuPMyjW3W9HpoD/aqAcIoeU lBpTqWkY0oIlqLcDx4hYakYfR3LpV7bwxT8GFnNAbARU5td6rgmmuE7mODDsA2Uvpk8g yzIqAlEH4Wl7Fu2f76IHgTyyKiM9Cz74+H5N5Jn0+CGXYKBarz0HRv6ePQuYgVTlQ3F2 UUKDA/iVTDyW6pyRB3KEXtZ1kdbcOGL3zB0szaizCBnRMkh3bCwj9zfh+pKRE6Im6xyy imSg== X-Gm-Message-State: APt69E1U8RqR3IJPVLpqIgrOt44DvXYxEG8LxBMPmrnr+iQ6svHe7mjY gvaIJEFEluAsjugtrcIMxkA2WyMhsd+x6eXqnylgHDMDlp9+9eFk3lQpcu+CUyeQh8pc4ruvCEO uioNBjLotzrrTaA== X-Google-Smtp-Source: ADUXVKLD4S/xaxAhRnPP4vlFrtWtB3voYE9W4x3FB6r75PhT0REIdfFEE9vawuglB33p3voEhVPZIJEwzL49sGKLtr4= X-Received: by 2002:a24:2246:: with SMTP id o67-v6mr9907906ito.25.1529340465606; Mon, 18 Jun 2018 09:47:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:9785:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 09:47:15 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 18 Jun 2018 10:47:15 -0600 Message-ID: To: Hannes Tschofenig Cc: "" Content-Type: multipart/alternative; boundary="0000000000003197ab056eed53c8" Archived-At: Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:47:50 -0000 --0000000000003197ab056eed53c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I tried to join this morning but was the only one on the webex (of course, user error could be involved on my part). I didn't have much specific for the call but did want to politely ask the Chairs how the document shepherding was coming along for https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ ? On Wed, May 16, 2018 at 11:38 AM, Hannes Tschofenig < Hannes.Tschofenig@arm.com> wrote: > Hi all, > > > > Rifaat and I will again dial into the Webex next Monday to hear whether > someone of you has anything to discuss/report/suggest/=E2=80=A6. > > > > Ciao > Hannes & Rifaat > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000003197ab056eed53c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I tried to join this morning but was the only one on = the webex (of course, user error could be involved on my part).
<= div>
I didn't have much specific for the call but did wan= t to politely ask the Chairs how the document shepherding was coming along = for https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/= ?


<= br>
On Wed, May 16, 2018 at 11:38 AM, Hannes Tsch= ofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

Rifaat and I will again dial into the Webex next Mon= day to hear whether someone of you has anything to discuss/report/suggest/= =E2=80=A6.

=C2=A0

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000003197ab056eed53c8-- From nobody Mon Jun 18 10:18:30 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140B4130DF9 for ; Mon, 18 Jun 2018 10:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsnMUNoTciPn for ; Mon, 18 Jun 2018 10:18:24 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658C212872C for ; Mon, 18 Jun 2018 10:18:24 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id d7-v6so11159650uam.13 for ; Mon, 18 Jun 2018 10:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6Mv2C6Nr992j/ZxAVHeW5tIx9wh/VNCkwoSCLdD2SfY=; b=VYJ77dDF3A91G+2oIaAljlRPa/C+Y9+6Lth7V09xz+33Fjj4atQCkdf5GRIuCsAmuP CfR1bB1TYubNnhiFyF3EEVFQRFckRrBdNePeCTwnfltTywuo8v0/j+cxBOK5UQvvvb2I vCh6HQodaV9x4E5NuI8yUx9Z7jikCLxPaNdzCQ5phYz16eJRdcXiT3xm3nr3/bXDlk1x NpCNkCORSLBEUr5py8fhu6xLlrThdCrEypGKwvTYaI2xPT4imvv5LKFmOgEIXGYZxqqO LKUsvfEDHBj7vdtr5s8Suft/fYj9gPKtbF1suQD/ZETJinkUNZEJlYl84Mop6fMueBx8 vMXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6Mv2C6Nr992j/ZxAVHeW5tIx9wh/VNCkwoSCLdD2SfY=; b=ne+KLxsDkjk7XRfFrErjbeWZp1OzZQpVvvCyo9MStwDc/Y1kXanfOiVuCTlKZV2dP/ NGMsZoPt+kuCyHCynUQQ7LmpjMkiDbMcysQmItiNJF3osYFweq+VKr7poykXrnkoN+Pf HFbnlJHqBlXI277BFLuWfXOcjyzx2Vhb457bXbJrg0TV65o6gR0RpUVmfEuNW8OIc7Hv lfVK3CDbWzLhs3fik4P5TBC6u5NTfEFedXJQ9PUWixcoU2sspTRyehmpmBhxfKupPxzg AYaMKylAgbeIMoT6IGWIs14iLms50tfytoXRcvjbddM+Au0zaZSLKivzAfSMXYPgfzIS PAbg== X-Gm-Message-State: APt69E1jjN2DIm/Asl+/vOsMPNZohqbRf23Dl7EBLJUR0N7jCe6lVnRW 8G5fWArBx38Mg/ti00wdpfTd15j4a36NWNBnXJS+ig== X-Google-Smtp-Source: ADUXVKLJeuUniDq8/mosJrNT1YG3aVzBX3VGeAEIy49+GsRIZn/l/HTDL9sA8yBlTgCY1Hpaqs+eq4EA0kgyS53ZVBs= X-Received: by 2002:ab0:4889:: with SMTP id x9-v6mr8393699uac.132.1529342303348; Mon, 18 Jun 2018 10:18:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rifaat Shekh-Yusef Date: Mon, 18 Jun 2018 13:18:44 -0400 Message-ID: To: bcampbell=40pingidentity.com@dmarc.ietf.org Cc: Hannes Tschofenig , oauth Content-Type: multipart/alternative; boundary="000000000000bb3225056eedc024" Archived-At: Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 17:18:28 -0000 --000000000000bb3225056eedc024 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hmmm, I did open webex and waited for 10 minutes :) I will be traveling this week, but I will discuss it with Hannes in the coming few days and we will start working on the write-ups for the MTLS and JWT BCP documents soon. Regards, Rifaat On Mon, Jun 18, 2018 at 12:48 PM Brian Campbell wrote: > I tried to join this morning but was the only one on the webex (of course= , > user error could be involved on my part). > > I didn't have much specific for the call but did want to politely ask the > Chairs how the document shepherding was coming along for > https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ ? > > > > On Wed, May 16, 2018 at 11:38 AM, Hannes Tschofenig < > Hannes.Tschofenig@arm.com> wrote: > >> Hi all, >> >> >> >> Rifaat and I will again dial into the Webex next Monday to hear whether >> someone of you has anything to discuss/report/suggest/=E2=80=A6. >> >> >> >> Ciao >> Hannes & Rifaat >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy t= he >> information in any medium. Thank you. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --000000000000bb3225056eedc024 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hmmm, I did open webex and waited for 10 minutes :)

I will be traveling this week, but I will discuss i= t with Hannes in the coming few days and we will start working on the write= -ups for the MTLS and JWT BCP documents soon.

Rega= rds,
=C2=A0Rifaat


On Mon, Jun 18, 2018 at 12:48 PM Brian Campbell = <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
I tried to join this mornin= g but was the only one on the webex (of course, user error could be involve= d on my part).

I didn't have much specifi= c for the call but did want to politely ask the Chairs how the document she= pherding was coming along for https://datatracker.ietf.org/doc/d= raft-ietf-oauth-mtls/ ?



On Wed, May 16, 2018 at = 11:38 AM, Hannes Tschofenig <Hannes.Tschofenig@arm.com> wrote:

Hi all,

=C2=A0

Rifaat and I will again dial into the Webex next Mon= day to hear whether someone of you has anything to discuss/report/suggest/= =E2=80=A6.

=C2=A0

Ciao
Hannes & Rifaat

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--000000000000bb3225056eedc024-- From nobody Mon Jun 18 11:59:43 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E68130E2E for ; Mon, 18 Jun 2018 11:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgXKbbSjFOZk for ; Mon, 18 Jun 2018 11:59:36 -0700 (PDT) Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 87E7D130E29 for ; Mon, 18 Jun 2018 11:59:36 -0700 (PDT) Received: from [IPv6:2601:282:202:b210:cd65:9d8a:6537:2e83] (unknown [IPv6:2601:282:202:b210:cd65:9d8a:6537:2e83]) by alkaline-solutions.com (Postfix) with ESMTPSA id D9FE531544; Mon, 18 Jun 2018 18:59:35 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: David Waite In-Reply-To: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> Date: Mon, 18 Jun 2018 12:59:34 -0600 Cc: oauth Content-Transfer-Encoding: quoted-printable Message-Id: References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> To: Torsten Lodderstedt X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 18:59:40 -0000 One of the reasons I hear for people wanting parameterized scopes is to = deal with transactions. I=E2=80=99d love to hear thoughts from the group = on if/how OAuth should be used to authorize a transaction, vs authorize = access to information/actions for a period of time. This approach for = instance sounds like it is trying to scope down access to a single = resource representing a transaction to be performed? I also hear people wanting dynamic scopes to support a finer-grained = access control, for instance not =E2=80=98allow moderation of chat = rooms=E2=80=99 but rather the list of *specific* rooms. There is = sometimes a case to be made that this would be better served as local = state in the resource, or as the result of an API call, but there is = value in some use cases to represent this as a finer-grained consent to = the user. I=E2=80=99ve seen parameterized scopes take the form of = colon-deliminated name:param, as a function name(param), or as a URL = https://nameurl?param=3Dvalue. The latter is recommended sometimes in = specs like opened connect as a way to prevent conflicting vendor = extensions. In terms of requesting a parameterized scope - I prefer overloading = scope (or perhaps claims when using connect) vs adding a new = authorization request parameter - for one, use of authorization request = parameters limits your grant type options unless you also define them as = token request parameters for the other types. Second, the = consent/business logic for determining which scopes a client get should = already be a customization point for a reusable AS. -DW > On Jun 18, 2018, at 9:34 AM, Torsten Lodderstedt = wrote: >=20 > Hi all, >=20 > I have been working lately on use cases where OAuth is used to = authorize transactions in the financial sector and electronic signing. = What I learned is there is always the need to pass resource ids (e.g. = account numbers) or transaction-specific values (e.g. amount or hash to = be signed) to the OAuth authorization process to further qualify the = scope of the requested access token.=20 >=20 > It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor = =E2=80=9Esign=E2=80=9C, won=E2=80=99t do the job. For example in case of = electronic signing, one must bind the authorization/access token to a = particular document, typically represented by its hash. >=20 > I would like to get your feedback on what you consider a good practice = to cope with that challenge. As a starting point for a discussion, I = have assembled a list of patterns I have seen in the wild (feel free to = extend).=20 >=20 > (1) Parameter is part of the scope value, e.g. = =E2=80=9Esign:=E2=80=9C or = "payments:" - I think this is an obvious way to = represent such parameters in OAuth, as it extends the scope parameter, = which is intended to represent the requested scope of an access token. I = used this pattern in the OAuth SCA mode in Berlin Group's PSD API.=20 >=20 > (2) One could also use additional query parameter to add further = details re the requested authorization, e.g.=20 >=20 > GET /authorize? > .... > &scope=3Dsign > .... > &hash_to_be_signed=3D >=20 > It seems to be robust (easier to implement?) but means the scope only = represents the static part of the action. The AS needs to look into a = further parameter to fully understand the requested authorization.=20 >=20 > (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80=9C= parameter to carry additional data.=20 >=20 > Example: =20 >=20 > "claims": { > "id_token": { > "acr": { > "essential": true, > "value": "..." > }, > "hash_to_be_signed": { > "essential": true, > "value": "" > } > }, > "userinfo": { > "hash_to_be_signed": { > "essential": true, > "value": "" > } > } > } >=20 > I=E2=80=98m looking forward for your feedback. Please also indicated = whether you think we should flush out a BCP on that topic.=20 >=20 > kind regards, > Torsten._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jun 18 14:06:26 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EE6130E76 for ; Mon, 18 Jun 2018 14:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2mFExcNqkte for ; Mon, 18 Jun 2018 14:06:20 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40071.outbound.protection.outlook.com [40.107.4.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D24130E47 for ; Mon, 18 Jun 2018 14:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pBUkx4V+Lj9fe2bX4nkY8KBGLSkz6GCjykPOSvgzq0Q=; b=S5mG6IWF0feK6o9TBBfuVigrnB/d260XQbqkVe8YBFMI8QYiTYAGiIiglm11goVTSzN0xQjM9EiiG/6jf3UJK5cwd1Eiie0DSHPuWtfuo2IsfvV6hjDsS0LjSA76HIY0VvArVKz8q+5+YarPERHHxMkrgUAXfvMZI0asYlzUA2A= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1840.eurprd08.prod.outlook.com (10.168.68.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Mon, 18 Jun 2018 21:06:17 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Mon, 18 Jun 2018 21:06:17 +0000 From: Hannes Tschofenig To: Brian Campbell CC: Rifaat Shekh-Yusef , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours Thread-Index: AdPtPHCaHL5IGsSwSyidRnL+pJRcMAZ55JWAAAkDwlA= Date: Mon, 18 Jun 2018 21:06:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [5.148.12.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1840; 7:Aqfj0ca73XykRlNpiT+0cBsdF+GNm+GeelgQNFeawD2voO5FVhtuswFG9Jqor2ANA9fi5nqooWDOK2V33thHKUhPOJkafQcGdHc4S9ouL1oL5Xs+CGQHbW4RfBBIkBGFQ3FgDFlvwc4Km9scKcVqdx4MgWDQZD309YzbFx15XKbOtSm94IV1ol1ioQWWOgz+qS8wFgg+jVW5sezlDtbPSzrI2z2KjEzprcXI+s1fJBW7EsroH+f0G7XvHbnVd8oR x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f159f3a1-fed0-47be-95e5-08d5d55f555a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1840; x-ms-traffictypediagnostic: VI1PR0801MB1840: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(120809045254105)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1840; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1840; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39380400002)(366004)(346002)(39860400002)(40434004)(189003)(38314003)(199004)(53754006)(2906002)(8676002)(966005)(5890100001)(26005)(81166006)(3280700002)(5660300001)(5250100002)(3660700001)(71446004)(229853002)(6436002)(186003)(6306002)(102836004)(76176011)(55016002)(72206003)(478600001)(790700001)(6116002)(81156014)(59450400001)(6916009)(86362001)(3846002)(8936002)(53546011)(6506007)(53936002)(14454004)(106356001)(25786009)(97736004)(39060400002)(66066001)(99286004)(2900100001)(7696005)(7736002)(486006)(476003)(236005)(68736007)(74316002)(54896002)(9686003)(606006)(11346002)(446003)(54906003)(6246003)(105586002)(316002)(33656002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1840; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: sRqIkWSRxxBHI2H2I8Ml96Edpx0WZNViSC4vjKEq3iPq/8xJcS4t/wePUVy/WVrsbY/0UIHV5WcdWpV7IcSJXsMTlH50zs54X30v4lW0lRuzPFG7+oO6M/D9kpAN620LzgOWRFJI/5gk412vZVO8aOErYWd7DgX3nuEsEpoQTUnuxh4UetwSIBdcwk03yCKH6thhTvI2NlaMJNcLTz1tK2ALEOWoK/mC/Ubheceje9I8qncS6ArCqGz4yKNHAcw8dEwytYO8PFuDkn8668HUXF6WzYyQJUjaERbyIk0QVKyK/OWSfVDjx9ARDLTu0/eRukdEKCBzSnPrSBexdZBzHA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112C7B75E121B01EF2B2C59FA710VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: f159f3a1-fed0-47be-95e5-08d5d55f555a X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 21:06:17.2211 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1840 Archived-At: Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 21:06:25 -0000 --_000_VI1PR0801MB2112C7B75E121B01EF2B2C59FA710VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmlmYWF0IHdhcyBvbiB0aGUgY2FsbCBmb3IgMzBtaW5zIGJ1dCBub2JvZHkgam9pbmVkLiBJIGNv dWxkbuKAmXQgbWFrZSBpdCBkdWUgdG8gYSBkZWxheWVkIGZsaWdodC4NCg0KV3JpdGUtdXBzIGFy ZSBpbiBwcm9ncmVzcy4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KRnJvbTogQnJpYW4gQ2FtcGJlbGwg W21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6IDE4IEp1bmUgMjAxOCAx ODo0Nw0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogPG9hdXRoQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gTWVldGluZyBJbnZpdGUgZm9yIHRoZSBPQXV0aCBXRyBWaXJ0dWFs IE9mZmljZSBIb3Vycw0KDQpJIHRyaWVkIHRvIGpvaW4gdGhpcyBtb3JuaW5nIGJ1dCB3YXMgdGhl IG9ubHkgb25lIG9uIHRoZSB3ZWJleCAob2YgY291cnNlLCB1c2VyIGVycm9yIGNvdWxkIGJlIGlu dm9sdmVkIG9uIG15IHBhcnQpLg0KDQpJIGRpZG4ndCBoYXZlIG11Y2ggc3BlY2lmaWMgZm9yIHRo ZSBjYWxsIGJ1dCBkaWQgd2FudCB0byBwb2xpdGVseSBhc2sgdGhlIENoYWlycyBob3cgdGhlIGRv Y3VtZW50IHNoZXBoZXJkaW5nIHdhcyBjb21pbmcgYWxvbmcgZm9yIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtbXRscy8gPw0KDQoNCg0KT24gV2VkLCBN YXkgMTYsIDIwMTggYXQgMTE6MzggQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9m ZW5pZ0Bhcm0uY29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj4gd3JvdGU6DQpI aSBhbGwsDQoNClJpZmFhdCBhbmQgSSB3aWxsIGFnYWluIGRpYWwgaW50byB0aGUgV2ViZXggbmV4 dCBNb25kYXkgdG8gaGVhciB3aGV0aGVyIHNvbWVvbmUgb2YgeW91IGhhcyBhbnl0aGluZyB0byBk aXNjdXNzL3JlcG9ydC9zdWdnZXN0L+KApi4NCg0KQ2lhbw0KSGFubmVzICYgUmlmYWF0DQpJTVBP UlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZv cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgNCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwg ZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0 ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0 aGUgbWVzc2FnZSBhbmQgYW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBU aGFuayB5b3UuDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBh bmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZp bGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50 cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBv ciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB2112C7B75E121B01EF2B2C59FA710VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOmR0PSJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1B MjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SaWZhYXQgd2FzIG9uIHRoZSBjYWxsIGZvciAzMG1p bnMgYnV0IG5vYm9keSBqb2luZWQuIEkgY291bGRu4oCZdCBtYWtlIGl0IGR1ZSB0byBhIGRlbGF5 ZWQgZmxpZ2h0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Xcml0ZS11cHMgYXJlIGluIHByb2dyZXNzLiAmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkNpYW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGFubmVzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv YT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDE4IEp1bmUgMjAxOCAxODo0Nzxicj4NCjxi PlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc8YnI+DQo8Yj5DYzo8L2I+ICZsdDtvYXV0aEBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gTWVldGluZyBJbnZp dGUgZm9yIHRoZSBPQXV0aCBXRyBWaXJ0dWFsIE9mZmljZSBIb3VyczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRyaWVkIHRvIGpvaW4gdGhpcyBtb3JuaW5n IGJ1dCB3YXMgdGhlIG9ubHkgb25lIG9uIHRoZSB3ZWJleCAob2YgY291cnNlLCB1c2VyIGVycm9y IGNvdWxkIGJlIGludm9sdmVkIG9uIG15IHBhcnQpLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGlkbid0IGhhdmUgbXVjaCBzcGVjaWZp YyBmb3IgdGhlIGNhbGwgYnV0IGRpZCB3YW50IHRvIHBvbGl0ZWx5IGFzayB0aGUgQ2hhaXJzIGhv dyB0aGUgZG9jdW1lbnQgc2hlcGhlcmRpbmcgd2FzIGNvbWluZyBhbG9uZyBmb3INCjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtbXRscy8i IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtb2F1dGgtbXRscy88L2E+ID8gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXkgMTYsIDIwMTggYXQgMTE6MzggQU0sIEhhbm5l cyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5I aSBhbGwsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJpZmFhdCBhbmQgSSB3aWxsIGFn YWluIGRpYWwgaW50byB0aGUgV2ViZXggbmV4dCBNb25kYXkgdG8gaGVhciB3aGV0aGVyIHNvbWVv bmUgb2YgeW91IGhhcyBhbnl0aGluZyB0byBkaXNjdXNzL3JlcG9ydC9zdWdnZXN0L+KApi4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2lhbzxicj4NCkhhbm5lcyAmYW1wOyBSaWZhYXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1QT1JUQU5UIE5P VElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwN CiB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRk aW5nOjBjbSI+Q09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlbWFpbCBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLg0KIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9u IG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuJm5ic3A7IElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoZSBtZXNz YWdlIGFuZCBhbnkgZmlsZSBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIuIFRoYW5rIHlv dS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBp biBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR0801MB2112C7B75E121B01EF2B2C59FA710VI1PR0801MB2112_-- From nobody Mon Jun 18 14:20:46 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CF3130E1D for ; Mon, 18 Jun 2018 14:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmONn7i_EsGI for ; Mon, 18 Jun 2018 14:20:37 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0090.outbound.protection.outlook.com [104.47.41.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D83E130E76 for ; Mon, 18 Jun 2018 14:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y9BUfnrw8UECTfbwBB3MV5epnLgUho1m+kemuIy8qV4=; b=G0IQxVOeGpR9fmwahK/iLkGA6yPv1U/uPW8jGZ6DAsG0G8vHh0+CVWQrGGmuKoFfz8SKN3taKF0azJaH7tnDF4tJdDMMxdOp8Yp16MueKsAL9+yRUtTKZeuyh8w81Nas7TiDK1rVNDmwC4ifiusKNqgm4AzL9j5fVwa2gcrgkOs= Received: from SN6PR00MB0400.namprd00.prod.outlook.com (52.132.118.31) by SN6PR00MB0399.namprd00.prod.outlook.com (52.132.118.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.919.0; Mon, 18 Jun 2018 21:20:35 +0000 Received: from SN6PR00MB0400.namprd00.prod.outlook.com ([fe80::e905:a757:e7e9:f7b5]) by SN6PR00MB0400.namprd00.prod.outlook.com ([fe80::e905:a757:e7e9:f7b5%2]) with mapi id 15.20.0917.000; Mon, 18 Jun 2018 21:20:35 +0000 From: Anthony Nadalin To: Hannes Tschofenig , Brian Campbell CC: "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours Thread-Index: AdPtPHCaHL5IGsSwSyidRnL+pJRcMAZ55JWAAAkDwlAAAIXkIA== Date: Mon, 18 Jun 2018 21:20:35 +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: [2001:4898:80e8:1:b477:7b5d:b38e:f0ef] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR00MB0399; 7:QtnZ+ScZXHpoNiyaUnjUH4L+smAjKEuQS24Z2YTrtnK0yksreubX20hk5/w5i+/ICDwRiyH6QOpyjfgCbvRS2d9h43Xpxolt3EUsPud/14L8O0+ntqy3jDlYRJMK+7HnqRw7wa6Mmq0sImABVfAE8Lsg+g1tvJt+ngKJUxRkt8vetaMQRsTTTbCF1+Krph+mGOnCi1ShG76Hn7KmoUuD4Tx+hoCn9qHdjQX+IpXeXeJ2FCt12hItTI2vinZ+4G0G x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: dcb523c7-5dc9-460f-1286-08d5d56154c8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:SN6PR00MB0399; x-ms-traffictypediagnostic: SN6PR00MB0399: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(180628864354917)(120809045254105)(189930954265078)(219752817060721)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(10201501046)(93006095)(93001095)(3231254)(2018427008)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:SN6PR00MB0399; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0399; x-forefront-prvs: 0707248B64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(396003)(39860400002)(39380400002)(40434004)(38314003)(189003)(199004)(53754006)(86362001)(2900100001)(86612001)(33656002)(106356001)(105586002)(110136005)(2906002)(3660700001)(316002)(22452003)(3280700002)(6306002)(236005)(6436002)(9686003)(54896002)(55016002)(966005)(10290500003)(14454004)(478600001)(446003)(11346002)(46003)(476003)(186003)(606006)(486006)(99286004)(6506007)(53546011)(59450400001)(102836004)(7696005)(76176011)(19609705001)(68736007)(790700001)(97736004)(10090500001)(8990500004)(6116002)(53936002)(6246003)(229853002)(4326008)(8936002)(81156014)(25786009)(81166006)(8676002)(5660300001)(7736002)(74316002)(5890100001)(5250100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0399; H:SN6PR00MB0400.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: itsub1+ztvP4Ls0tiyBrJVxGHW3AvTBhM9k5PPngdkEdDSKtspQ9c1YGmRPKDcFzz3EJORSnHPFV/kIGjfsr7xKlzHNsWbGK48z6SxjS1R/9rOAG9QOamoZn+ivLOXSUEy0nUQQXRvYnYPPfRj8tBAM+Ia1FyrxrKbiURFq42imOwxKUQDLZDCdXLtqNZk/8uXII0JklDJ6zX6PrOZ9/Cv42g8vi8WoLIyQp7lp81IqGUuFPU8bR4gHV5VgtuTJN+s8Y2x7/64E59Pmn9VpCMKyWQPkt7axJFPWKsLda3ZIuYxyHOW40pWAw/Odv8oFD2X6gsuUS6vW+cpjh9dVuCA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR00MB0400ED6896D5EE18EF6BEE8BA6710SN6PR00MB0400namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: dcb523c7-5dc9-460f-1286-08d5d56154c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2018 21:20:35.2524 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0399 Archived-At: Subject: Re: [OAUTH-WG] Meeting Invite for the OAuth WG Virtual Office Hours X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 21:20:44 -0000 --_000_SN6PR00MB0400ED6896D5EE18EF6BEE8BA6710SN6PR00MB0400namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YXMgZGlhbGVkIGluIGFuZCBubyBvbmUgd2FzIHRoZXJlDQoNCkZyb206IE9BdXRoIDxvYXV0 aC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNClNlbnQ6 IE1vbmRheSwgSnVuZSAxOCwgMjAxOCAyOjA2IFBNDQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tPg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBNZWV0aW5nIEludml0ZSBmb3IgdGhlIE9BdXRoIFdHIFZpcnR1YWwgT2ZmaWNl IEhvdXJzDQoNClJpZmFhdCB3YXMgb24gdGhlIGNhbGwgZm9yIDMwbWlucyBidXQgbm9ib2R5IGpv aW5lZC4gSSBjb3VsZG7igJl0IG1ha2UgaXQgZHVlIHRvIGEgZGVsYXllZCBmbGlnaHQuDQoNCldy aXRlLXVwcyBhcmUgaW4gcHJvZ3Jlc3MuDQoNCkNpYW8NCkhhbm5lcw0KDQoNCkZyb206IEJyaWFu IENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiAxOCBK dW5lIDIwMTggMTg6NDcNClRvOiBIYW5uZXMgVHNjaG9mZW5pZw0KQ2M6IDxvYXV0aEBpZXRmLm9y ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gTWVldGlu ZyBJbnZpdGUgZm9yIHRoZSBPQXV0aCBXRyBWaXJ0dWFsIE9mZmljZSBIb3Vycw0KDQpJIHRyaWVk IHRvIGpvaW4gdGhpcyBtb3JuaW5nIGJ1dCB3YXMgdGhlIG9ubHkgb25lIG9uIHRoZSB3ZWJleCAo b2YgY291cnNlLCB1c2VyIGVycm9yIGNvdWxkIGJlIGludm9sdmVkIG9uIG15IHBhcnQpLg0KDQpJ IGRpZG4ndCBoYXZlIG11Y2ggc3BlY2lmaWMgZm9yIHRoZSBjYWxsIGJ1dCBkaWQgd2FudCB0byBw b2xpdGVseSBhc2sgdGhlIENoYWlycyBob3cgdGhlIGRvY3VtZW50IHNoZXBoZXJkaW5nIHdhcyBj b21pbmcgYWxvbmcgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtb2F1dGgtbXRscy88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0 LWlldGYtb2F1dGgtbXRscyUyRiZkYXRhPTAyJTdDMDElN0N0b255bmFkJTQwbWljcm9zb2Z0LmNv bSU3QzA4NTk0YTJiZDk4NDQ4ODgzMjk4MDhkNWQ1NWY2MDY4JTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY0OTUyNzk4NzE2ODU5NCZzZGF0YT1NVFV2JTJC Y1dQSlhpbTRWV0FMaXBhUEVMU1V5N0olMkZlWXk4SmRMT0VueEgwbyUzRCZyZXNlcnZlZD0wPiA/ DQoNCg0KDQpPbiBXZWQsIE1heSAxNiwgMjAxOCBhdCAxMTozOCBBTSwgSGFubmVzIFRzY2hvZmVu aWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFy bS5jb20+PiB3cm90ZToNCkhpIGFsbCwNCg0KUmlmYWF0IGFuZCBJIHdpbGwgYWdhaW4gZGlhbCBp bnRvIHRoZSBXZWJleCBuZXh0IE1vbmRheSB0byBoZWFyIHdoZXRoZXIgc29tZW9uZSBvZiB5b3Ug aGFzIGFueXRoaW5nIHRvIGRpc2N1c3MvcmVwb3J0L3N1Z2dlc3Qv4oCmLg0KDQpDaWFvDQpIYW5u ZXMgJiBSaWZhYXQNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3Jl IG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRm9hdXRoJmRhdGE9MDIlN0MwMSU3Q3RvbnluYWQlNDBtaWNy b3NvZnQuY29tJTdDMDg1OTRhMmJkOTg0NDg4ODMyOTgwOGQ1ZDU1ZjYwNjglN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjQ5NTI3OTg3MTc4NTk4JnNkYXRh PTNXcnZ3T0hBcVU2ZzZnUWdZbEtSOGxzdVJOaFVyRm55bHFVaXh2N3paa0ElM0QmcmVzZXJ2ZWQ9 MD4NCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFOiBUaGlzIGVtYWlsIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9y IGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQg YW55IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLiBUaGFuayB5b3UuDQpJTVBP UlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZv cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= --_000_SN6PR00MB0400ED6896D5EE18EF6BEE8BA6710SN6PR00MB0400namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0K CXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SSB3YXMgZGlhbGVkIGluIGFuZCBubyBvbmUgd2FzIHRoZXJlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggJmx0O29hdXRoLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkhhbm5lcyBUc2Nob2ZlbmlnPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgSnVuZSAxOCwgMjAxOCAyOjA2IFBNPGJyPg0KPGI+VG86PC9iPiBCcmlh biBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBN ZWV0aW5nIEludml0ZSBmb3IgdGhlIE9BdXRoIFdHIFZpcnR1YWwgT2ZmaWNlIEhvdXJzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SaWZhYXQgd2FzIG9uIHRoZSBjYWxsIGZvciAz MG1pbnMgYnV0IG5vYm9keSBqb2luZWQuIEkgY291bGRu4oCZdCBtYWtlIGl0IGR1ZSB0byBhIGRl bGF5ZWQgZmxpZ2h0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldyaXRlLXVwcyBhcmUgaW4gcHJvZ3Jlc3MuICZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5DaWFvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IYW5u ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+IEJyaWFuIENhbXBiZWxsIFs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb20iPm1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gMTggSnVuZSAyMDE4IDE4OjQ3PGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9m ZW5pZzxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+ b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdH XSBNZWV0aW5nIEludml0ZSBmb3IgdGhlIE9BdXRoIFdHIFZpcnR1YWwgT2ZmaWNlIEhvdXJzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgdHJpZWQgdG8gam9pbiB0aGlzIG1vcm5p bmcgYnV0IHdhcyB0aGUgb25seSBvbmUgb24gdGhlIHdlYmV4IChvZiBjb3Vyc2UsIHVzZXIgZXJy b3IgY291bGQgYmUgaW52b2x2ZWQgb24gbXkgcGFydCkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkkgZGlkbid0IGhhdmUgbXVjaCBzcGVjaWZpYyBm b3IgdGhlIGNhbGwgYnV0IGRpZCB3YW50IHRvIHBvbGl0ZWx5IGFzayB0aGUgQ2hhaXJzIGhvdyB0 aGUgZG9jdW1lbnQgc2hlcGhlcmRpbmcgd2FzIGNvbWluZyBhbG9uZyBmb3INCjxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1pZXRmLW9hdXRoLW10bHMl MkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdDMDg1OTRhMmJk OTg0NDg4ODMyOTgwOGQ1ZDU1ZjYwNjglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2NjQ5NTI3OTg3MTY4NTk0JmFtcDtzZGF0YT1NVFV2JTJCY1dQSlhpbTRW V0FMaXBhUEVMU1V5N0olMkZlWXk4SmRMT0VueEgwbyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1v YXV0aC1tdGxzLzwvYT4gPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii Pk9uIFdlZCwgTWF5IDE2LCAyMDE4IGF0IDExOjM4IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20iIHRhcmdldD0iX2JsYW5r Ij5IYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLUdCIj5IaSBhbGwsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5SaWZhYXQgYW5kIEkgd2ls bCBhZ2FpbiBkaWFsIGludG8gdGhlIFdlYmV4IG5leHQgTW9uZGF5IHRvIGhlYXIgd2hldGhlciBz b21lb25lIG9mIHlvdSBoYXMgYW55dGhpbmcgdG8gZGlzY3Vzcy9yZXBvcnQvc3VnZ2VzdC/igKYu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5DaWFvPGJyPg0KSGFubmVzICZhbXA7IFJpZmFhdDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzDQogdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJG bWFpbG1hbiUyRmxpc3RpbmZvJTJGb2F1dGgmYW1wO2RhdGE9MDIlN0MwMSU3Q3RvbnluYWQlNDBt aWNyb3NvZnQuY29tJTdDMDg1OTRhMmJkOTg0NDg4ODMyOTgwOGQ1ZDU1ZjYwNjglN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjQ5NTI3OTg3MTc4NTk4JmFt cDtzZGF0YT0zV3J2d09IQXFVNmc2Z1FnWWxLUjhsc3VSTmhVckZueWxxVWl4djd6WmtBJTNEJmFt cDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPjxicj4NCjwvc3Bhbj48Yj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNTU1NTU1O2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowaW4iPkNP TkZJREVOVElBTElUWSBOT1RJQ0U6IFRoaXMgZW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVk DQogcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9z dXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiZuYnNwOyBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZSBhbmQgYW55 IGZpbGUgYXR0YWNobWVudHMgZnJvbSB5b3VyIGNvbXB1dGVyLg0KIFRoYW5rIHlvdS48L3NwYW4+ PC9pPjwvYj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SU1QT1JUQU5UIE5P VElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5DQogdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29u LCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN6PR00MB0400ED6896D5EE18EF6BEE8BA6710SN6PR00MB0400namp_-- From nobody Mon Jun 18 23:17:00 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57A01310AB for ; Mon, 18 Jun 2018 23:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=curity-io.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PD4ghR07KTq for ; Mon, 18 Jun 2018 23:16:54 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E27128CF3 for ; Mon, 18 Jun 2018 23:16:53 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id f16-v6so19192061wrm.3 for ; Mon, 18 Jun 2018 23:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=curity-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xVwPnwSlsOHFLCXMA60DlElWWeDMa+NUprjMoVp++lY=; b=Zoct/yrqjo0W0dEOyXlwBDHqLEraECxWDYntszdG1OzYyfx469GUKcwOz8jFl1cHow vmSXLIADIbIKdtLkkhLvxtm5HW35claIT5lwmbz1UBV1Z6kA9jhuwpjY0hgtG40kjwAd tm+x6mon+LqLgGj2YIAngjqVm34o6nm8F3WII8Lf4PfozQcbTCFo3iNrU9lFSXAPfO50 zjkMe1sRLkYfB8rReTXtPj3L7WWHnsD0m6birLEpNwcn7xTYhXn6U8zsXyJGMVsDolJE ImbE+Uf2B5aUBdwSYGnREcTLC4CbUvdoh1UF4Mm9g95CdFgNRuPPryxWPco99IDQ+ejs PYDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xVwPnwSlsOHFLCXMA60DlElWWeDMa+NUprjMoVp++lY=; b=AUyKZgXtr1OYPd1FTRqkU6K/o18t/weQL81VW6ZaGk1oxOhtjQLm83+xrI7ZqbWkt1 NVSL+9B6nG08YXiEkCi5NrTGcIW6SRwvw8LnEYTGkD21u+2on0iaIcOoA/M3ekPSf6hI 8lvdtBuxf9xrwd9obfYCUT07BnmGlhw0CredLkRMtvtik9dC4uAzj41niEuhLVHqc/xd DsgP/p5rNZtZFikxN+0bIfG54PXFmiuOLI63nQcyH/3yXQcBeFk07WGb4MjkKmgc5w9Y lcNgs0LlS29ZBwqlMy563D26XoC5pWpe6p9+kLZN70WlVzb/5fBSu16e7+y4zSNY1pXt HGKA== X-Gm-Message-State: APt69E18m/UKdACufBpAwCP8As8PVD0a7KwFdpSxMisMpM2g7/voGSkl Ct0fmXrUUQOS75ByrvKFqzg12NgZ4O6wcmLrpZMjLvmq X-Google-Smtp-Source: ADUXVKJcQ95cf7e3LNJ0G/YUssa+k1rmv+Q0zRFdQMOnvuUdY9UqL/dQB+dNcb+Rp4/j80qPKN9hEmqC/gYzFyILSdk= X-Received: by 2002:adf:93c6:: with SMTP id 64-v6mr12661100wrp.119.1529389012344; Mon, 18 Jun 2018 23:16:52 -0700 (PDT) MIME-Version: 1.0 References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> In-Reply-To: From: Jacob Ideskog Date: Tue, 19 Jun 2018 08:16:39 +0200 Message-ID: To: David Waite Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000cdf2af056ef8a05c" Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 06:16:58 -0000 --000000000000cdf2af056ef8a05c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This borderlines another problem we've been adressing which is when a client needs to pass on the request to an asyncronous queue. In that case the client can request the AS to "downscope" it's token, and include a signature of the request in the token. (simplified). The dynamic scope approach would help in this case also, i.e. have a dynamic scope "sign:" which lets the client downscope it by adding the actual signature/hash of the request to the token endpoint in a refresh (sign:). Since we then consider sign: to be the downscoped version of sign:, thus allowing the AS to issue this AT. Also, one-off scopes are useful in services like pay per view etc, where you can purchase say a single movie, game etc. Then the dynamic scope can be decided to be issued by the AS rathern than specifically asked for by the client. Example client asks for games: and gets games:world-cup-2018-06-15 etc. So, the scope approach seems like a more general approach for both the authorize endpoint as well as the token endpoint. With that said, it will probably make it hard to narrow down dynamic scopes to single particular usecase. It would mean that 1. If a dynamic scope is requested on the Authorize endpoint it's a consentable request that the user needs to sign 2. If a dynamic scope is requested on the Token endpoint, the AS determines what the end result might be. Seems a bit vague perhaps. For OpenID I still think the signed claims parameters make a more flexible approach, but OpenID isn't always in play. Just my 5-cents /Jacob Ideskog Curity m=C3=A5n 18 juni 2018 kl 21:00 skrev David Waite : > One of the reasons I hear for people wanting parameterized scopes is to > deal with transactions. I=E2=80=99d love to hear thoughts from the group = on if/how > OAuth should be used to authorize a transaction, vs authorize access to > information/actions for a period of time. This approach for instance soun= ds > like it is trying to scope down access to a single resource representing = a > transaction to be performed? > > I also hear people wanting dynamic scopes to support a finer-grained > access control, for instance not =E2=80=98allow moderation of chat rooms= =E2=80=99 but > rather the list of *specific* rooms. There is sometimes a case to be made > that this would be better served as local state in the resource, or as th= e > result of an API call, but there is value in some use cases to represent > this as a finer-grained consent to the user. > > I=E2=80=99ve seen parameterized scopes take the form of colon-deliminated > name:param, as a function name(param), or as a URL > https://nameurl?param=3Dvalue. The latter is recommended sometimes in > specs like opened connect as a way to prevent conflicting vendor extensio= ns. > > In terms of requesting a parameterized scope - I prefer overloading scope > (or perhaps claims when using connect) vs adding a new authorization > request parameter - for one, use of authorization request parameters limi= ts > your grant type options unless you also define them as token request > parameters for the other types. Second, the consent/business logic for > determining which scopes a client get should already be a customization > point for a reusable AS. > > -DW > > > On Jun 18, 2018, at 9:34 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > > > Hi all, > > > > I have been working lately on use cases where OAuth is used to authoriz= e > transactions in the financial sector and electronic signing. What I learn= ed > is there is always the need to pass resource ids (e.g. account numbers) o= r > transaction-specific values (e.g. amount or hash to be signed) to the OAu= th > authorization process to further qualify the scope of the requested acces= s > token. > > > > It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor= =E2=80=9Esign=E2=80=9C, won=E2=80=99t do > the job. For example in case of electronic signing, one must bind the > authorization/access token to a particular document, typically represente= d > by its hash. > > > > I would like to get your feedback on what you consider a good practice > to cope with that challenge. As a starting point for a discussion, I have > assembled a list of patterns I have seen in the wild (feel free to extend= ). > > > > (1) Parameter is part of the scope value, e.g. > =E2=80=9Esign:=E2=80=9C or "payments:" - I think > this is an obvious way to represent such parameters in OAuth, as it exten= ds > the scope parameter, which is intended to represent the requested scope o= f > an access token. I used this pattern in the OAuth SCA mode in Berlin > Group's PSD API. > > > > (2) One could also use additional query parameter to add further detail= s > re the requested authorization, e.g. > > > > GET /authorize? > > .... > > &scope=3Dsign > > .... > > &hash_to_be_signed=3D > > > > It seems to be robust (easier to implement?) but means the scope only > represents the static part of the action. The AS needs to look into a > further parameter to fully understand the requested authorization. > > > > (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80= =9C parameter to > carry additional data. > > > > Example: > > > > "claims": { > > "id_token": { > > "acr": { > > "essential": true, > > "value": "..." > > }, > > "hash_to_be_signed": { > > "essential": true, > > "value": "" > > } > > }, > > "userinfo": { > > "hash_to_be_signed": { > > "essential": true, > > "value": "" > > } > > } > > } > > > > I=E2=80=98m looking forward for your feedback. Please also indicated wh= ether you > think we should flush out a BCP on that topic. > > > > kind 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 > --=20 --- Jacob Ideskog Curity AB M: +46(0)70 22 33 664 E: jacob.ideskog@curity.io W: curity.io *Curity AB is the leading supplier of API-driven identity management, providing unified security for digital services. Curity Identity Server is the world=E2=80=99s most powerful OAuth and OpenID Conne= ct Server; it is used for logging in and securing millions of users=E2=80=99 a= ccess to web and mobile apps over APIs and microservices. We enjoy the trust of large organizations in financial services, telecom, retail, energy and government services with operations across many countries which have chosen Curity for their enterprise-grade API security needs. * *More information about us can be found at: https://curity.io * --000000000000cdf2af056ef8a05c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This borderlines another problem we've been adres= sing which is when a client needs to pass on the request to an asyncronous = queue. In that case the client can request the AS to "downscope" = it's token, and include a signature of the request in the token. (simpl= ified).

The dynamic scope approach would help in t= his case also, i.e. have a dynamic scope "sign:" which lets the c= lient downscope it by adding the actual signature/hash of the request to th= e token endpoint in a refresh (sign:<hash>). Since we then consider s= ign:<hash> to be the downscoped version of sign:, thus allowing the A= S to issue this AT.

Also, one-off scopes are usefu= l in services like pay per view etc, where you can purchase say a single mo= vie, game etc. Then the dynamic scope can be decided to be issued by the AS= rathern than specifically asked for by the client. Example client asks for= games: and gets games:world-cup-2018-06-15 etc.

So, the scope approach seems like a more general approach for both the a= uthorize endpoint as well as the token endpoint. With that said, it will pr= obably make it hard to narrow down dynamic scopes to single particular usec= ase. It would mean that

1. If a dynamic scope= is requested on=C2=A0 the Authorize endpoint it's a consentable reques= t that the user needs to sign
2. If a dynamic scope is requested = on the Token endpoint, the AS determines what the end result might be. Seem= s a bit vague perhaps.

For OpenID I still thin= k the signed claims parameters make a more flexible approach, but OpenID is= n't always in play.

Just my 5-cents
<= div>
/Jacob Ideskog
Curity

=
m=C3=A5n 18 juni 2018= kl 21:00 skrev David Waite <david@alkaline-solutions.com>:
One of the reasons I hear for people wanting parameterized scopes i= s to deal with transactions. I=E2=80=99d love to hear thoughts from the gro= up on if/how OAuth should be used to authorize a transaction, vs authorize = access to information/actions for a period of time. This approach for insta= nce sounds like it is trying to scope down access to a single resource repr= esenting a transaction to be performed?

I also hear people wanting dynamic scopes to support a finer-grained access= control, for instance not =E2=80=98allow moderation of chat rooms=E2=80=99= but rather the list of *specific* rooms. There is sometimes a case to be m= ade that this would be better served as local state in the resource, or as = the result of an API call, but there is value in some use cases to represen= t this as a finer-grained consent to the user.

I=E2=80=99ve seen parameterized scopes take the form of colon-deliminated n= ame:param, as a function name(param), or as a URL https://nameurl?param= =3Dvalue.=C2=A0 The latter is recommended sometimes in specs like opene= d connect as a way to prevent conflicting vendor extensions.

In terms of requesting a parameterized scope - I prefer overloading scope (= or perhaps claims when using connect) vs adding a new authorization request= parameter - for one, use of authorization request parameters limits your g= rant type options unless you also define them as token request parameters f= or the other types. Second, the consent/business logic for determining whic= h scopes a client get should already be a customization point for a reusabl= e AS.

-DW

> On Jun 18, 2018, at 9:34 AM, Torsten Lodderstedt <torsten@lodderstedt.net>= wrote:
>
> Hi all,
>
> I have been working lately on use cases where OAuth is used to authori= ze transactions in the financial sector and electronic signing. What I lear= ned is there is always the need to pass resource ids (e.g. account numbers)= or transaction-specific values (e.g. amount or hash to be signed) to the O= Auth authorization process to further qualify the scope of the requested ac= cess token.
>
> It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Co= r =E2=80=9Esign=E2=80=9C, won=E2=80=99t do the job. For example in case of = electronic signing, one must bind the authorization/access token to a parti= cular document, typically represented by its hash.
>
> I would like to get your feedback on what you consider a good practice= to cope with that challenge. As a starting point for a discussion, I have = assembled a list of patterns I have seen in the wild (feel free to extend).=
>
> (1) Parameter is part of the scope value, e.g. =E2=80=9Esign:<hash_= to_be_signed>=E2=80=9C or "payments:<payment_resource_id>&quo= t; - I think this is an obvious way to represent such parameters in OAuth, = as it extends the scope parameter, which is intended to represent the reque= sted scope of an access token. I used this pattern in the OAuth SCA mode in= Berlin Group's PSD API.
>
> (2) One could also use additional query parameter to add further detai= ls re the requested authorization, e.g.
>
> GET /authorize?
> ....
> &scope=3Dsign
> ....
> &hash_to_be_signed=3D<hash_to_be_signed>
>
> It seems to be robust (easier to implement?) but means the scope only = represents the static part of the action. The AS needs to look into a furth= er parameter to fully understand the requested authorization.
>
> (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2= =80=9C parameter to carry additional data.
>
> Example:=C2=A0
>
> "claims": {
>=C2=A0 =C2=A0 "id_token": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "acr": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "essential": true,<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "...&= quot;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "hash_to_be_signed": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "essential": true,<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "<= hash_to_be_signed>"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 },
>=C2=A0 =C2=A0 "userinfo": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "hash_to_be_signed": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "essential": true,<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "<= hash_to_be_signed>"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>=C2=A0 }
>
> I=E2=80=98m looking forward for your feedback. Please also indicated w= hether you think we should flush out a BCP on that topic.
>
> kind 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
--
---
Jacob Ideskog
Curity AB

M: +46(0= )70 22 33 664
E: jacob.idesko= g@curity.io
W:=C2=A0curity.io=C2=A0=C2=A0
=C2=A0 =C2=A0=C2= =A0
Curity AB is the leading supplier of API-driven identity manageme= nt,=C2=A0providing unified security for digital=C2=A0services.=C2=A0Curity Identity Server is the world=E2=80=99s most powerful OAuth and OpenID Conn= ect=20 Server; it is used for logging in and securing millions of users=E2=80=99 a= ccess to web and mobile apps over APIs and microservices. We enjoy the trust=20 of large organizations in financial services, telecom, retail, energy=20 and government services with operations across many countries which have chosen Curity for their enterprise-grade API security needs.=C2=A0
More=C2=A0information about us can be found=C2=A0at:= =C2=A0https://curity.io
--000000000000cdf2af056ef8a05c-- From nobody Tue Jun 19 06:01:40 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8425F130EA5 for ; Tue, 19 Jun 2018 06:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOPBRbTdWBVl for ; Tue, 19 Jun 2018 06:01:33 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DF9130EF8 for ; Tue, 19 Jun 2018 05:53:36 -0700 (PDT) Received: from [80.155.34.3] (helo=[10.3.12.195]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fVG8c-0000QU-AX; Tue, 19 Jun 2018 14:53:34 +0200 From: Torsten Lodderstedt Message-Id: <2F1E9439-DD6D-478E-964A-A7272D5BFBF5@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_D47C4473-CB07-4816-B998-75CC48F2A798"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Tue, 19 Jun 2018 14:53:31 +0200 In-Reply-To: Cc: David Waite , oauth To: Jacob Ideskog References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> X-Mailer: Apple Mail (2.3445.8.2) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 13:01:39 -0000 --Apple-Mail=_D47C4473-CB07-4816-B998-75CC48F2A798 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jacob, thanks for your thoughts on dynamic scopes.=20 > Am 19.06.2018 um 08:16 schrieb Jacob Ideskog = : >=20 > For OpenID I still think the signed claims parameters make a more = flexible approach, but OpenID isn't always in play. Why do you think it is more flexible?=20 kind regards, Torsten.=20 --Apple-Mail=_D47C4473-CB07-4816-B998-75CC48F2A798 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNjE5MTI1MzMyWjAjBgkqhkiG9w0BCQQxFgQU0VVXR5U3nfrt d4U92LZZVD8y6LAwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBACQnTYpH7M9X58uaaAGG7ZtsrEAH0SIpRpFNZZzeX7ENpee9SpTg SxY7jsa8i8uKyv0dEzAzGhmxvQO/e/SrhurjqSR7/rzjmYrNr6e4R31/Ki+Av0xMADthadkMdW6h nZ39uw46K8LrHRASDUzmxfdFVm7Zk08xVWVYUzNMmxTYQMTDYOGwo8Ir8I89Bq1ZgCYIPaj0PHUj FJ+3x/KvtsxBbfLO4MJCIA0KruKR0AhdNxNhT2shisbUs6BYA0j/TiS/nKFdP89vBa/zIEWRVi5a 05UcHQPNvpCXosiZevd8DbJZdiaJAWPCSb1HuOKkLSbAxPhrwWOMXocavaugHxAAAAAAAAA= --Apple-Mail=_D47C4473-CB07-4816-B998-75CC48F2A798-- From nobody Wed Jun 20 14:58:42 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165C6130EC4 for ; Wed, 20 Jun 2018 14:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFOt4xxpG9bg for ; Wed, 20 Jun 2018 14:58:37 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27557130EBF for ; Wed, 20 Jun 2018 14:58:37 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id l25-v6so1120534ioh.12 for ; Wed, 20 Jun 2018 14:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2+RPUhPRKgcxiueeL7YkfGkg7vel4NjBdZZL198pJWY=; b=oMcAmjjkqa4kE8QQ/gMkaDD/63BPVcYK5555fQ2SUkkig5gB6MFVUFe3sW+j1R5dZ+ ZS4m7Y73n7L8ypXQrEbW9F64HzeT6LPWerSbhvjAa1ssZ+UVpONcMIl5DlmU8/IOgjgB 8seUQ3FhTun4VUs4ys2X1D71YC/ZAG3UaoEDQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2+RPUhPRKgcxiueeL7YkfGkg7vel4NjBdZZL198pJWY=; b=HTtasgQEIOF/l95gjX/+AyKs/ikB8SYj6B0H2QZQQJWJ/O9Om7QtjYvo28zhhYCIdo 7vxuHnYELmX+bx6QW2c5uHJcBivSdzYf8gv8JZ1fEAcq/JzrmfdwYioa4HNGsczwFl1R D0habCF5ByiJGapkHAqPXN7Ig//PdqRkwphyEzfLE4X9YKZ5ncoQ0O3a0hXz4pEhyGqz Zkt3NxHik0p0uUeYV9zMZV0FeLsXEjrmf0SUCM0VSsZ2sdZwZoQjhrnuueBiCfxM4yfk BIaZRj2/EGK9fgIeVkhn4y52NRPbYkB2sqV/r+cxUICnquZZM98/sv0GeUza6MVrTIGg ZSRw== X-Gm-Message-State: APt69E0d1UpqfKS25GfDUCcwcaEmABRvp1kGFotFNqJou655GqRhxDvp x4jLmLNZvWOfeaeR4kFFsrVJlODNdzdMKyTQ8c6oo1ORYlCrGxmFwUTNPiozM+ilFoefIurU+rq qY5zBNB5Cizt5oA1z X-Google-Smtp-Source: ADUXVKKQ7g1vdwfh66Bg741SgM6Wivj93WWf85ZgRJRB8FiHpUG402Llz+LyPU0G7DAXPNHO1fXr63Pr+r5o5Au/evM= X-Received: by 2002:a6b:284b:: with SMTP id o72-v6mr18461159ioo.168.1529531916209; Wed, 20 Jun 2018 14:58:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:9785:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 14:58:05 -0700 (PDT) In-Reply-To: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> From: Brian Campbell Date: Wed, 20 Jun 2018 15:58:05 -0600 Message-ID: To: Torsten Lodderstedt Cc: oauth Content-Type: multipart/alternative; boundary="0000000000008a0eb3056f19e6e6" Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 21:58:40 -0000 --0000000000008a0eb3056f19e6e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my own personal and humble opinion, Torsten, what you describe as "(1) Parameter is part of the scope value" is the most natural approach and works without needing changes to, or going outside of, RFC6749 The OAuth 2.0 Authorization Framework. There may be AS implementations that have made assumption about scope values being static (I know of at least one!) but that's an implementation/feature issue, which can change, and not a spec issue. The OIDC "claims" parameter is already a bit of a hairy beast and I think using it and the ID Token to convey more dynamic access/authorization is blurring the line between authorization and authentication a bit much. Also, as others have pointed out, OIDC isn't always in play - particularly for regular old authorization cases. An additional query parameter might be simple for a one-off case but it's nonstandard and not very repeatable. On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Hi all, > > I have been working lately on use cases where OAuth is used to authorize > transactions in the financial sector and electronic signing. What I learn= ed > is there is always the need to pass resource ids (e.g. account numbers) o= r > transaction-specific values (e.g. amount or hash to be signed) to the OAu= th > authorization process to further qualify the scope of the requested acces= s > token. > > It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor = =E2=80=9Esign=E2=80=9C, won=E2=80=99t do > the job. For example in case of electronic signing, one must bind the > authorization/access token to a particular document, typically represente= d > by its hash. > > I would like to get your feedback on what you consider a good practice to > cope with that challenge. As a starting point for a discussion, I have > assembled a list of patterns I have seen in the wild (feel free to extend= ). > > (1) Parameter is part of the scope value, e.g. =E2=80=9Esign:=E2=80=9C > or "payments:" - I think this is an obvious way to > represent such parameters in OAuth, as it extends the scope parameter, > which is intended to represent the requested scope of an access token. I > used this pattern in the OAuth SCA mode in Berlin Group's PSD API. > > (2) One could also use additional query parameter to add further details > re the requested authorization, e.g. > > GET /authorize? > .... > &scope=3Dsign > .... > &hash_to_be_signed=3D > > It seems to be robust (easier to implement?) but means the scope only > represents the static part of the action. The AS needs to look into a > further parameter to fully understand the requested authorization. > > (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80= =9C parameter to > carry additional data. > > Example: > > "claims": { > "id_token": { > "acr": { > "essential": true, > "value": "..." > }, > "hash_to_be_signed": { > "essential": true, > "value": "" > } > }, > "userinfo": { > "hash_to_be_signed": { > "essential": true, > "value": "" > } > } > } > > I=E2=80=98m looking forward for your feedback. Please also indicated whet= her you > think we should flush out a BCP on that topic. > > kind regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --0000000000008a0eb3056f19e6e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my own=C2=A0personal and=C2=A0humble opinion, Tors= ten, what you describe as "(1) Parameter is part of the scope value&qu= ot; is the most natural approach and works without needing changes to, or g= oing outside of, RFC6749 The OAuth 2.0 Authorization Framework. There may b= e AS implementations that have made assumption about scope values being sta= tic (I know of at least one!) but that's an implementation/feature issu= e, which can change, and not a spec issue.

The OID= C "claims" parameter is already a bit of a hairy beast and I thin= k using it and the ID Token to convey more dynamic access/authorization is = blurring the line between authorization and authentication a bit much. Also= , as others have pointed out, OIDC isn't always in play - particularly = for regular old authorization cases.=C2=A0

An addi= tional query parameter might be simple for a one-off case but it's nons= tandard and not very repeatable.


On Mon, Jun 18, 2018 at 9:34 AM, T= orsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

I have been working lately on use cases where OAuth is used to authorize tr= ansactions in the financial sector and electronic signing. What I learned i= s there is always the need to pass resource ids (e.g. account numbers) or t= ransaction-specific values (e.g. amount or hash to be signed) to the OAuth = authorization process to further qualify the scope of the requested access = token.

It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor =E2= =80=9Esign=E2=80=9C, won=E2=80=99t do the job. For example in case of elect= ronic signing, one must bind the authorization/access token to a particular= document, typically represented by its hash.

I would like to get your feedback on what you consider a good practice to c= ope with that challenge. As a starting point for a discussion, I have assem= bled a list of patterns I have seen in the wild (feel free to extend).

(1) Parameter is part of the scope value, e.g. =E2=80=9Esign:<hash_to_be= _signed>=E2=80=9C or "payments:<payment_resource_id>&quo= t; - I think this is an obvious way to represent such parameters in OAuth, = as it extends the scope parameter, which is intended to represent the reque= sted scope of an access token. I used this pattern in the OAuth SCA mode in= Berlin Group's PSD API.

(2) One could also use additional query parameter to add further details re= the requested authorization, e.g.

GET /authorize?
....
&scope=3Dsign
....
&hash_to_be_signed=3D<hash_to_be_signed>

It seems to be robust (easier to implement?) but means the scope only repre= sents the static part of the action. The AS needs to look into a further pa= rameter to fully understand the requested authorization.

(3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80=9C = parameter to carry additional data.

Example:=C2=A0

"claims": {
=C2=A0 =C2=A0 "id_token": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "acr": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "essential": true,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "..."= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "hash_to_be_signed": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "essential": true,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "<hash= _to_be_signed>"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "userinfo": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "hash_to_be_signed": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "essential": true,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "<hash= _to_be_signed>"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }

I=E2=80=98m looking forward for your feedback. Please also indicated whethe= r you think we should flush out a BCP on that topic.

kind regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --0000000000008a0eb3056f19e6e6-- From nobody Thu Jun 21 01:35:48 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943A4130DC1 for ; Thu, 21 Jun 2018 01:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX5ZYPPrxCr6 for ; Thu, 21 Jun 2018 01:35:44 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A064128CF3 for ; Thu, 21 Jun 2018 01:35:43 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id w10-v6so2214111wrk.9 for ; Thu, 21 Jun 2018 01:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5mMHVoCb9/7elHQNQLiRzBlPbv4LntQo5eQfLiV+k6I=; b=iF1Ds+W1MyfL3JLy0CR56vFRf/GnlddLUdlR7YI5oE9tEpUvE3st7q/r1SLeiXBaGb TdusRAn7Xo7UmHhP8gv+3oKIgcDFs9UPmfyWGxZxU80//w4TVzrfuo1jlcrFDDKWvEfp j/h8Df/21D+ksDjQBr0oTjL3IRGHHMtQhVh/yEcqjWzzN/HhO1Yy1L8aeS84HwzP02o6 OSWFwH+RpPnLL2kYF0rQLVzQU/FH8qp/Zq5Cgig0KmID1M1lGwZshqhM7K+UAA0uTR6W 77/634dDQYe7Z8GNgA43eLxNfyjTrSzKZExP4CLM1HiGNicrThIqydI8KgoHb1WJi+pr aA0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5mMHVoCb9/7elHQNQLiRzBlPbv4LntQo5eQfLiV+k6I=; b=BreNoCgV1Zx5OylHNqgondCQx6RSgAOlOC1FvGZhQKk9wmW38iYdkgUHqjcPdJrKlZ Z74fzPwGtCNTKpDRTaPTfJ/agMEDyp9JAwjxKxbrq4E1m3Yi37BOrTl2h9exVA73YyvE emNi6OoWcPoconK9S4BZFhX8hwPNvZJLxIMp22+yEbrkePlDA+YY6ZgIk52mw3mHDvPM lxI5vjvAYN8eX7uxz85TxnFG8OcO2PGOAJjrPOof1ERJZ0IDk+i27FY8MJAdstT3iZgY ey/lMP+geYsYTlkS4uap6DWwrAOxS2OilBrVhzZTmD4ittuaEX21KpcwG1ksD7wxzlVb fNtQ== X-Gm-Message-State: APt69E3xBqmaz50UJjvItybBZwlWuzOoSsH6yIlUq5ltD1q4voNFTvJk JtD/lcXJKL0UlcrBX6R3544B06bDlymaFkeXJSI= X-Google-Smtp-Source: ADUXVKLCK36cq3wH3PTVKZHmcLWulwaiclZV0PV/CMBgcbODkcWqQ9D8L2tuc4OTTCnTM8BCF5RCDimvNmxGBGDDTq4= X-Received: by 2002:adf:edc6:: with SMTP id v6-v6mr20085576wro.264.1529570141771; Thu, 21 Jun 2018 01:35:41 -0700 (PDT) MIME-Version: 1.0 References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> In-Reply-To: From: Nat Sakimura Date: Thu, 21 Jun 2018 17:35:29 +0900 Message-ID: To: Brian Campbell Cc: Torsten Lodderstedt , oauth Content-Type: multipart/alternative; boundary="000000000000f59d9e056f22cccf" Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 08:35:47 -0000 --000000000000f59d9e056f22cccf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It depends on the use case but if you are talking about payment etc., putting the transaction details in the scope and sending it over the regular RFC6749 redirect to the authorization server is inherently a bad idea, as it is not protected. My preference by far is to set up a staging endpoint and push the transaction intent into there. Then, do the authorization on that staged transaction. Once that's done. I am OK with putting the reference to the staged transaction in the scope parameter. The beauty of the "staging" strategy is that: 1) You can push pretty big payload to the staging endpoint as it is a server to server thing; 2) You can do the "auth" and then later "capture" after shipping the product strategy using the access token the client has obtained; 3) The content of the transaction is not exposed via URL nor referrers. Best, Nat On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell wrote: > In my own personal and humble opinion, Torsten, what you describe as "(1) > Parameter is part of the scope value" is the most natural approach and > works without needing changes to, or going outside of, RFC6749 The OAuth > 2.0 Authorization Framework. There may be AS implementations that have ma= de > assumption about scope values being static (I know of at least one!) but > that's an implementation/feature issue, which can change, and not a spec > issue. > > The OIDC "claims" parameter is already a bit of a hairy beast and I think > using it and the ID Token to convey more dynamic access/authorization is > blurring the line between authorization and authentication a bit much. > Also, as others have pointed out, OIDC isn't always in play - particularl= y > for regular old authorization cases. > > An additional query parameter might be simple for a one-off case but it's > nonstandard and not very repeatable. > > > On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> Hi all, >> >> I have been working lately on use cases where OAuth is used to authorize >> transactions in the financial sector and electronic signing. What I lear= ned >> is there is always the need to pass resource ids (e.g. account numbers) = or >> transaction-specific values (e.g. amount or hash to be signed) to the OA= uth >> authorization process to further qualify the scope of the requested acce= ss >> token. >> >> It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor = =E2=80=9Esign=E2=80=9C, won=E2=80=99t do >> the job. For example in case of electronic signing, one must bind the >> authorization/access token to a particular document, typically represent= ed >> by its hash. >> >> I would like to get your feedback on what you consider a good practice t= o >> cope with that challenge. As a starting point for a discussion, I have >> assembled a list of patterns I have seen in the wild (feel free to exten= d). >> >> (1) Parameter is part of the scope value, e.g. =E2=80=9Esign:=E2=80=9C >> or "payments:" - I think this is an obvious way to >> represent such parameters in OAuth, as it extends the scope parameter, >> which is intended to represent the requested scope of an access token. I >> used this pattern in the OAuth SCA mode in Berlin Group's PSD API. >> >> (2) One could also use additional query parameter to add further details >> re the requested authorization, e.g. >> >> GET /authorize? >> > ..... >> &scope=3Dsign >> ..... > > >> &hash_to_be_signed=3D >> >> It seems to be robust (easier to implement?) but means the scope only >> represents the static part of the action. The AS needs to look into a >> further parameter to fully understand the requested authorization. >> >> (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80= =9C parameter to >> carry additional data. >> >> Example: >> >> "claims": { >> "id_token": { >> "acr": { >> "essential": true, >> "value": "..." >> }, >> "hash_to_be_signed": { >> "essential": true, >> "value": "" >> } >> }, >> "userinfo": { >> "hash_to_be_signed": { >> "essential": true, >> "value": "" >> } >> } >> } >> >> I=E2=80=98m looking forward for your feedback. Please also indicated whe= ther you >> think we should flush out a BCP on that topic. >> >> kind regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you.*_______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation --000000000000f59d9e056f22cccf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It depends on the use case but if you are talking about pa= yment etc., putting the transaction details in the scope and sending it ove= r the regular RFC6749 redirect to the authorization server is inherently a = bad idea, as it is not protected.=C2=A0

My preference by far i= s to set up a staging endpoint and push the transaction intent into there. = Then, do the authorization on that staged transaction. Once that's done= .=C2=A0I am OK with putting the reference to the staged transaction in the = scope parameter.=C2=A0

The beauty of the &qu= ot;staging" strategy is that:=C2=A0

1) You ca= n push pretty big payload to the staging endpoint as it is a server to serv= er thing;=C2=A0
2) You can do the "auth" and then later= "capture" after shipping the product strategy using the access t= oken the client has obtained;=C2=A0
3) The content of the transac= tion is not exposed via URL nor referrers.=C2=A0

B= est,=C2=A0

Nat


=

On Thu, Jun 21, 2018 = at 6:59 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf.org> wrote:
In my own=C2=A0pers= onal and=C2=A0humble opinion, Torsten, what you describe as "(1) Param= eter is part of the scope value" is the most natural approach and work= s without needing changes to, or going outside of, RFC6749 The OAuth 2.0 Au= thorization Framework. There may be AS implementations that have made assum= ption about scope values being static (I know of at least one!) but that= 9;s an implementation/feature issue, which can change, and not a spec issue= .

The OIDC "claims" parameter is already= a bit of a hairy beast and I think using it and the ID Token to convey mor= e dynamic access/authorization is blurring the line between authorization a= nd authentication a bit much. Also, as others have pointed out, OIDC isn= 9;t always in play - particularly for regular old authorization cases.=C2= =A0

An additional query parameter might be simple = for a one-off case but it's nonstandard and not very repeatable.


On Mon,= Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt <torsten@lodderstedt.n= et> wrote:
Hi all,

I have been working lately on use cases where OAuth is used to authorize tr= ansactions in the financial sector and electronic signing. What I learned i= s there is always the need to pass resource ids (e.g. account numbers) or t= ransaction-specific values (e.g. amount or hash to be signed) to the OAuth = authorization process to further qualify the scope of the requested access = token.

It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor =E2= =80=9Esign=E2=80=9C, won=E2=80=99t do the job. For example in case of elect= ronic signing, one must bind the authorization/access token to a particular= document, typically represented by its hash.

I would like to get your feedback on what you consider a good practice to c= ope with that challenge. As a starting point for a discussion, I have assem= bled a list of patterns I have seen in the wild (feel free to extend).

(1) Parameter is part of the scope value, e.g. =E2=80=9Esign:<hash_to_be= _signed>=E2=80=9C or "payments:<payment_resource_id>" - = I think this is an obvious way to represent such parameters in OAuth, as it= extends the scope parameter, which is intended to represent the requested = scope of an access token. I used this pattern in the OAuth SCA mode in Berl= in Group's PSD API.

(2) One could also use additional query parameter to add further details re= the requested authorization, e.g.

GET /authorize?
.....
&scope=3Dsign
.....

&hash_to_be_signed=3D<hash_to_be_signed>

It seems to be robust (easier to implement?) but means the scope only repre= sents the static part of the action. The AS needs to look into a further pa= rameter to fully understand the requested authorization.

(3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80=9C = parameter to carry additional data.

Example:=C2=A0

"claims": {
=C2=A0 =C2=A0 "id_token": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "acr": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "essential": true,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "..."= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 },
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "hash_to_be_signed": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "essential": true,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "<hash= _to_be_signed>"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 "userinfo": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "hash_to_be_signed": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "essential": true,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "value": "<hash= _to_be_signed>"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }

I=E2=80=98m looking forward for your feedback. Please also indicated whethe= r you think we should flush out a BCP on that topic.

kind regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= ..=C2=A0 If you have received this communication in error, please notify th= e sender immediately by e-mail and delete the message and any file attachme= nts from your computer. Thank you._______________________= ________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--000000000000f59d9e056f22cccf-- From nobody Thu Jun 21 08:11:57 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17B8131234 for ; Thu, 21 Jun 2018 08:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVcwaS20BT8H for ; Thu, 21 Jun 2018 08:11:46 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on060d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::60d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1895D131258 for ; Thu, 21 Jun 2018 08:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BnbbugE4Kxx0YJrRgrWjq0kH7VXynqK9P2G9qUGSfkw=; b=qV9GaE6QuhACYQLf4lATx7aS0mOsdDdQJBCWufN9ie2fTjMUfIJKsUvlYdDyeq1zQ7TUmLNMsim3ieDOF9TcOfbz4f/E5XXZd6xOwPdGe4/ePvs8mFjgPb8ALvZkZfqOWzKhz6Iz281xj4czlXz0hxN9QGgyGeRtl2NxoF8yXoE= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1840.eurprd08.prod.outlook.com (10.168.68.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.16; Thu, 21 Jun 2018 15:11:43 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 15:11:43 +0000 From: Hannes Tschofenig To: "oauth@ietf.org" CC: Laurence Lundblade Thread-Topic: Standardizing Attestation Tokens Thread-Index: AdQJcgYcjI8QIQCVT++3DyjB6i8mjQ== Date: Thu, 21 Jun 2018 15:11:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [217.140.96.140] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1840; 7:NEH9lGcMJCdalmYEd4EZQoepoEQ8lqAwPaeKP94EUH8QeXJSaf89XwUpIgb80EZxSXW71j834hVfI8yhycJNtj5CsNcx/9CeBi7YPrhjwOYsNbfab6uZrco8kUZLaH+6wk8mtLRoX/HOyDE79U4D7l+5cyunCXoihySE9UAt/OBro5uMNnwoUtzrbc2CPi1oiJHAgGDQ5YxiY3ZqD4ysC+WfFZjcVUIFqEZwp7kGLXC3FpiGM2XtqLO+bt+iGzy3 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 685115d0-cfaa-401e-d1a5-08d5d7894c82 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1840; x-ms-traffictypediagnostic: VI1PR0801MB1840: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1840; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1840; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(376002)(39380400002)(366004)(39860400002)(199004)(189003)(40434004)(53754006)(105586002)(5660300001)(72206003)(6116002)(7736002)(8676002)(1730700003)(81156014)(81166006)(68736007)(3846002)(5630700001)(4326008)(66066001)(25786009)(966005)(790700001)(74316002)(5640700003)(106356001)(6436002)(3480700004)(7116003)(8936002)(5890100001)(2501003)(55016002)(6916009)(3660700001)(99286004)(476003)(33656002)(3280700002)(54896002)(6306002)(186003)(316002)(86362001)(2351001)(2906002)(26005)(6506007)(9686003)(53936002)(2900100001)(97736004)(478600001)(14454004)(5250100002)(7696005)(59450400001)(486006)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1840; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: E5F/xY24RAm4Cku4rUnDLPt8baXawSFAGJ4MbH5HbDZG3PCrK5v7JqK+UHZAYjT1D7MSn3v9e8Xl8QvZHczATdAiX4kAsp3lM9B38XihD38UeDtBoyu+MjlKpaF+D9+l9rn4Zgc8HPvrvXM8XslLZ8tjoAfjqdTL+wiupqgzmS1ik426IgEIfic7nlZrh08OKMk5X6PB2ROgXLUZQFkfWZU+KswQ75C9kzEirqDwszqbvnvSmQy1yz8915nLQsTdpOy5LjvGBTs9ExSpUJbt6uavcE5/u/OGis0pvE3MbuHCv02CxpKOQWd34VW8dPuLqLcTzKczwd0PJf/4UUxLqw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB211257AF7644A444E43DAE7BFA760VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 685115d0-cfaa-401e-d1a5-08d5d7894c82 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 15:11:43.5555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1840 Archived-At: Subject: [OAUTH-WG] Standardizing Attestation Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 15:11:55 -0000 --_000_VI1PR0801MB211257AF7644A444E43DAE7BFA760VI1PR0801MB2112_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I would like to make you aware of work that will be discussed on attestatio= n on the EAT mailing list. Here is the link to the list: https://www.ietf.org/mailman/listinfo/eat Here is a document describing the idea: https://tools.ietf.org/html/draft-mandyam-eat-00 The work is relevant for IoT and non-IoT devices. Laurence and I are planning to organize a Bar BOF at the Montreal IETF meet= ing to entertain the idea. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR0801MB211257AF7644A444E43DAE7BFA760VI1PR0801MB2112_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I would like to make you aware of work that will be = discussed on attestation on the EAT mailing list. Here is the link to the l= ist:

https://www.ietf.org/mailman/listinfo/eat=

 

Here is a document describing the idea: <= /p>

https://tools.ietf.org/html/draft-mandyam-eat-00

 

The work is relevant for IoT and non-IoT devices.

 

Laurence and I are planning to organize a Bar BOF at= the Montreal IETF meeting to entertain the idea.

 

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR0801MB211257AF7644A444E43DAE7BFA760VI1PR0801MB2112_-- From nobody Thu Jun 21 12:17:23 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8721130DCD; Thu, 21 Jun 2018 12:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdkY9ayb2G3a; Thu, 21 Jun 2018 12:17:18 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B36E130DE0; Thu, 21 Jun 2018 12:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8150; q=dns/txt; s=iport; t=1529608638; x=1530818238; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=+MVev5ZVPc2dRq9wHpkJkQ7RLDZm6inyoKHlF3CmBUw=; b=dWBLc6AeNjUtznpAYaua6N2ls0NijGBy0saJTIoNtf79odX06tk4U+c8 oHhmUAZrbWI78kSn6W2oiwSPZriFgaxtgzbOMq7YCC3UF1pjXOmD5SmRu njBBMlQuW9KlJaot19xmdF7llScCgQ70ZpYFTpXVyy21V/RvTbNv8eEUx A=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQBV+Ctb/xbLJq1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTTIEMfyiDeYhjjWaPfYUXgWUIAxgBCoRJAoMcNxUBAgE?= =?us-ascii?q?BAQEBAQJtHAyFKQEBAQMBASEKQQIJEAsYKgICJzAGAQwGAgEBgyEBgX8Pqxa?= =?us-ascii?q?CHB+IJ14KBYdKgx0lgRGCaIMYAQEDgSoBEgFLglWCVQKHPpFoCYNTgVhShVS?= =?us-ascii?q?DOQaBPx2DZIJGhTuKHYdDgVciYXEzGggbFTEKBXodgSIpgzIBAodchUA9MI1?= =?us-ascii?q?zgjkBAQ?= X-IronPort-AV: E=Sophos;i="5.51,253,1526342400"; d="asc'?scan'208,217";a="4704534" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 19:17:16 +0000 Received: from [10.61.219.105] ([10.61.219.105]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w5LJHFYS015611; Thu, 21 Jun 2018 19:17:15 GMT To: Hannes Tschofenig , "oauth@ietf.org" Cc: Laurence Lundblade , eat@ietf.org References: From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Thu, 21 Jun 2018 21:17:07 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gfJaqOhudPIMAs8KUwBGcfziTeAYIDGXV" Archived-At: Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 19:17:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gfJaqOhudPIMAs8KUwBGcfziTeAYIDGXV Content-Type: multipart/mixed; boundary="dUeu2ww7XFLK73F3cKq3ESMBGaDRy9MhX"; protected-headers="v1" From: Eliot Lear To: Hannes Tschofenig , "oauth@ietf.org" Cc: Laurence Lundblade , eat@ietf.org Message-ID: Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens References: In-Reply-To: --dUeu2ww7XFLK73F3cKq3ESMBGaDRy9MhX Content-Type: multipart/alternative; boundary="------------D8206455333DA5BC8B891451" Content-Language: en-US This is a multi-part message in MIME format. --------------D8206455333DA5BC8B891451 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Hannes, The draft is interesting, but it looks a bit like NEA.=C2=A0 How would th= is vary, apart from the CoAP part and a different registry?=C2=A0 Seems to m= e the real magic is how the device is interrogated such that the consumer of this information has confidence as to its validity.=C2=A0 The protocol= bits are the easy part.=C2=A0 If people have some understanding of that m= agic and are willing to share, then this work becomes considerably more interesting. Eliot On 21.06.18 17:11, Hannes Tschofenig wrote: > > Hi all, > > =C2=A0 > > I would like to make you aware of work that will be discussed on > attestation on the EAT mailing list. Here is the link to the list: > > https://www.ietf.org/mailman/listinfo/eat > > =C2=A0 > > Here is a document describing the idea: > > https://tools.ietf.org/html/draft-mandyam-eat-00 > > =C2=A0 > > The work is relevant for IoT and non-IoT devices. > > =C2=A0 > > Laurence and I are planning to organize a Bar BOF at the Montreal IETF > meeting to entertain the idea. > > =C2=A0 > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------D8206455333DA5BC8B891451 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Hannes,

The draft is interesting, but it looks a bit like NEA.=C2=A0 How w= ould this vary, apart from the CoAP part and a different registry?=C2=A0= Seems to me the real magic is how the device is interrogated such that the consumer of this information has confidence as to its validity.=C2=A0 The protocol bits are the easy part.=C2=A0 If peopl= e have some understanding of that magic and are willing to share, then this work becomes considerably more interesting.

Eliot


On 21.06.18 17:11, Hannes Tschofenig wrote:

Hi all,

=C2=A0

I would like to make you aware of work tha= t will be discussed on attestation on the EAT mailing list. Here is the link to the list:

https://www.ietf.org/mailman/= listinfo/eat

=C2=A0

Here is a document describing the idea:

https://tools.ietf.org= /html/draft-mandyam-eat-00

=C2=A0

The work is relevant for IoT and non-IoT devices.

=C2=A0

Laurence and I are planning to organize a Bar BOF at the Montreal IETF meeting to entertain the idea.

=C2=A0

Ciao

Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 

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

--------------D8206455333DA5BC8B891451-- --dUeu2ww7XFLK73F3cKq3ESMBGaDRy9MhX-- --gfJaqOhudPIMAs8KUwBGcfziTeAYIDGXV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlsr+bMACgkQh7ZrRtnS ejMkcggA2/kKfP4/NlNm+mdayP2u2KHYFm+tN/VR5OFLnu6LZ5wBwSBypiyz168h NJK00GXJu74GRZx8aMOgAcPREuzgqEDPXZ2zU0dm7ldisbxCxnrZ/dAeHV9ZOXSy ALpc7qURp6CX1fR6G0dFllmcsXrLNbjZdber1uM9FGpzCkpCdAGsQiipYH8XtiYn mdfByq5/WkCNvnWJqOkojXk9cYjBRcDIR+vc6SD1IEDpIjhfvnfzHVYSBw3UdnYf oKIm4gsar93NcfGf/tEoB3YywO32PvrSTg/8pPQ6esrGZ6ucavProvBa4jEFcy5f w7NTSca309R7jW1C84N2nVfkd5ECMQ== =yqbZ -----END PGP SIGNATURE----- --gfJaqOhudPIMAs8KUwBGcfziTeAYIDGXV-- From nobody Thu Jun 21 13:04:41 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F2312872C; Thu, 21 Jun 2018 13:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq0aPlR-JQ50; Thu, 21 Jun 2018 13:04:36 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0061.outbound.protection.outlook.com [104.47.1.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA6512777C; Thu, 21 Jun 2018 13:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rUwamr4RmqDLhOHJzR/uoy9zax03SaCARKbTgM240R8=; b=aZCMPGaKa13+/Owh3TQII3rLP5wSEmzdjtf/s/qUpVBLHhPDlr7urfS/+03BOUTz6ZKNnh7k7m3sjtZ/IJBbCtJ+4p6H58aGNBIVBeADZkd8ucb2OQxjOuNZbZh1B9NOLmVmKuJADe7V9clpPnvofwQ+al9KS78JJWqelo/n2N0= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1389.eurprd08.prod.outlook.com (10.167.198.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.19; Thu, 21 Jun 2018 20:04:33 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Thu, 21 Jun 2018 20:04:33 +0000 From: Hannes Tschofenig To: Eliot Lear , "oauth@ietf.org" CC: Laurence Lundblade , "eat@ietf.org" Thread-Topic: [OAUTH-WG] Standardizing Attestation Tokens Thread-Index: AdQJcgYcjI8QIQCVT++3DyjB6i8mjQAImu2AAAGhYqA= Date: Thu, 21 Jun 2018 20:04:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [5.148.12.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1389; 7:ipUixDrJ3tRcFed8wc487e6XP/HCp66KUeI4Trt6lCA9x2fCWKYBAHrqao8m/sm6ICwvAoz/79d63SzUtLl3HYk0LRxFI9+ZQnRfrfcgPy2JNPrVgV477s4H6LnpXRHp74KvASRPQ+p3rXldHlsf7n2syH2wf7Z3Jm5mgBT8IxZiBbC+TfPxHdBl6ZT5fS8A66TlByF5ThCs8OrwadZuhWhAqTfY0pt1uPh0wCt297EbT73cw9pzW72wD1ymfXE1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e2474161-5039-47ad-96b7-08d5d7b23501 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1389; x-ms-traffictypediagnostic: VI1PR0801MB1389: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1389; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1389; x-forefront-prvs: 07106EF9B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39380400002)(396003)(39860400002)(376002)(366004)(199004)(189003)(53754006)(40434004)(68736007)(53546011)(2906002)(5890100001)(2501003)(229853002)(7736002)(6506007)(102836004)(106356001)(74316002)(186003)(86362001)(7696005)(486006)(54896002)(6306002)(9686003)(236005)(6436002)(55016002)(3280700002)(33656002)(26005)(59450400001)(476003)(105586002)(76176011)(2900100001)(5250100002)(81166006)(53936002)(81156014)(110136005)(25786009)(316002)(8676002)(71446004)(446003)(6116002)(6246003)(790700001)(3846002)(606006)(99286004)(54906003)(8936002)(72206003)(14454004)(478600001)(4326008)(3660700001)(11346002)(966005)(97736004)(66066001)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1389; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: BXBQUR2VppNIyEnsgzHdh9wcBFnXLFiu5AJEFxEhMmJ57jGHCR63GCcfJ/UD904S7xhBdpDKFhCm2qa1HhhA7L2zHjqp5u5jYdFRKPrQ4QfmVeC9TwGbhdzXm6GvUkj3gV+XousW0v3tlkOKpNt2WUdv/OS3RSmZ5RW9fw6v0zyIKuEmUcCNChRm4I+YGIH6BFyPeKxlRBZ79+9JY0uNvOEY1MDYyF6mkmtOXn3HngjcQl/zI7QyUPvvkmO+byheURNTYP5RKO2HgeQimzKw3FGsLUw5a443kvlTfkTTKp5F0NVsuBKKrIoPRtpAnNLdWYoSpgnvsOJSSY7ECn4vQA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112D2148E29AF0E63603AC0FA760VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2474161-5039-47ad-96b7-08d5d7b23501 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2018 20:04:33.4709 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1389 Archived-At: Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 20:04:41 -0000 --_000_VI1PR0801MB2112D2148E29AF0E63603AC0FA760VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgYSBnb29kIHF1ZXN0aW9uLCBFbGlvdC4gTGV0IG1lIHB1dCBzb21ldGhpbmcgdG9n ZXRoZXIgZm9yIHRoZSBJRVRGIG1lZXRpbmcNCg0KRnJvbTogRWxpb3QgTGVhciBbbWFpbHRvOmxl YXJAY2lzY28uY29tXQ0KU2VudDogMjEgSnVuZSAyMDE4IDIwOjE3DQpUbzogSGFubmVzIFRzY2hv ZmVuaWc7IG9hdXRoQGlldGYub3JnDQpDYzogTGF1cmVuY2UgTHVuZGJsYWRlOyBlYXRAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFN0YW5kYXJkaXppbmcgQXR0ZXN0YXRpb24gVG9r ZW5zDQoNCg0KSGkgSGFubmVzLA0KDQpUaGUgZHJhZnQgaXMgaW50ZXJlc3RpbmcsIGJ1dCBpdCBs b29rcyBhIGJpdCBsaWtlIE5FQS4gIEhvdyB3b3VsZCB0aGlzIHZhcnksIGFwYXJ0IGZyb20gdGhl IENvQVAgcGFydCBhbmQgYSBkaWZmZXJlbnQgcmVnaXN0cnk/ICBTZWVtcyB0byBtZSB0aGUgcmVh bCBtYWdpYyBpcyBob3cgdGhlIGRldmljZSBpcyBpbnRlcnJvZ2F0ZWQgc3VjaCB0aGF0IHRoZSBj b25zdW1lciBvZiB0aGlzIGluZm9ybWF0aW9uIGhhcyBjb25maWRlbmNlIGFzIHRvIGl0cyB2YWxp ZGl0eS4gIFRoZSBwcm90b2NvbCBiaXRzIGFyZSB0aGUgZWFzeSBwYXJ0LiAgSWYgcGVvcGxlIGhh dmUgc29tZSB1bmRlcnN0YW5kaW5nIG9mIHRoYXQgbWFnaWMgYW5kIGFyZSB3aWxsaW5nIHRvIHNo YXJlLCB0aGVuIHRoaXMgd29yayBiZWNvbWVzIGNvbnNpZGVyYWJseSBtb3JlIGludGVyZXN0aW5n Lg0KDQpFbGlvdA0KDQpPbiAyMS4wNi4xOCAxNzoxMSwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6 DQpIaSBhbGwsDQoNCkkgd291bGQgbGlrZSB0byBtYWtlIHlvdSBhd2FyZSBvZiB3b3JrIHRoYXQg d2lsbCBiZSBkaXNjdXNzZWQgb24gYXR0ZXN0YXRpb24gb24gdGhlIEVBVCBtYWlsaW5nIGxpc3Qu IEhlcmUgaXMgdGhlIGxpbmsgdG8gdGhlIGxpc3Q6DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2VhdA0KDQpIZXJlIGlzIGEgZG9jdW1lbnQgZGVzY3JpYmluZyB0aGUgaWRl YToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYW5keWFtLWVhdC0wMA0KDQpU aGUgd29yayBpcyByZWxldmFudCBmb3IgSW9UIGFuZCBub24tSW9UIGRldmljZXMuDQoNCkxhdXJl bmNlIGFuZCBJIGFyZSBwbGFubmluZyB0byBvcmdhbml6ZSBhIEJhciBCT0YgYXQgdGhlIE1vbnRy ZWFsIElFVEYgbWVldGluZyB0byBlbnRlcnRhaW4gdGhlIGlkZWEuDQoNCkNpYW8NCkhhbm5lcw0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGluZyBsaXN0 DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUg Y29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRp YWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8g bm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9y IGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVk aXVtLiBUaGFuayB5b3UuDQo= --_000_VI1PR0801MB2112D2148E29AF0E63603AC0FA760VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNr Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhdOKAmXMgYSBnb29kIHF1ZXN0aW9u LCBFbGlvdC4gTGV0IG1lIHB1dCBzb21ldGhpbmcgdG9nZXRoZXIgZm9yIHRoZSBJRVRGIG1lZXRp bmcNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9 Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+DQogRWxpb3QgTGVhciBbbWFp bHRvOmxlYXJAY2lzY28uY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gMjEgSnVuZSAyMDE4IDIwOjE3 PGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzsgb2F1dGhAaWV0Zi5vcmc8YnI+DQo8 Yj5DYzo8L2I+IExhdXJlbmNlIEx1bmRibGFkZTsgZWF0QGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbT0FVVEgtV0ddIFN0YW5kYXJkaXppbmcgQXR0ZXN0YXRpb24gVG9rZW5zPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SGkgSGFubmVzLDxvOnA+PC9vOnA+PC9wPg0KPHA+ VGhlIGRyYWZ0IGlzIGludGVyZXN0aW5nLCBidXQgaXQgbG9va3MgYSBiaXQgbGlrZSBORUEuJm5i c3A7IEhvdyB3b3VsZCB0aGlzIHZhcnksIGFwYXJ0IGZyb20gdGhlIENvQVAgcGFydCBhbmQgYSBk aWZmZXJlbnQgcmVnaXN0cnk/Jm5ic3A7IFNlZW1zIHRvIG1lIHRoZSByZWFsIG1hZ2ljIGlzIGhv dyB0aGUgZGV2aWNlIGlzIGludGVycm9nYXRlZCBzdWNoIHRoYXQgdGhlIGNvbnN1bWVyIG9mIHRo aXMgaW5mb3JtYXRpb24gaGFzIGNvbmZpZGVuY2UgYXMgdG8NCiBpdHMgdmFsaWRpdHkuJm5ic3A7 IFRoZSBwcm90b2NvbCBiaXRzIGFyZSB0aGUgZWFzeSBwYXJ0LiZuYnNwOyBJZiBwZW9wbGUgaGF2 ZSBzb21lIHVuZGVyc3RhbmRpbmcgb2YgdGhhdCBtYWdpYyBhbmQgYXJlIHdpbGxpbmcgdG8gc2hh cmUsIHRoZW4gdGhpcyB3b3JrIGJlY29tZXMgY29uc2lkZXJhYmx5IG1vcmUgaW50ZXJlc3Rpbmcu PG86cD48L286cD48L3A+DQo8cD5FbGlvdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gMjEuMDYuMTggMTc6MTEsIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCwgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgd291bGQgbGlrZSB0byBtYWtlIHlvdSBhd2FyZSBvZiB3b3JrIHRoYXQgd2ls bCBiZSBkaXNjdXNzZWQgb24gYXR0ZXN0YXRpb24gb24gdGhlIEVBVCBtYWlsaW5nIGxpc3QuIEhl cmUgaXMgdGhlIGxpbmsgdG8gdGhlIGxpc3Q6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZWF0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VhdDwvYT48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBpcyBhIGRvY3VtZW50IGRlc2NyaWJpbmcgdGhlIGlkZWE6 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hbmR5YW0tZWF0LTAwIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtbWFuZHlhbS1lYXQtMDA8L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSB3b3JrIGlzIHJlbGV2YW50IGZvciBJb1QgYW5kIG5vbi1Jb1QgZGV2aWNlcy4gPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxhdXJlbmNlIGFuZCBJIGFyZSBwbGFubmluZyB0byBvcmdh bml6ZSBhIEJhciBCT0YgYXQgdGhlIE1vbnRyZWFsIElFVEYgbWVldGluZyB0byBlbnRlcnRhaW4g dGhlIGlkZWEuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tR0IiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwNCiBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUg b3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9B dXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpP QXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0801MB2112D2148E29AF0E63603AC0FA760VI1PR0801MB2112_-- From nobody Thu Jun 21 23:02:23 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236A9130DEB; Thu, 21 Jun 2018 23:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHyKpTRtkjdk; Thu, 21 Jun 2018 23:02:08 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA3C130DDE; Thu, 21 Jun 2018 23:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13445; q=dns/txt; s=iport; t=1529647328; x=1530856928; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=X/E31jpEZdrFlmHnoAsAEW2dIaJ2T3hykFSV1UbSmRM=; b=IMU3PrbhRVok5zWMl6q/MeTmaEqEHfUlv+Zcr8VXYZoDe77VUEbueY8z B6FNrD/9ZivLZ344z3BX0+LLeNi1xr2/RWsl4pEqRmcjJGATwoPMEqcDY ozJbkjPJNJBM7rtApvnJcps+RuMqu0zC6DTy9q2BDVfFqtVVz5b5Al81w 0=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQD7jyxb/xbLJq1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJTTIEMfyiDeYhjjWWPfYUDFIFlCAMYAQqESQKDHjUXAQI?= =?us-ascii?q?BAQEBAQECbRwMhSgBAQEBAwEBIQpBAgkQCxEEAQEBJwMCAicfCQgGAQwGAgE?= =?us-ascii?q?BgyEBgX8Pq0OCHB+IJXYKBYdKgx0lgRGCaIMYAQEDgSoBEgFLCoJLglUChz6?= =?us-ascii?q?BBZBjCYNTgVhShVSDOQaBPx2DZIJGhTuKHYdDgUMCNGFxMxoIGxUxCgV6HYE?= =?us-ascii?q?iKQmDKQECh1yFQD0wjXOCOQEB?= X-IronPort-AV: E=Sophos;i="5.51,255,1526342400"; d="asc'?scan'208,217";a="4711863" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2018 06:02:05 +0000 Received: from [10.61.249.74] ([10.61.249.74]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w5M6253n013880; Fri, 22 Jun 2018 06:02:05 GMT To: Hannes Tschofenig , "oauth@ietf.org" Cc: Laurence Lundblade , "eat@ietf.org" References: From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: Date: Fri, 22 Jun 2018 08:02:04 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9QvluuTOtKJ0rWBmSqKx2yKELc4qGOtyQ" Archived-At: Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 06:02:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9QvluuTOtKJ0rWBmSqKx2yKELc4qGOtyQ Content-Type: multipart/mixed; boundary="91BAbt6wfZWIVOWZ1RQBQpk5H8aEfJ9pU"; protected-headers="v1" From: Eliot Lear To: Hannes Tschofenig , "oauth@ietf.org" Cc: Laurence Lundblade , "eat@ietf.org" Message-ID: Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens References: In-Reply-To: --91BAbt6wfZWIVOWZ1RQBQpk5H8aEfJ9pU Content-Type: multipart/alternative; boundary="------------4EB4E73ED8C7DAD9963454B8" Content-Language: en-US This is a multi-part message in MIME format. --------------4EB4E73ED8C7DAD9963454B8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable By the way, a lot *has* changed.=C2=A0 If we can use the TEE to get signe= d information out... if *it* is the attester, that's a pretty big benefit.=C2=A0 That just leaves the protocol gorp.=C2=A0 But one needs to= know that there is a TEE. On 21.06.18 22:04, Hannes Tschofenig wrote: > > That=E2=80=99s a good question, Eliot. Let me put something together fo= r the > IETF meeting > > =C2=A0 > > *From:*Eliot Lear [mailto:lear@cisco.com] > *Sent:* 21 June 2018 20:17 > *To:* Hannes Tschofenig; oauth@ietf.org > *Cc:* Laurence Lundblade; eat@ietf.org > *Subject:* Re: [OAUTH-WG] Standardizing Attestation Tokens > > =C2=A0 > > Hi Hannes, > > The draft is interesting, but it looks a bit like NEA.=C2=A0 How would = this > vary, apart from the CoAP part and a different registry?=C2=A0 Seems to= me > the real magic is how the device is interrogated such that the > consumer of this information has confidence as to its validity.=C2=A0 T= he > protocol bits are the easy part.=C2=A0 If people have some understandin= g of > that magic and are willing to share, then this work becomes > considerably more interesting. > > Eliot > > =C2=A0 > > On 21.06.18 17:11, Hannes Tschofenig wrote: > > Hi all, > > =C2=A0 > > I would like to make you aware of work that will be discussed on > attestation on the EAT mailing list. Here is the link to the list: > > https://www.ietf.org/mailman/listinfo/eat > > =C2=A0 > > Here is a document describing the idea: > > https://tools.ietf.org/html/draft-mandyam-eat-00 > > =C2=A0 > > The work is relevant for IoT and non-IoT devices. > > =C2=A0 > > Laurence and I are planning to organize a Bar BOF at the Montreal > IETF meeting to entertain the idea. > > =C2=A0 > > Ciao > > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments > are confidential and may also be privileged. If you are not the > intended recipient, please notify the sender immediately and do > not disclose the contents to any other person, use it for any > purpose, or store or copy the information in any medium. Thank you.= > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > =C2=A0 > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you.=20 --------------4EB4E73ED8C7DAD9963454B8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

By the way, a lot *has* changed.=C2=A0 If we can use the TEE to ge= t signed information out... if *it* is the attester, that's a pretty big benefit.=C2=A0 That just leaves the protocol gorp.=C2=A0 But on= e needs to know that there is a TEE.


On 21.06.18 22:04, Hannes Tschofenig wrote:

That=E2=80=99= s a good question, Eliot. Let me put something together for the IETF meeting

=C2= =A0

From: Eliot Lear [mailto:lear@cisco.com]
Sent: 21 June 2018 20:17
To: Hannes Tschofenig; oauth@ietf.org
Cc: Laurence Lundblade; eat@ietf.org
Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens

=C2=A0

Hi Hannes,

The draft is interesting, but it looks a bit like NEA.=C2=A0 H= ow would this vary, apart from the CoAP part and a different registry?=C2=A0 Seems to me the real magic is how the device is= interrogated such that the consumer of this information has confidence as to its validity.=C2=A0 The protocol bits are the = easy part.=C2=A0 If people have some understanding of that magic and= are willing to share, then this work becomes considerably more interesting.

Eliot

=C2=A0

On 21.06.18 17:11, Hannes Tschofenig wrote:

Hi all,

=C2=A0

I would like to make you aware of work that will be discussed on attestation on the EAT mailing list. Here is the link to the list:

https://www.ietf.org/mailman/listi= nfo/eat

=C2=A0

Here is a document describing the idea: =

https://tools.ietf.org/html/draft-= mandyam-eat-00

=C2=A0

The work is relevant for IoT and non-IoT= devices.

=C2=A0

Laurence and I are planning to organize = a Bar BOF at the Montreal IETF meeting to entertain the idea.

=C2=A0

Ciao

Hannes

I= MPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. 


_______________________________________________=

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

=C2=A0

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--------------4EB4E73ED8C7DAD9963454B8-- --91BAbt6wfZWIVOWZ1RQBQpk5H8aEfJ9pU-- --9QvluuTOtKJ0rWBmSqKx2yKELc4qGOtyQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlsskNwACgkQh7ZrRtnS ejPSYQf/bvjM+C7uuCmMhqgKt+MwaZmYqk7ZxvXUpVwgmT96Fflqc0+ziNd36dyr uMmrxHxSmCVRYXruNiFgoPPhRRc3YYTMrA8F5A65z803wNgRzdgD11f+z+sf+fmm vapz7zytX/fC7xg3LM8l5cstB9jhj91KZXlicJioJEO/nlJU6nsb5WEtZN5UFXBY 6KzAzbJ7XHIJlXLKMzOApvasIjj5sxgxbAw/h9Pu78XwC6B5KGXbbwUYnwgs3z/J nUOm1MxWw7R2tCNd3tJdJIEy7vmzU6s/rzh4J4eYWlqFFziVcMuGmPs8ZK+NvhNw vi2HmpK9cRVa/BywiEXGMKmQgh0Nnw== =BQ8K -----END PGP SIGNATURE----- --9QvluuTOtKJ0rWBmSqKx2yKELc4qGOtyQ-- From nobody Thu Jun 21 23:07:16 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D0D130DEB; Thu, 21 Jun 2018 23:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBM8kSwNLB22; Thu, 21 Jun 2018 23:06:46 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0049.outbound.protection.outlook.com [104.47.0.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4D1C130DDE; Thu, 21 Jun 2018 23:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6zuDzzL+WTiKmtRhKEzCbQGOf+xYDA93aO+BNmTVRCM=; b=H4Wazkt9UJXN5IXHvVRM3xKZkjaRK4VjM8axr4Op7q5CXF5akH3b49uQ8XiJGelGOVBlxWuQbBSIU2i7goDJW72rhzXFGtrJTKXTiMwRkbURyNqFC0ckpbWIjpqb3SQ6ydGEeD3VqYb6pQkEddb0I9uHDei7sax9YDacGeYrXN8= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1710.eurprd08.prod.outlook.com (10.168.67.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.19; Fri, 22 Jun 2018 06:06:42 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0863.016; Fri, 22 Jun 2018 06:06:42 +0000 From: Hannes Tschofenig To: Eliot Lear , "oauth@ietf.org" CC: Laurence Lundblade , "eat@ietf.org" Thread-Topic: [OAUTH-WG] Standardizing Attestation Tokens Thread-Index: AdQJcgYcjI8QIQCVT++3DyjB6i8mjQAImu2AAAGhYqAAFOTrAAAAGh9w Date: Fri, 22 Jun 2018 06:06:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [88.128.80.137] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1710; 7:1PeuY+BVfzEhutvc5q3JTQ0fxSPQ4Ea4r9tSeNLuBk7eW/l6Z2V+pIvyuKC5JDwAWDQDoRYf9PL97C4DqyXjVPFE0cGG4w5U5NFwN5/0qoHslJvbb5Wp1+SZW+8pO2p+zaY3eadFKVG/LgKtVX2oGyPrHrus8a0f2KPW6Kxr4KpO68+UHAQM2EPu5wLwer4t5eaKIhi54c02NmRljppi0d2R1950qkqGeKwu93KivNMjJhStTEqNIZxv0z6cCbik x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: dd084ee3-7880-4443-3d58-08d5d80653a0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(5600026)(711020)(48565401081)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1710; x-ms-traffictypediagnostic: VI1PR0801MB1710: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(3002001)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1710; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1710; x-forefront-prvs: 071156160B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(366004)(39860400002)(396003)(376002)(346002)(53754006)(189003)(199004)(40434004)(97736004)(2501003)(5660300001)(7696005)(59450400001)(102836004)(55236004)(6506007)(53546011)(76176011)(2900100001)(74316002)(26005)(7736002)(186003)(86362001)(105586002)(106356001)(3660700001)(3280700002)(2906002)(5890100001)(5250100002)(33656002)(478600001)(66066001)(93886005)(6246003)(8676002)(68736007)(72206003)(25786009)(966005)(229853002)(53936002)(6436002)(316002)(54896002)(14454004)(236005)(606006)(6306002)(55016002)(99286004)(9686003)(110136005)(54906003)(790700001)(6116002)(3846002)(486006)(446003)(476003)(81166006)(11346002)(4326008)(81156014)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1710; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: NbostHmYvzc17/mcOQjBJQv8XqAi93Vnr8wT+v9WTjNTtxhtWNkDCO5gpcC47n9KjA+IWeTBfNC/WB3o6zMacePV10PCnGlXkRp1Og+Sm730laV22dSgTQqZNqSwdwfe1EU++t5vqnxacT5/NyfnEgIlttxgVvO/Tx7ci/pZ99g49OoNyZoY8VrVlktvIsKVTpvbEcLouYMgldu1JXSr2PxW4MAAmGNYJenF98MqE6xG9Ft44b9ceCm5BA8gta6SQbpTOiJSaqGtfMZZNFWstwzREW+bQDZGvP+GDmEEHnWHI1Eukxb4EaX33an8B8z7I8j66/CVzx5nXlkQ+XKsiA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB21120DE3CBDDFF0AD065C0A1FA750VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd084ee3-7880-4443-3d58-08d5d80653a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2018 06:06:42.5765 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1710 Archived-At: Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 06:06:50 -0000 --_000_VI1PR0801MB21120DE3CBDDFF0AD065C0A1FA750VI1PR0801MB2112_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBndWVzcyB0aGlzIGlzIGEgcGllY2Ugb2YgaW5mbyB3ZSBzaG91bGQgaGF2ZSBtZW50aW9uZWQg c29tZXdoZXJlLiBZZXMsIHRoZSBpZGVhIGlzIHRvIHVzZSBhIFRFRSBmb3IgdGhhdCBwdXJwb3Nl Lg0KQXQgbGVhc3QgZm9yIEFybSwgVHJ1c3Rab25lIGZvciB2OC1NIGV2ZW4gYnJpbmdzIFRFRSBj YXBhYmlsaXRpZXMgdG8gdGhlIGxvdy1lbmQgSW9UIGRldmljZXMgYW5kIHRoZSBmaXJzdCBwcm9k dWN0cyBhcmUgYWxyZWFkeSBvbiB0aGUgbWFya2V0Lg0KDQpDaWFvDQpIYW5uZXMNCg0KRnJvbTog RWxpb3QgTGVhciBbbWFpbHRvOmxlYXJAY2lzY28uY29tXQ0KU2VudDogMjIgSnVuZSAyMDE4IDA3 OjAyDQpUbzogSGFubmVzIFRzY2hvZmVuaWc7IG9hdXRoQGlldGYub3JnDQpDYzogTGF1cmVuY2Ug THVuZGJsYWRlOyBlYXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFN0YW5kYXJk aXppbmcgQXR0ZXN0YXRpb24gVG9rZW5zDQoNCg0KQnkgdGhlIHdheSwgYSBsb3QgKmhhcyogY2hh bmdlZC4gIElmIHdlIGNhbiB1c2UgdGhlIFRFRSB0byBnZXQgc2lnbmVkIGluZm9ybWF0aW9uIG91 dC4uLiBpZiAqaXQqIGlzIHRoZSBhdHRlc3RlciwgdGhhdCdzIGEgcHJldHR5IGJpZyBiZW5lZml0 LiAgVGhhdCBqdXN0IGxlYXZlcyB0aGUgcHJvdG9jb2wgZ29ycC4gIEJ1dCBvbmUgbmVlZHMgdG8g a25vdyB0aGF0IHRoZXJlIGlzIGEgVEVFLg0KDQpPbiAyMS4wNi4xOCAyMjowNCwgSGFubmVzIFRz Y2hvZmVuaWcgd3JvdGU6DQpUaGF04oCZcyBhIGdvb2QgcXVlc3Rpb24sIEVsaW90LiBMZXQgbWUg cHV0IHNvbWV0aGluZyB0b2dldGhlciBmb3IgdGhlIElFVEYgbWVldGluZw0KDQpGcm9tOiBFbGlv dCBMZWFyIFttYWlsdG86bGVhckBjaXNjby5jb21dDQpTZW50OiAyMSBKdW5lIDIwMTggMjA6MTcN ClRvOiBIYW5uZXMgVHNjaG9mZW5pZzsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYu b3JnPg0KQ2M6IExhdXJlbmNlIEx1bmRibGFkZTsgZWF0QGlldGYub3JnPG1haWx0bzplYXRAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTdGFuZGFyZGl6aW5nIEF0dGVzdGF0aW9u IFRva2Vucw0KDQoNCkhpIEhhbm5lcywNCg0KVGhlIGRyYWZ0IGlzIGludGVyZXN0aW5nLCBidXQg aXQgbG9va3MgYSBiaXQgbGlrZSBORUEuICBIb3cgd291bGQgdGhpcyB2YXJ5LCBhcGFydCBmcm9t IHRoZSBDb0FQIHBhcnQgYW5kIGEgZGlmZmVyZW50IHJlZ2lzdHJ5PyAgU2VlbXMgdG8gbWUgdGhl IHJlYWwgbWFnaWMgaXMgaG93IHRoZSBkZXZpY2UgaXMgaW50ZXJyb2dhdGVkIHN1Y2ggdGhhdCB0 aGUgY29uc3VtZXIgb2YgdGhpcyBpbmZvcm1hdGlvbiBoYXMgY29uZmlkZW5jZSBhcyB0byBpdHMg dmFsaWRpdHkuICBUaGUgcHJvdG9jb2wgYml0cyBhcmUgdGhlIGVhc3kgcGFydC4gIElmIHBlb3Bs ZSBoYXZlIHNvbWUgdW5kZXJzdGFuZGluZyBvZiB0aGF0IG1hZ2ljIGFuZCBhcmUgd2lsbGluZyB0 byBzaGFyZSwgdGhlbiB0aGlzIHdvcmsgYmVjb21lcyBjb25zaWRlcmFibHkgbW9yZSBpbnRlcmVz dGluZy4NCg0KRWxpb3QNCg0KT24gMjEuMDYuMTggMTc6MTEsIEhhbm5lcyBUc2Nob2ZlbmlnIHdy b3RlOg0KSGkgYWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gbWFrZSB5b3UgYXdhcmUgb2Ygd29yayB0 aGF0IHdpbGwgYmUgZGlzY3Vzc2VkIG9uIGF0dGVzdGF0aW9uIG9uIHRoZSBFQVQgbWFpbGluZyBs aXN0LiBIZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBsaXN0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9lYXQNCg0KSGVyZSBpcyBhIGRvY3VtZW50IGRlc2NyaWJpbmcgdGhl IGlkZWE6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFuZHlhbS1lYXQtMDAN Cg0KVGhlIHdvcmsgaXMgcmVsZXZhbnQgZm9yIElvVCBhbmQgbm9uLUlvVCBkZXZpY2VzLg0KDQpM YXVyZW5jZSBhbmQgSSBhcmUgcGxhbm5pbmcgdG8gb3JnYW5pemUgYSBCYXIgQk9GIGF0IHRoZSBN b250cmVhbCBJRVRGIG1lZXRpbmcgdG8gZW50ZXJ0YWluIHRoZSBpZGVhLg0KDQpDaWFvDQpIYW5u ZXMNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkg dGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1dGggbWFpbGlu ZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpJTVBPUlRBTlQgTk9USUNF OiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25m aWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBp bnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBh bnkgbWVkaXVtLiBUaGFuayB5b3UuDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5r IHlvdS4NCg== --_000_VI1PR0801MB21120DE3CBDDFF0AD065C0A1FA750VI1PR0801MB2112_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQg MyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOmJsYWNrOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29s b3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgZ3Vlc3MgdGhpcyBpcyBhIHBpZWNlIG9mIGluZm8gd2Ug c2hvdWxkIGhhdmUgbWVudGlvbmVkIHNvbWV3aGVyZS4gWWVzLCB0aGUgaWRlYSBpcyB0byB1c2Ug YSBURUUgZm9yIHRoYXQgcHVycG9zZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BdCBsZWFzdCBmb3IgQXJt LCBUcnVzdFpvbmUgZm9yIHY4LU0gZXZlbiBicmluZ3MgVEVFIGNhcGFiaWxpdGllcyB0byB0aGUg bG93LWVuZCBJb1QgZGV2aWNlcyBhbmQgdGhlIGZpcnN0IHByb2R1Y3RzIGFyZSBhbHJlYWR5IG9u IHRoZSBtYXJrZXQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkNpYW88 YnI+DQpIYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdC Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPg0KIEVsaW90IExl YXIgW21haWx0bzpsZWFyQGNpc2NvLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IDIyIEp1bmUgMjAx OCAwNzowMjxicj4NCjxiPlRvOjwvYj4gSGFubmVzIFRzY2hvZmVuaWc7IG9hdXRoQGlldGYub3Jn PGJyPg0KPGI+Q2M6PC9iPiBMYXVyZW5jZSBMdW5kYmxhZGU7IGVhdEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTdGFuZGFyZGl6aW5nIEF0dGVzdGF0aW9uIFRv a2VuczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkJ5IHRoZSB3YXksIGEgbG90ICpoYXMq IGNoYW5nZWQuJm5ic3A7IElmIHdlIGNhbiB1c2UgdGhlIFRFRSB0byBnZXQgc2lnbmVkIGluZm9y bWF0aW9uIG91dC4uLiBpZiAqaXQqIGlzIHRoZSBhdHRlc3RlciwgdGhhdCdzIGEgcHJldHR5IGJp ZyBiZW5lZml0LiZuYnNwOyBUaGF0IGp1c3QgbGVhdmVzIHRoZSBwcm90b2NvbCBnb3JwLiZuYnNw OyBCdXQgb25lIG5lZWRzIHRvIGtub3cgdGhhdCB0aGVyZSBpcyBhIFRFRS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIxLjA2LjE4IDIyOjA0LCBIYW5uZXMgVHNjaG9mZW5pZyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhdOKAmXMgYSBnb29kIHF1ZXN0aW9uLCBFbGlvdC4g TGV0IG1lIHB1dCBzb21ldGhpbmcgdG9nZXRoZXIgZm9yIHRoZSBJRVRGIG1lZXRpbmcNCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQ7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tR0IiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+ DQogRWxpb3QgTGVhciBbPGEgaHJlZj0ibWFpbHRvOmxlYXJAY2lzY28uY29tIj5tYWlsdG86bGVh ckBjaXNjby5jb208L2E+XSA8YnI+DQo8Yj5TZW50OjwvYj4gMjEgSnVuZSAyMDE4IDIwOjE3PGJy Pg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IExhdXJlbmNlIEx1bmRi bGFkZTsgPGEgaHJlZj0ibWFpbHRvOmVhdEBpZXRmLm9yZyI+ZWF0QGlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTdGFuZGFyZGl6aW5nIEF0dGVzdGF0aW9u IFRva2Vuczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkhpIEhhbm5lcyw8bzpwPjwvbzpw PjwvcD4NCjxwPlRoZSBkcmFmdCBpcyBpbnRlcmVzdGluZywgYnV0IGl0IGxvb2tzIGEgYml0IGxp a2UgTkVBLiZuYnNwOyBIb3cgd291bGQgdGhpcyB2YXJ5LCBhcGFydCBmcm9tIHRoZSBDb0FQIHBh cnQgYW5kIGEgZGlmZmVyZW50IHJlZ2lzdHJ5PyZuYnNwOyBTZWVtcyB0byBtZSB0aGUgcmVhbCBt YWdpYyBpcyBob3cgdGhlIGRldmljZSBpcyBpbnRlcnJvZ2F0ZWQgc3VjaCB0aGF0IHRoZSBjb25z dW1lciBvZiB0aGlzIGluZm9ybWF0aW9uIGhhcyBjb25maWRlbmNlIGFzIHRvDQogaXRzIHZhbGlk aXR5LiZuYnNwOyBUaGUgcHJvdG9jb2wgYml0cyBhcmUgdGhlIGVhc3kgcGFydC4mbmJzcDsgSWYg cGVvcGxlIGhhdmUgc29tZSB1bmRlcnN0YW5kaW5nIG9mIHRoYXQgbWFnaWMgYW5kIGFyZSB3aWxs aW5nIHRvIHNoYXJlLCB0aGVuIHRoaXMgd29yayBiZWNvbWVzIGNvbnNpZGVyYWJseSBtb3JlIGlu dGVyZXN0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHA+RWxpb3Q8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDIxLjA2LjE4IDE3OjExLCBIYW5uZXMgVHNjaG9mZW5pZyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBhbGwsIDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdvdWxkIGxpa2UgdG8gbWFrZSB5b3UgYXdhcmUgb2Ygd29y ayB0aGF0IHdpbGwgYmUgZGlzY3Vzc2VkIG9uIGF0dGVzdGF0aW9uIG9uIHRoZSBFQVQgbWFpbGlu ZyBsaXN0LiBIZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBsaXN0Og0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2VhdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lYXQ8 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUgaXMgYSBkb2N1bWVudCBkZXNjcmliaW5n IHRoZSBpZGVhOiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYW5keWFtLWVhdC0wMCI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hbmR5YW0tZWF0LTAwPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgd29yayBpcyByZWxldmFudCBmb3IgSW9UIGFuZCBub24tSW9UIGRl dmljZXMuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MYXVyZW5jZSBhbmQgSSBhcmUgcGxhbm5p bmcgdG8gb3JnYW5pemUgYSBCYXIgQk9GIGF0IHRoZSBNb250cmVhbCBJRVRGIG1lZXRpbmcgdG8g ZW50ZXJ0YWluIHRoZSBpZGVhLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklNUE9SVEFO VCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg YXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UNCiB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBl cnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3Jt YXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1haWxpbmcg bGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y ZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+ SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LA0KIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRz IG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNj bG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_VI1PR0801MB21120DE3CBDDFF0AD065C0A1FA750VI1PR0801MB2112_-- From nobody Fri Jun 22 07:02:44 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C13E130E63; Fri, 22 Jun 2018 07:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSD2mQ2cUEzm; Fri, 22 Jun 2018 07:02:40 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09A5130E52; Fri, 22 Jun 2018 07:02:39 -0700 (PDT) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2018 07:02:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.51,257,1526367600"; d="scan'208,217"; a="69155474" Received: from fmsmsx107.amr.corp.intel.com ([10.18.124.205]) by orsmga002.jf.intel.com with ESMTP; 22 Jun 2018 07:02:39 -0700 Received: from fmsmsx125.amr.corp.intel.com (10.18.125.40) by fmsmsx107.amr.corp.intel.com (10.18.124.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 22 Jun 2018 07:02:39 -0700 Received: from crsmsx152.amr.corp.intel.com (172.18.7.35) by FMSMSX125.amr.corp.intel.com (10.18.125.40) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 22 Jun 2018 07:02:38 -0700 Received: from crsmsx101.amr.corp.intel.com ([169.254.1.79]) by CRSMSX152.amr.corp.intel.com ([169.254.5.115]) with mapi id 14.03.0319.002; Fri, 22 Jun 2018 08:02:37 -0600 From: "Wheeler, David M" To: Hannes Tschofenig , Eliot Lear , "oauth@ietf.org" CC: "eat@ietf.org" , Laurence Lundblade Thread-Topic: [OAUTH-WG] Standardizing Attestation Tokens Thread-Index: AQHUCe9GWYrZSkeRUEWlNiFoTC1UpqRsS0xA Date: Fri, 22 Jun 2018 14:02:36 +0000 Message-ID: <0627F5240443D2498FAA65332EE46C843B65778E@CRSMSX101.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTI2ZGI0NjYtNGJjYS00M2U0LTkwYzgtYzFhMGNjZTFiMzMzIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRXY4Rm9peTdnaWpxRUNZd2kzZjBvcFV0MjRHaklOcDI0anhKUHZhVDExUHF5MGQrM1pXbTBJRG55RWdBNnVhQiJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [172.18.205.10] Content-Type: multipart/alternative; boundary="_000_0627F5240443D2498FAA65332EE46C843B65778ECRSMSX101amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 14:02:42 -0000 --_000_0627F5240443D2498FAA65332EE46C843B65778ECRSMSX101amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGF1cmVuY2UsDQpJdCBpcyBnb29kIHRvIGhlYXIgeW91ciBuYW1lIGFnYWluISBJIGxvb2sgZm9y d2FyZCB0byBzZWVpbmcgeW91IGluIE1vbnRyZWFsLg0KDQpJIGhhdmUgc2tpbW1lZCB0aHJvdWdo IHRoZSBwcm9wb3NhbCwgYnV0IEkgc3RpbGwgbmVlZCB0byByZWFkIGl0IG1vcmUgZGVlcGx5IGFu ZCBjYXJlZnVsbHkg4oCTIHBsZWFzZSBleGN1c2UgbWUgaWYgSSBtaXNzZWQgc29tZXRoaW5nIGlu IHRoZSByZWFkaW5nLg0KDQpXaGF0IHNlZW1zIHRvIGJlIG1pc3NpbmcgZnJvbSB0aGUgcHJvcG9z ZWQgc3RydWN0dXJlIGlzIHRoZSBhYmlsaXR5IHRvIGF0dGFjaCBuZXcga2V5IG1hdGVyaWFsIGlu dG8gdGhlIEVBVCBzdHJ1Y3R1cmUsIHdpdGggYW4gYXR0ZXN0YXRpb24gY2xhaW0uIFRoZSBhdHRl c3RhdGlvbiBjbGFpbSBjYW4gYmUgdGhhdCBpdCB3YXMgZ2VuZXJhdGVkIG9uIHRoZSBkZXZpY2Us IG9yIGdlbmVyYXRlZCBpbnNpZGUgdGhlIFRFRSBhbmQgYm91bmQvc2VhbGVkIHRvIHRoZSBURUUu IEFuZCBwZXJoYXBzIGV2ZW4gYSBwdXJwb3NlIGZvciB0aGUga2V5IG1hdGVyaWFsLiBBIG5ldyBh dHRlc3RhdGlvbiBrZXksIGZvciBleGFtcGxlOyBvciBhIHNwZWNpYWwgc2lnbmluZy9hdXRob3Jp emF0aW9uIGtleSBmb3IgYSBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9uLg0KDQpNYW55IHRpbWVzLCBJ TUhPLCBpdCBpcyB1c2VmdWwgdG8gZ2VuZXJhdGUgYSBuZXcga2V5IHRoYXQgaXMgYXR0ZXN0ZWQg aW4gc29tZSB3YXksIGFuZCB0aGVuIGZ1dHVyZSBvcGVyYXRpb25zIHVzZSB0aGF0IGtleS4gSW4g ZmFjdCwgT1RyUC9URUVQIGhhcyB0aGlzIGltcGxpY2F0aW9uLCB3aXRoIHRoZSBBSUsga2V5cyBm b3IgbmV3IGluc3RhbGxlZCBBcHBzLCBidXQgKElNTykgaXQgaXMgbm90IHJlYWxseSB0aGF0IGNs ZWFybHkgc3BlbGxlZCBvdXQsIGFsdGhvdWdoIEkgdGhpbmsgdGhlIGludGVudGlvbiBpcyBjbGVh ci4NCg0KT3RoZXIgYXR0ZXN0YXRpb24gY2xhaW1zIGFyZSBhbHNvIHVzZWZ1bCDigJMgdGhlIGlk ZW50aXR5IGFuZCBjcnlwdG9ncmFwaGljIGhhc2ggb2YgdGhlIGNvZGUgb2YgYSBwYXJ0aWN1bGFy IFRFRSBhcHBsaWNhdGlvbjsgYSBESCBwdWJsaWMga2V5IHRvIGVzdGFibGlzaCBhbiBlbmNyeXB0 ZWQgY2hhbm5lbDsgdGhlIHNldCBvZiByb290IENB4oCZcyB0aGlzIFRFRSB3aWxsIHRydXN0OyDi gKYNCg0KT25lIGFkZGl0aW9uYWwgdGhpbmcgdGhhdCBJIHdvdWxkIGxpa2UgdG8gc2VlIGlzIHBl cmhhcHMgYSBtb3JlIGdlbmVyaWMgd2F5IHRvIGV4dGVuZCBvciBhZGQgYSBjbGFpbSBpbnRvIHRo ZSBhdHRlc3RhdGlvbiBzdHJ1Y3R1cmUuIEFmdGVyIGFsbCwgdGhlIGF0dGVzdGF0aW9uIGlzIGp1 c3QgYSBjb250YWluZXIsIHRoYXQgaXMgc2lnbmVkLCB3aGljaCBjYXJyaWVzIHNvbWUgY2xhaW1z LiBCdXQgZm9yIHRoZXNlIGNsYWltcyB0byBiZSB0cnVlLCB0aGUgY2xhaW1zIG11c3QgYmUgY29u c3RydWN0ZWQgaW4gYSB3YXkgdGhhdCB3b3VsZCBiZSB0cnVzdGVkIGJ5IGEgdmVyaWZpZXIuIEFk ZGl0aW9uYWwgZGF0YSBmb3IgdGhlIHZlcmlmaWVyIHRvIHVuZGVyc3RhbmQgaG93IHRoZSBjbGFp bXMgYXJlIGNvbnN0cnVjdGVkICh3aGljaCBtYXkgYmUgaW5mZXJyZWQgYnkgdGhlIG9yaWdpbmF0 aW9uIGluZm9ybWF0aW9uKSwgYnV0IG1heSBuZWVkIG1vcmUgZGF0YSwgYXMgc29tZSBjbGFpbXMg KGZvciBzZWN1cmUgYm9vdCkgbWF5IGNvbWUgZnJvbSB0aGUgVFBNLCBhbmQgb3RoZXJzIGZyb20g YSBURUUuDQoNCkkgZG8gbGlrZSB0aGlzIHByb3Bvc2FsLCBJIGhvcGUgd2UgY2FuIGRpc2N1c3Mg c29tZSBleHRlbnNpb25zIHRvIG1ha2UgaXQgbW9yZSBleHRlbnNpYmxlLg0KDQpUaGFua3MsDQpE YXZlIFdoZWVsZXINCg0KRnJvbTogRUFUIFttYWlsdG86ZWF0LWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogVGh1cnNkYXksIEp1bmUgMjEsIDIw MTggMTE6MDcgUE0NClRvOiBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbT47IG9hdXRoQGlldGYu b3JnDQpDYzogZWF0QGlldGYub3JnOyBMYXVyZW5jZSBMdW5kYmxhZGUgPGxnbEBpc2xhbmQtcmVz b3J0LmNvbT4NClN1YmplY3Q6IFJlOiBbRUFUXSBbT0FVVEgtV0ddIFN0YW5kYXJkaXppbmcgQXR0 ZXN0YXRpb24gVG9rZW5zDQoNCkkgZ3Vlc3MgdGhpcyBpcyBhIHBpZWNlIG9mIGluZm8gd2Ugc2hv dWxkIGhhdmUgbWVudGlvbmVkIHNvbWV3aGVyZS4gWWVzLCB0aGUgaWRlYSBpcyB0byB1c2UgYSBU RUUgZm9yIHRoYXQgcHVycG9zZS4NCkF0IGxlYXN0IGZvciBBcm0sIFRydXN0Wm9uZSBmb3Igdjgt TSBldmVuIGJyaW5ncyBURUUgY2FwYWJpbGl0aWVzIHRvIHRoZSBsb3ctZW5kIElvVCBkZXZpY2Vz IGFuZCB0aGUgZmlyc3QgcHJvZHVjdHMgYXJlIGFscmVhZHkgb24gdGhlIG1hcmtldC4NCg0KQ2lh bw0KSGFubmVzDQoNCkZyb206IEVsaW90IExlYXIgW21haWx0bzpsZWFyQGNpc2NvLmNvbV0NClNl bnQ6IDIyIEp1bmUgMjAxOCAwNzowMg0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnOyBvYXV0aEBpZXRm Lm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpDYzogTGF1cmVuY2UgTHVuZGJsYWRlOyBlYXRA aWV0Zi5vcmc8bWFpbHRvOmVhdEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFN0 YW5kYXJkaXppbmcgQXR0ZXN0YXRpb24gVG9rZW5zDQoNCg0KQnkgdGhlIHdheSwgYSBsb3QgKmhh cyogY2hhbmdlZC4gIElmIHdlIGNhbiB1c2UgdGhlIFRFRSB0byBnZXQgc2lnbmVkIGluZm9ybWF0 aW9uIG91dC4uLiBpZiAqaXQqIGlzIHRoZSBhdHRlc3RlciwgdGhhdCdzIGEgcHJldHR5IGJpZyBi ZW5lZml0LiAgVGhhdCBqdXN0IGxlYXZlcyB0aGUgcHJvdG9jb2wgZ29ycC4gIEJ1dCBvbmUgbmVl ZHMgdG8ga25vdyB0aGF0IHRoZXJlIGlzIGEgVEVFLg0KDQpPbiAyMS4wNi4xOCAyMjowNCwgSGFu bmVzIFRzY2hvZmVuaWcgd3JvdGU6DQpUaGF04oCZcyBhIGdvb2QgcXVlc3Rpb24sIEVsaW90LiBM ZXQgbWUgcHV0IHNvbWV0aGluZyB0b2dldGhlciBmb3IgdGhlIElFVEYgbWVldGluZw0KDQpGcm9t OiBFbGlvdCBMZWFyIFttYWlsdG86bGVhckBjaXNjby5jb21dDQpTZW50OiAyMSBKdW5lIDIwMTgg MjA6MTcNClRvOiBIYW5uZXMgVHNjaG9mZW5pZzsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRo QGlldGYub3JnPg0KQ2M6IExhdXJlbmNlIEx1bmRibGFkZTsgZWF0QGlldGYub3JnPG1haWx0bzpl YXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBTdGFuZGFyZGl6aW5nIEF0dGVz dGF0aW9uIFRva2Vucw0KDQoNCkhpIEhhbm5lcywNCg0KVGhlIGRyYWZ0IGlzIGludGVyZXN0aW5n LCBidXQgaXQgbG9va3MgYSBiaXQgbGlrZSBORUEuICBIb3cgd291bGQgdGhpcyB2YXJ5LCBhcGFy dCBmcm9tIHRoZSBDb0FQIHBhcnQgYW5kIGEgZGlmZmVyZW50IHJlZ2lzdHJ5PyAgU2VlbXMgdG8g bWUgdGhlIHJlYWwgbWFnaWMgaXMgaG93IHRoZSBkZXZpY2UgaXMgaW50ZXJyb2dhdGVkIHN1Y2gg dGhhdCB0aGUgY29uc3VtZXIgb2YgdGhpcyBpbmZvcm1hdGlvbiBoYXMgY29uZmlkZW5jZSBhcyB0 byBpdHMgdmFsaWRpdHkuICBUaGUgcHJvdG9jb2wgYml0cyBhcmUgdGhlIGVhc3kgcGFydC4gIElm IHBlb3BsZSBoYXZlIHNvbWUgdW5kZXJzdGFuZGluZyBvZiB0aGF0IG1hZ2ljIGFuZCBhcmUgd2ls bGluZyB0byBzaGFyZSwgdGhlbiB0aGlzIHdvcmsgYmVjb21lcyBjb25zaWRlcmFibHkgbW9yZSBp bnRlcmVzdGluZy4NCg0KRWxpb3QNCg0KT24gMjEuMDYuMTggMTc6MTEsIEhhbm5lcyBUc2Nob2Zl bmlnIHdyb3RlOg0KSGkgYWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gbWFrZSB5b3UgYXdhcmUgb2Yg d29yayB0aGF0IHdpbGwgYmUgZGlzY3Vzc2VkIG9uIGF0dGVzdGF0aW9uIG9uIHRoZSBFQVQgbWFp bGluZyBsaXN0LiBIZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBsaXN0Og0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lYXQNCg0KSGVyZSBpcyBhIGRvY3VtZW50IGRlc2NyaWJp bmcgdGhlIGlkZWE6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFuZHlhbS1l YXQtMDANCg0KVGhlIHdvcmsgaXMgcmVsZXZhbnQgZm9yIElvVCBhbmQgbm9uLUlvVCBkZXZpY2Vz Lg0KDQpMYXVyZW5jZSBhbmQgSSBhcmUgcGxhbm5pbmcgdG8gb3JnYW5pemUgYSBCYXIgQk9GIGF0 IHRoZSBNb250cmVhbCBJRVRGIG1lZXRpbmcgdG8gZW50ZXJ0YWluIHRoZSBpZGVhLg0KDQpDaWFv DQpIYW5uZXMNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmls ZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRz IHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9y IGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk9BdXRoIG1h aWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KSU1QT1JUQU5UIE5P VElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwg dXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24g aW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQo= --_000_0627F5240443D2498FAA65332EE46C843B65778ECRSMSX101amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TGF1cmVuY2UsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkl0IGlzIGdvb2QgdG8gaGVhciB5b3VyIG5hbWUgYWdhaW4hIEkgbG9vayBmb3J3 YXJkIHRvIHNlZWluZyB5b3UgaW4gTW9udHJlYWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5JIGhhdmUgc2tpbW1lZCB0aHJvdWdoIHRoZSBwcm9wb3NhbCwgYnV0IEkgc3Rp bGwgbmVlZCB0byByZWFkIGl0IG1vcmUgZGVlcGx5IGFuZCBjYXJlZnVsbHkg4oCTIHBsZWFzZSBl eGN1c2UgbWUgaWYgSSBtaXNzZWQgc29tZXRoaW5nIGluIHRoZSByZWFkaW5nLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hhdCBzZWVtcyB0byBiZSBtaXNzaW5nIGZyb20g dGhlIHByb3Bvc2VkIHN0cnVjdHVyZSBpcyB0aGUgYWJpbGl0eSB0byBhdHRhY2ggbmV3IGtleSBt YXRlcmlhbCBpbnRvIHRoZSBFQVQgc3RydWN0dXJlLCB3aXRoIGFuIGF0dGVzdGF0aW9uIGNsYWlt LiBUaGUgYXR0ZXN0YXRpb24gY2xhaW0gY2FuIGJlIHRoYXQgaXQgd2FzIGdlbmVyYXRlZCBvbiB0 aGUgZGV2aWNlLA0KIG9yIGdlbmVyYXRlZCBpbnNpZGUgdGhlIFRFRSBhbmQgYm91bmQvc2VhbGVk IHRvIHRoZSBURUUuIEFuZCBwZXJoYXBzIGV2ZW4gYSBwdXJwb3NlIGZvciB0aGUga2V5IG1hdGVy aWFsLiBBIG5ldyBhdHRlc3RhdGlvbiBrZXksIGZvciBleGFtcGxlOyBvciBhIHNwZWNpYWwgc2ln bmluZy9hdXRob3JpemF0aW9uIGtleSBmb3IgYSBwYXJ0aWN1bGFyIGFwcGxpY2F0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TWFueSB0aW1lcywgSU1ITywgaXQgaXMg dXNlZnVsIHRvIGdlbmVyYXRlIGEgbmV3IGtleSB0aGF0IGlzIGF0dGVzdGVkIGluIHNvbWUgd2F5 LCBhbmQgdGhlbiBmdXR1cmUgb3BlcmF0aW9ucyB1c2UgdGhhdCBrZXkuIEluIGZhY3QsIE9UclAv VEVFUCBoYXMgdGhpcyBpbXBsaWNhdGlvbiwgd2l0aCB0aGUgQUlLIGtleXMgZm9yIG5ldyBpbnN0 YWxsZWQgQXBwcywgYnV0DQogKElNTykgaXQgaXMgbm90IHJlYWxseSB0aGF0IGNsZWFybHkgc3Bl bGxlZCBvdXQsIGFsdGhvdWdoIEkgdGhpbmsgdGhlIGludGVudGlvbiBpcyBjbGVhci48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk90aGVyIGF0dGVzdGF0aW9uIGNsYWltcyBh cmUgYWxzbyB1c2VmdWwg4oCTIHRoZSBpZGVudGl0eSBhbmQgY3J5cHRvZ3JhcGhpYyBoYXNoIG9m IHRoZSBjb2RlIG9mIGEgcGFydGljdWxhciBURUUgYXBwbGljYXRpb247IGEgREggcHVibGljIGtl eSB0byBlc3RhYmxpc2ggYW4gZW5jcnlwdGVkIGNoYW5uZWw7IHRoZSBzZXQgb2Ygcm9vdCBDQeKA mXMgdGhpcyBURUUgd2lsbA0KIHRydXN0OyDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPk9uZSBhZGRpdGlvbmFsIHRoaW5nIHRoYXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBp cyBwZXJoYXBzIGEgbW9yZSBnZW5lcmljIHdheSB0byBleHRlbmQgb3IgYWRkIGEgY2xhaW0gaW50 byB0aGUgYXR0ZXN0YXRpb24gc3RydWN0dXJlLiBBZnRlciBhbGwsIHRoZSBhdHRlc3RhdGlvbiBp cyBqdXN0IGEgY29udGFpbmVyLCB0aGF0IGlzIHNpZ25lZCwgd2hpY2ggY2Fycmllcw0KIHNvbWUg Y2xhaW1zLiBCdXQgZm9yIHRoZXNlIGNsYWltcyB0byBiZSB0cnVlLCB0aGUgY2xhaW1zIG11c3Qg YmUgY29uc3RydWN0ZWQgaW4gYSB3YXkgdGhhdCB3b3VsZCBiZSB0cnVzdGVkIGJ5IGEgdmVyaWZp ZXIuIEFkZGl0aW9uYWwgZGF0YSBmb3IgdGhlIHZlcmlmaWVyIHRvIHVuZGVyc3RhbmQgaG93IHRo ZSBjbGFpbXMgYXJlIGNvbnN0cnVjdGVkICh3aGljaCBtYXkgYmUgaW5mZXJyZWQgYnkgdGhlIG9y aWdpbmF0aW9uIGluZm9ybWF0aW9uKSwNCiBidXQgbWF5IG5lZWQgbW9yZSBkYXRhLCBhcyBzb21l IGNsYWltcyAoZm9yIHNlY3VyZSBib290KSBtYXkgY29tZSBmcm9tIHRoZSBUUE0sIGFuZCBvdGhl cnMgZnJvbSBhIFRFRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgZG8g bGlrZSB0aGlzIHByb3Bvc2FsLCBJIGhvcGUgd2UgY2FuIGRpc2N1c3Mgc29tZSBleHRlbnNpb25z IHRvIG1ha2UgaXQgbW9yZSBleHRlbnNpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5EYXZlIFdoZWVsZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0i X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfX19fX3JlcGx5c2VwYXJhdG9yIj48L2E+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dCI+IEVBVCBbbWFpbHRvOmVhdC1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5IYW5uZXMgVHNjaG9mZW5pZzxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSnVuZSAyMSwgMjAxOCAxMTowNyBQTTxicj4NCjxiPlRvOjwvYj4gRWxpb3QgTGVh ciAmbHQ7bGVhckBjaXNjby5jb20mZ3Q7OyBvYXV0aEBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4g ZWF0QGlldGYub3JnOyBMYXVyZW5jZSBMdW5kYmxhZGUgJmx0O2xnbEBpc2xhbmQtcmVzb3J0LmNv bSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtFQVRdIFtPQVVUSC1XR10gU3RhbmRhcmRp emluZyBBdHRlc3RhdGlvbiBUb2tlbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkg Z3Vlc3MgdGhpcyBpcyBhIHBpZWNlIG9mIGluZm8gd2Ugc2hvdWxkIGhhdmUgbWVudGlvbmVkIHNv bWV3aGVyZS4gWWVzLCB0aGUgaWRlYSBpcyB0byB1c2UgYSBURUUgZm9yIHRoYXQgcHVycG9zZS4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QXQgbGVhc3QgZm9yIEFybSwgVHJ1c3Rab25l IGZvciB2OC1NIGV2ZW4gYnJpbmdzIFRFRSBjYXBhYmlsaXRpZXMgdG8gdGhlIGxvdy1lbmQgSW9U IGRldmljZXMgYW5kIHRoZSBmaXJzdCBwcm9kdWN0cyBhcmUgYWxyZWFkeSBvbiB0aGUgbWFya2V0 Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkNpYW88YnI+DQpIYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+IEVsaW90 DQogTGVhciBbPGEgaHJlZj0ibWFpbHRvOmxlYXJAY2lzY28uY29tIj5tYWlsdG86bGVhckBjaXNj by5jb208L2E+XSA8YnI+DQo8Yj5TZW50OjwvYj4gMjIgSnVuZSAyMDE4IDA3OjAyPGJyPg0KPGI+ VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzsgPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn Ij5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IExhdXJlbmNlIEx1bmRibGFkZTsg PGEgaHJlZj0ibWFpbHRvOmVhdEBpZXRmLm9yZyI+ZWF0QGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTdGFuZGFyZGl6aW5nIEF0dGVzdGF0aW9uIFRva2Vu czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4tR0IiPkJ5IHRoZSB3YXksIGEgbG90ICpoYXMqIGNoYW5nZWQuJm5ic3A7 IElmIHdlIGNhbiB1c2UgdGhlIFRFRSB0byBnZXQgc2lnbmVkIGluZm9ybWF0aW9uIG91dC4uLiBp ZiAqaXQqIGlzIHRoZSBhdHRlc3RlciwgdGhhdCdzIGEgcHJldHR5IGJpZyBiZW5lZml0LiZuYnNw OyBUaGF0IGp1c3QgbGVhdmVzIHRoZSBwcm90b2NvbCBnb3JwLiZuYnNwOyBCdXQgb25lIG5lZWRz IHRvIGtub3cgdGhhdCB0aGVyZSBpcyBhIFRFRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5P biAyMS4wNi4xOCAyMjowNCwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhdOKAmXMgYSBnb29kIHF1ZXN0aW9uLCBFbGlvdC4g TGV0IG1lIHB1dCBzb21ldGhpbmcgdG9nZXRoZXIgZm9yIHRoZSBJRVRGIG1lZXRpbmcNCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1HQiI+IEVsaW90DQogTGVhciBbPGEgaHJlZj0ibWFpbHRvOmxlYXJAY2lzY28u Y29tIj5tYWlsdG86bGVhckBjaXNjby5jb208L2E+XSA8YnI+DQo8Yj5TZW50OjwvYj4gMjEgSnVu ZSAyMDE4IDIwOjE3PGJyPg0KPGI+VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzsgPGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+ IExhdXJlbmNlIEx1bmRibGFkZTsgPGEgaHJlZj0ibWFpbHRvOmVhdEBpZXRmLm9yZyI+ZWF0QGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBTdGFuZGFyZGl6 aW5nIEF0dGVzdGF0aW9uIFRva2Vuczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5n PSJFTi1HQiI+SGkgSGFubmVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLUdCIj5UaGUgZHJhZnQgaXMgaW50ZXJlc3RpbmcsIGJ1dCBpdCBsb29rcyBhIGJpdCBsaWtl IE5FQS4mbmJzcDsgSG93IHdvdWxkIHRoaXMgdmFyeSwgYXBhcnQgZnJvbSB0aGUgQ29BUCBwYXJ0 IGFuZCBhIGRpZmZlcmVudCByZWdpc3RyeT8mbmJzcDsgU2VlbXMgdG8gbWUgdGhlIHJlYWwgbWFn aWMgaXMgaG93IHRoZSBkZXZpY2UgaXMgaW50ZXJyb2dhdGVkIHN1Y2ggdGhhdCB0aGUgY29uc3Vt ZXIgb2YgdGhpcyBpbmZvcm1hdGlvbiBoYXMNCiBjb25maWRlbmNlIGFzIHRvIGl0cyB2YWxpZGl0 eS4mbmJzcDsgVGhlIHByb3RvY29sIGJpdHMgYXJlIHRoZSBlYXN5IHBhcnQuJm5ic3A7IElmIHBl b3BsZSBoYXZlIHNvbWUgdW5kZXJzdGFuZGluZyBvZiB0aGF0IG1hZ2ljIGFuZCBhcmUgd2lsbGlu ZyB0byBzaGFyZSwgdGhlbiB0aGlzIHdvcmsgYmVjb21lcyBjb25zaWRlcmFibHkgbW9yZSBpbnRl cmVzdGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1HQiI+RWxp b3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiAyMS4wNi4xOCAxNzoxMSwgSGFubmVzIFRz Y2hvZmVuaWcgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5IaSBhbGwsIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1H QiI+SSB3b3VsZCBsaWtlIHRvIG1ha2UgeW91IGF3YXJlIG9mIHdvcmsgdGhhdCB3aWxsIGJlIGRp c2N1c3NlZCBvbiBhdHRlc3RhdGlvbiBvbiB0aGUgRUFUIG1haWxpbmcgbGlzdC4gSGVyZSBpcyB0 aGUgbGluayB0byB0aGUgbGlzdDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2VhdCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9lYXQ8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5IZXJlIGlzIGEgZG9jdW1lbnQgZGVzY3Jp YmluZyB0aGUgaWRlYTogPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LW1hbmR5YW0tZWF0LTAwIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbWFuZHlhbS1lYXQtMDA8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgd29yayBpcyByZWxl dmFudCBmb3IgSW9UIGFuZCBub24tSW9UIGRldmljZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPkxh dXJlbmNlIGFuZCBJIGFyZSBwbGFubmluZyB0byBvcmdhbml6ZSBhIEJhciBCT0YgYXQgdGhlIE1v bnRyZWFsIElFVEYgbWVldGluZyB0byBlbnRlcnRhaW4gdGhlIGlkZWEuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiPkNpYW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiI+SGFubmVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50 cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeQ0KIHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkg cHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4g VGhhbmsgeW91Lg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLUdCIj48YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5JTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZQ0KIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0u IFRoYW5rIHlvdS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6d2luZG93 dGV4dCI+SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFu eSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2Vk LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LA0KIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBj b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0627F5240443D2498FAA65332EE46C843B65778ECRSMSX101amrcor_-- From nobody Fri Jun 22 09:00:48 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4137130EA6 for ; Fri, 22 Jun 2018 09:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO4B1kLpYycz for ; Fri, 22 Jun 2018 09:00:41 -0700 (PDT) Received: from p3plsmtpa12-02.prod.phx3.secureserver.net (p3plsmtpa12-02.prod.phx3.secureserver.net [68.178.252.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F5D130EBF for ; Fri, 22 Jun 2018 09:00:30 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id WOU8fg0SMh8ZdWOU9fGhQe; Fri, 22 Jun 2018 09:00:29 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_47153D2B-A84D-49B3-9441-774CF754E27D" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 22 Jun 2018 09:00:28 -0700 In-Reply-To: <0627F5240443D2498FAA65332EE46C843B65778E@CRSMSX101.amr.corp.intel.com> Cc: Hannes Tschofenig , Eliot Lear , "oauth@ietf.org" , "eat@ietf.org" To: "Wheeler, David M" References: <0627F5240443D2498FAA65332EE46C843B65778E@CRSMSX101.amr.corp.intel.com> X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfJgsmQiLMVYRqNarep1h/slF0rf8E1ItjOOWCEhL5wTBFMtQzTttGf8Pz2rlcJmJOc4MZ20auxWOxxiCHCAibYFoTacCsMDqsyYGgOgB6jpO5fhhtXqR K2TypeX9fNQG/ta0yNJ5fVWhcX+OUkPPp7LR1gDqm2cKRgRhXlvYO878uHGO/q2TeYvb7QSQtSCN/qq57OJi+M9qFJBNkBXxMo0VC/REz721GNP9nw++ZZiC IzshAhUN8CAYDLKm5DBHWfTJa5zOLqjdznviZkEtQACoXz9rZ1RDk0vWs2SK66YS Archived-At: Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:00:46 -0000 --Apple-Mail=_47153D2B-A84D-49B3-9441-774CF754E27D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 22, 2018, at 7:02 AM, Wheeler, David M = wrote: >=20 > Laurence, > It is good to hear your name again! I look forward to seeing you in = Montreal. Yes, good to hear from you too! > I have skimmed through the proposal, but I still need to read it more = deeply and carefully =E2=80=93 please excuse me if I missed something in = the reading. > =20 > What seems to be missing from the proposed structure is the ability to = attach new key material into the EAT structure, with an attestation = claim. The attestation claim can be that it was generated on the device, = or generated inside the TEE and bound/sealed to the TEE. And perhaps = even a purpose for the key material. A new attestation key, for example; = or a special signing/authorization key for a particular application. > =20 > Many times, IMHO, it is useful to generate a new key that is attested = in some way, and then future operations use that key. In fact, OTrP/TEEP = has this implication, with the AIK keys for new installed Apps, but = (IMO) it is not really that clearly spelled out, although I think the = intention is clear. You are completely right and I completely agree. Was / is just a matter = of doing the writing.=20 Some have proposed inserting a CSR. That seems OK, but should be able to = carry a bare public key too as CSRs are ASN.1 and we=E2=80=99d like to = avoid that. The bare key should use the COSE formats for representing = RSA, EC and other key types. > =20 > Other attestation claims are also useful =E2=80=93 the identity and = cryptographic hash of the code of a particular TEE application; Agree on this too. I have some text for a =E2=80=9Cmeasurement=E2=80=9D = claim that is not in the current draft.=20 > a DH public key to establish an encrypted channel; the set of root = CA=E2=80=99s this TEE will trust; =E2=80=A6 Sure. > =20 > One additional thing that I would like to see is perhaps a more = generic way to extend or add a claim into the attestation structure. = After all, the attestation is just a container, that is signed, which = carries some claims. But for these claims to be true, the claims must be = constructed in a way that would be trusted by a verifier. Additional = data for the verifier to understand how the claims are constructed = (which may be inferred by the origination information), but may need = more data, as some claims (for secure boot) may come from the TPM, and = others from a TEE. Anyone can add any claim they want. The only real rule is that = non-standard claims must use a label in the proprietary range. The association of data with the security level is one the biggest = design issue I=E2=80=99ve struggled with. The submods claim is the = current thinking. See example A.2. LL > =20 > I do like this proposal, I hope we can discuss some extensions to make = it more extensible. > =20 > Thanks, > Dave Wheeler > =C2=A0 <> > <>From: EAT [mailto:eat-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Thursday, June 21, 2018 11:07 PM > To: Eliot Lear ; oauth@ietf.org > Cc: eat@ietf.org; Laurence Lundblade > Subject: Re: [EAT] [OAUTH-WG] Standardizing Attestation Tokens > =20 > I guess this is a piece of info we should have mentioned somewhere. = Yes, the idea is to use a TEE for that purpose. > At least for Arm, TrustZone for v8-M even brings TEE capabilities to = the low-end IoT devices and the first products are already on the = market. > =20 > Ciao > Hannes > =20 > From: Eliot Lear [mailto:lear@cisco.com ]=20 > Sent: 22 June 2018 07:02 > To: Hannes Tschofenig; oauth@ietf.org > Cc: Laurence Lundblade; eat@ietf.org > Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens > =20 > By the way, a lot *has* changed. If we can use the TEE to get signed = information out... if *it* is the attester, that's a pretty big benefit. = That just leaves the protocol gorp. But one needs to know that there = is a TEE. >=20 > =20 > On 21.06.18 22:04, Hannes Tschofenig wrote: > That=E2=80=99s a good question, Eliot. Let me put something together = for the IETF meeting > =20 > From: Eliot Lear [mailto:lear@cisco.com ]=20 > Sent: 21 June 2018 20:17 > To: Hannes Tschofenig; oauth@ietf.org > Cc: Laurence Lundblade; eat@ietf.org > Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens > =20 > Hi Hannes, >=20 > The draft is interesting, but it looks a bit like NEA. How would this = vary, apart from the CoAP part and a different registry? Seems to me = the real magic is how the device is interrogated such that the consumer = of this information has confidence as to its validity. The protocol = bits are the easy part. If people have some understanding of that magic = and are willing to share, then this work becomes considerably more = interesting. >=20 > Eliot >=20 > =20 > On 21.06.18 17:11, Hannes Tschofenig wrote: > Hi all, > =20 > I would like to make you aware of work that will be discussed on = attestation on the EAT mailing list. Here is the link to the list: > https://www.ietf.org/mailman/listinfo/eat = > =20 > Here is a document describing the idea: > https://tools.ietf.org/html/draft-mandyam-eat-00 = > =20 > The work is relevant for IoT and non-IoT devices. > =20 > Laurence and I are planning to organize a Bar BOF at the Montreal IETF = meeting to entertain the idea. > =20 > Ciao > Hannes > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you.=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. > =20 > IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. --Apple-Mail=_47153D2B-A84D-49B3-9441-774CF754E27D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jun 22, 2018, at 7:02 AM, Wheeler, David M <david.m.wheeler@intel.com> wrote:

Laurence,

It is good to hear your name again! I = look forward to seeing you in = Montreal.


Yes, good to hear from you too!


I have = skimmed through the proposal, but I still need to read it more deeply = and carefully =E2=80=93 please excuse me if I missed something in the = reading.

 

What seems to be missing from the = proposed structure is the ability to attach new key material into the = EAT structure, with an attestation claim. The attestation claim can be = that it was generated on the device, or generated inside the TEE and bound/sealed to the TEE. And perhaps = even a purpose for the key material. A new attestation key, for example; = or a special signing/authorization key for a particular application.

 

Many times, IMHO, it is useful to = generate a new key that is attested in some way, and then future = operations use that key. In fact, OTrP/TEEP has this implication, with = the AIK keys for new installed Apps, but (IMO) it is not really that clearly spelled out, although I think the = intention is clear.


You are completely right and I completely agree. =  Was / is just a matter of doing the writing. 

Some have proposed inserting a CSR. That seems OK, = but should be able to carry a bare public key too as CSRs are ASN.1 and = we=E2=80=99d like to avoid that.  The bare key should use the COSE = formats for representing RSA, EC and other key types.


 

Other attestation claims are also = useful =E2=80=93 the identity and cryptographic hash of the code of a = particular TEE application; =


Agree on this too. I have some text for a = =E2=80=9Cmeasurement=E2=80=9D claim that is not in the current = draft. 


a DH public key to establish an = encrypted channel; the set of root CA=E2=80=99s this TEE will trust; =E2=80=A6


Sure.

 

One additional thing that I would = like to see is perhaps a more generic way to extend or add a claim into = the attestation structure. After all, the attestation is just a = container, that is signed, which carries some claims. But for these claims to be true, the claims must be = constructed in a way that would be trusted by a verifier. Additional = data for the verifier to understand how the claims are constructed = (which may be inferred by the origination information), but may need more data, as some claims (for secure boot) may come from = the TPM, and others from a = TEE.


Anyone can add any claim they want. The only real = rule is that non-standard claims must use a label in the proprietary = range.

The association of data with = the security level is one the biggest design issue I=E2=80=99ve = struggled with. The submods claim is the current thinking. See example = A.2.

LL


 

I do like this proposal, I hope we = can discuss some extensions to make it more extensible.

 

Thanks,

Dave Wheeler

 

From: EAT [mailto:eat-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Thursday, June 21, 2018 11:07 PM
To: Eliot Lear <lear@cisco.com>; oauth@ietf.org
Cc: eat@ietf.org; Laurence Lundblade <lgl@island-resort.com>
Subject: Re: [EAT] [OAUTH-WG] Standardizing = Attestation Tokens

 

I guess this is a piece of info we should have mentioned = somewhere. Yes, the idea is to use a TEE for that purpose.

At least for Arm, = TrustZone for v8-M even brings TEE capabilities to the low-end IoT = devices and the first products are already on the market.

 

Ciao
Hannes

 

From: Eliot Lear [mailto:lear@cisco.com]
Sent: 22 June 2018 07:02
To: Hannes Tschofenig; oauth@ietf.org
Cc: Laurence Lundblade; eat@ietf.org
Subject: Re: [OAUTH-WG] Standardizing Attestation = Tokens

 

By the way, a lot *has* changed.  If we can use the TEE = to get signed information out... if *it* is the attester, that's a = pretty big benefit.  That just leaves the protocol gorp.  But = one needs to know that there is a TEE.

 

On = 21.06.18 22:04, Hannes Tschofenig wrote:

That=E2=80=99s a good question, Eliot. Let me put something = together for the IETF meeting

 

From: Eliot Lear [mailto:lear@cisco.com]
Sent: 21 June 2018 20:17
To: Hannes Tschofenig; oauth@ietf.org
Cc: Laurence Lundblade; eat@ietf.org
Subject: Re: [OAUTH-WG] Standardizing Attestation = Tokens

 

Hi Hannes,

The draft is interesting, but it looks a bit = like NEA.  How would this vary, apart from the CoAP part and a = different registry?  Seems to me the real magic is how the device = is interrogated such that the consumer of this information has confidence as to its validity.  The protocol bits are the easy = part.  If people have some understanding of that magic and are = willing to share, then this work becomes considerably more = interesting.

Eliot

 

On = 21.06.18 17:11, Hannes Tschofenig wrote:

Hi all,

 

I would like to make = you aware of work that will be discussed on attestation on the EAT = mailing list. Here is the link to the list:

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

 

Here is a document = describing the idea:

https://tools.ietf.org/html/draft-mandyam-eat-00

 

The work is relevant = for IoT and non-IoT devices.

 

Laurence and I are = planning to organize a Bar BOF at the Montreal IETF meeting to entertain = the idea.

 

Ciao

Hannes

IMPORTANT NOTICE: The contents of = this email and any attachments are confidential and may also be = privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other = person, use it for any purpose, or store or copy the information in any = medium. Thank you. 


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

 

IMPORTANT = NOTICE: The contents of this email and any attachments are confidential = and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not = disclose the contents to any other person, use it for any purpose, or = store or copy the information in any medium. Thank you.

 

IMPORTANT NOTICE: The = contents of this email and any attachments are confidential and may also = be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents = to any other person, use it for any purpose, or store or copy the = information in any medium. Thank you.


= --Apple-Mail=_47153D2B-A84D-49B3-9441-774CF754E27D-- From nobody Fri Jun 22 09:13:04 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9EB130EC1 for ; Fri, 22 Jun 2018 09:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzQbWrPR1fqB for ; Fri, 22 Jun 2018 09:12:46 -0700 (PDT) Received: from p3plsmtpa11-07.prod.phx3.secureserver.net (p3plsmtpa11-07.prod.phx3.secureserver.net [68.178.252.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D05130ED1 for ; Fri, 22 Jun 2018 09:12:45 -0700 (PDT) Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id WOfzfGXYVneOrWOg0fkIsb; Fri, 22 Jun 2018 09:12:44 -0700 From: Laurence Lundblade Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2F9B1D9D-FDF3-4E72-A8EC-8B8DE08404E9" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 22 Jun 2018 09:12:43 -0700 In-Reply-To: Cc: Hannes Tschofenig , "oauth@ietf.org" , "eat@ietf.org" To: Eliot Lear References: X-Mailer: Apple Mail (2.3445.8.2) X-CMAE-Envelope: MS4wfGajTZWsXr5ArTO6Tnrzv2bomeRYtVzFXXnrpbqQ2XPylxsoTisO1Jb+JBVn2lQU/Xoab3gsZc3csuS0B4aZ6MjQuvpHxr2W+dRr01+8kpbc9jnfXUIR UmUuXr2zK10exGxryRCqmruvzZdYSB2ZuoeRkmdAUXn5eW0vm4vhcGq5iqTJBt29oqCrHpNxlA3DUf1lYQiPXj6+GbIQIctOwXVPDGnGqeY+ET6P9AdLDcW5 TtmBXWoseK2+NIHcngZb5w== Archived-At: Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:12:58 -0000 --Apple-Mail=_2F9B1D9D-FDF3-4E72-A8EC-8B8DE08404E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Android Key Attestation = = does this today. It is part of the Android Keystore that is usually = implemented in the TEE. This feature is on Android P (maybe O too, I = can=E2=80=99t recall for sure).=20 It implements some of the same functionality as EAT, but uses an X.509 = certificate for syntax. All the claims are in the X.509 v3 extensions in = ASN.1 format. It is very oriented around key attestation as David = requested the addition of. See here = . LL =20 > On Jun 21, 2018, at 11:02 PM, Eliot Lear wrote: >=20 > By the way, a lot *has* changed. If we can use the TEE to get signed = information out... if *it* is the attester, that's a pretty big benefit. = That just leaves the protocol gorp. But one needs to know that there = is a TEE. >=20 >=20 > On 21.06.18 22:04, Hannes Tschofenig wrote: >> That=E2=80=99s a good question, Eliot. Let me put something together = for the IETF meeting >> =C2=A0 <> >> From: Eliot Lear [mailto:lear@cisco.com ]=20 >> Sent: 21 June 2018 20:17 >> To: Hannes Tschofenig; oauth@ietf.org >> Cc: Laurence Lundblade; eat@ietf.org >> Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens >> =20 >> Hi Hannes, >>=20 >> The draft is interesting, but it looks a bit like NEA. How would = this vary, apart from the CoAP part and a different registry? Seems to = me the real magic is how the device is interrogated such that the = consumer of this information has confidence as to its validity. The = protocol bits are the easy part. If people have some understanding of = that magic and are willing to share, then this work becomes considerably = more interesting. >>=20 >> Eliot >>=20 >> =20 >> On 21.06.18 17:11, Hannes Tschofenig wrote: >> Hi all,=20 >> =20 >> I would like to make you aware of work that will be discussed on = attestation on the EAT mailing list. Here is the link to the list: >> https://www.ietf.org/mailman/listinfo/eat = >> =20 >> Here is a document describing the idea:=20 >> https://tools.ietf.org/html/draft-mandyam-eat-00 = >> =20 >> The work is relevant for IoT and non-IoT devices.=20 >> =20 >> Laurence and I are planning to organize a Bar BOF at the Montreal = IETF meeting to entertain the idea. >> =20 >> Ciao >> Hannes >> IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you.=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >> IMPORTANT NOTICE: The contents of this email and any attachments are = confidential and may also be privileged. If you are not the intended = recipient, please notify the sender immediately and do not disclose the = contents to any other person, use it for any purpose, or store or copy = the information in any medium. Thank you. >=20 >=20 --Apple-Mail=_2F9B1D9D-FDF3-4E72-A8EC-8B8DE08404E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Android Key Attestation does this today. It = is part of the Android Keystore that is usually implemented in the TEE. = This feature is on Android P (maybe O too, I can=E2=80=99t recall for = sure). 

It = implements some of the same functionality as EAT, but uses an X.509 = certificate for syntax. All the claims are in the X.509 v3 extensions in = ASN.1 format. It is very oriented around key attestation as David = requested the addition of. See here.

LL
 


On Jun 21, 2018, at 11:02 PM, = Eliot Lear <lear@cisco.com> wrote:

By the way, a lot *has* = changed.  If we can use the TEE to get signed information out... if = *it* is the attester, that's a pretty big benefit.  That just = leaves the protocol gorp.  But one needs to know that there is a = TEE.


On = 21.06.18 22:04, Hannes Tschofenig wrote:
That=E2=80=99s a good = question, Eliot. Let me put something together for the IETF meeting
 
From: Eliot Lear [mailto:lear@cisco.com] 
Sent: 21 = June 2018 20:17
To: Hannes Tschofenig; oauth@ietf.org
Cc: Laurence Lundblade; eat@ietf.org
Subject: Re: [OAUTH-WG] = Standardizing Attestation Tokens
 

Hi Hannes,

The draft = is interesting, but it looks a bit like NEA.  How would this vary, = apart from the CoAP part and a different registry?  Seems to me the = real magic is how the device is interrogated such that the consumer of = this information has confidence as to its validity.  The protocol = bits are the easy part.  If people have some understanding of that = magic and are willing to share, then this work becomes considerably more = interesting.

Eliot

 
On 21.06.18 17:11, Hannes = Tschofenig wrote:
Hi all, 
 
I would = like to make you aware of work that will be discussed on attestation on = the EAT mailing list. Here is the link to the list:
https://www.ietf.org/mailman/listinfo/eat
 
Here is a = document describing the idea: 
https://tools.ietf.org/html/draft-mandyam-eat-00
 
The work = is relevant for IoT and non-IoT devices. 
 
Laurence = and I are planning to organize a Bar BOF at the Montreal IETF meeting to = entertain the idea.
 
Ciao
Hannes
IMPORTANT NOTICE: = The contents of this email and any attachments are confidential and may = also be privileged. If you are not the intended recipient, please notify = the sender immediately and do not disclose the contents to any other = person, use it for any purpose, or store or copy the information in any = medium. Thank you. 


_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
IMPORTANT NOTICE: The contents = of this email and any attachments are confidential and may also be = privileged. If you are not the intended recipient, please notify the = sender immediately and do not disclose the contents to any other person, = use it for any purpose, or store or copy the information in any medium. = Thank you.



= --Apple-Mail=_2F9B1D9D-FDF3-4E72-A8EC-8B8DE08404E9-- From nobody Fri Jun 22 09:28:58 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29DD3130EAE for ; Fri, 22 Jun 2018 09:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZBOfh-T9HxF for ; Fri, 22 Jun 2018 09:28:52 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B425130EA9 for ; Fri, 22 Jun 2018 09:28:52 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fWOvX-0002Wg-4X; Fri, 22 Jun 2018 18:28:47 +0200 From: Torsten Lodderstedt Message-Id: <42293014-1A1C-42BC-AE5B-A4E10B4FB2EC@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_8AA127A2-0943-4514-8DE0-0745581F0704"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 22 Jun 2018 18:28:42 +0200 In-Reply-To: Cc: Brian Campbell , oauth To: Nat Sakimura References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> X-Mailer: Apple Mail (2.3445.8.2) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:28:57 -0000 --Apple-Mail=_8AA127A2-0943-4514-8DE0-0745581F0704 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Nat, > Am 21.06.2018 um 10:35 schrieb Nat Sakimura : >=20 > It depends on the use case but if you are talking about payment etc., = putting the transaction details in the scope and sending it over the = regular RFC6749 redirect to the authorization server is inherently a bad = idea, as it is not protected.=20 Good point. One could carry the scope parameter as part of a signed = request object to cope with that issue. What do you think about that? >=20 > My preference by far is to set up a staging endpoint and push the = transaction intent into there. Then, do the authorization on that staged = transaction. Once that's done. I am OK with putting the reference to the = staged transaction in the scope parameter.=20 >=20 > The beauty of the "staging" strategy is that:=20 >=20 > 1) You can push pretty big payload to the staging endpoint as it is a = server to server thing;=20 > 2) You can do the "auth" and then later "capture" after shipping the = product strategy using the access token the client has obtained;=20 > 3) The content of the transaction is not exposed via URL nor = referrers.=20 I agree. That=E2=80=99s really powerful. But one should also admit the = client needs to prepare and send two more requests. In OB UK the client = first obtains an access token using the client credentials grant and = then creates the payment/account information resource.=20 best regards, Torsten.=20 >=20 > Best,=20 >=20 > Nat >=20 >=20 >=20 > On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell = wrote: > In my own personal and humble opinion, Torsten, what you describe as = "(1) Parameter is part of the scope value" is the most natural approach = and works without needing changes to, or going outside of, RFC6749 The = OAuth 2.0 Authorization Framework. There may be AS implementations that = have made assumption about scope values being static (I know of at least = one!) but that's an implementation/feature issue, which can change, and = not a spec issue. >=20 > The OIDC "claims" parameter is already a bit of a hairy beast and I = think using it and the ID Token to convey more dynamic = access/authorization is blurring the line between authorization and = authentication a bit much. Also, as others have pointed out, OIDC isn't = always in play - particularly for regular old authorization cases. =20 >=20 > An additional query parameter might be simple for a one-off case but = it's nonstandard and not very repeatable.=20 >=20 >=20 > On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt = wrote: > Hi all, >=20 > I have been working lately on use cases where OAuth is used to = authorize transactions in the financial sector and electronic signing. = What I learned is there is always the need to pass resource ids (e.g. = account numbers) or transaction-specific values (e.g. amount or hash to = be signed) to the OAuth authorization process to further qualify the = scope of the requested access token.=20 >=20 > It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor = =E2=80=9Esign=E2=80=9C, won=E2=80=99t do the job. For example in case of = electronic signing, one must bind the authorization/access token to a = particular document, typically represented by its hash. >=20 > I would like to get your feedback on what you consider a good practice = to cope with that challenge. As a starting point for a discussion, I = have assembled a list of patterns I have seen in the wild (feel free to = extend).=20 >=20 > (1) Parameter is part of the scope value, e.g. = =E2=80=9Esign:=E2=80=9C or = "payments:" - I think this is an obvious way to = represent such parameters in OAuth, as it extends the scope parameter, = which is intended to represent the requested scope of an access token. I = used this pattern in the OAuth SCA mode in Berlin Group's PSD API.=20 >=20 > (2) One could also use additional query parameter to add further = details re the requested authorization, e.g.=20 >=20 > GET /authorize? > ..... > &scope=3Dsign > ..... >=20 > &hash_to_be_signed=3D >=20 > It seems to be robust (easier to implement?) but means the scope only = represents the static part of the action. The AS needs to look into a = further parameter to fully understand the requested authorization.=20 >=20 > (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80=9C= parameter to carry additional data.=20 >=20 > Example: =20 >=20 > "claims": { > "id_token": { > "acr": { > "essential": true, > "value": "..." > }, > "hash_to_be_signed": { > "essential": true, > "value": "" > } > }, > "userinfo": { > "hash_to_be_signed": { > "essential": true, > "value": "" > } > } > } >=20 > I=E2=80=98m looking forward for your feedback. Please also indicated = whether you think we should flush out a BCP on that topic.=20 >=20 > kind regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank = you._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 > Nat Sakimura >=20 > Chairman of the Board, OpenID Foundation >=20 --Apple-Mail=_8AA127A2-0943-4514-8DE0-0745581F0704 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNjIyMTYyODQyWjAjBgkqhkiG9w0BCQQxFgQU7/WYCUCO4rm0 qrAPpNNAjt29jIgwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBALRXh2GcNCpOKVQ2FzQTPqHvLV/STjNrsBBk8oV72755KT9Wnxv9 TBqS5yOeEHxMjHPHTRQS+Rf2HjT6LbZ4pAGL4w08UWEgEGL8rDFDKqlAxvbxHSeIht2gmsxqasvq o6WqB+AqT2eYdI8WrHnoqKV1p1UZJOhE9BZiM0LlC6XK/YonxFDmy32KzJdsqEWD5NDQwQt8fH9j moaMNajkGjPd6QDi4QLTVDxfojQIAIp021iG6ft92LWJbLkRonFcuLKgabQQZEx0Y1iYQcYRI/Es 86gZkkePTCEqQ9vqry+Gg7Mx0pngQjgoEYTJMuP069jiqG2yZK+Dp/MRy8O4wmkAAAAAAAA= --Apple-Mail=_8AA127A2-0943-4514-8DE0-0745581F0704-- From nobody Fri Jun 22 09:56:51 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57AA130EAF for ; Fri, 22 Jun 2018 09:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zIVciR0UeB1 for ; Fri, 22 Jun 2018 09:56:43 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C86130EAC for ; Fri, 22 Jun 2018 09:56:42 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id y12-v6so2368948wrs.2 for ; Fri, 22 Jun 2018 09:56:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JgSpjUsOprMoNP6miArQDbGYQomIIBegmMFQuo3COEg=; b=o0fglJEhCnEHLiOhzO6HbBl6F4Mtt5/fMCVFyoG9E8AGM4JrzBkuOXwIMIhbh3ant1 aHKPUHjzwbk1ynAJfM/eqI5xe4ATvEJYiLMnKZUF5MVFldZJn3po9M1mEJTWC5SDVR0b MBh6sPp8JAmUATxOl880k3BLGuCMZsfcM5eAIpWbsmPRky0+nai7dytEbrXYrNUKysRw 4fdKFJ6sO9CbTPXRIOzN3sb6w5U2q19yXuD4iu3wGpNp08PXnk20AqKtu3KUJCq50KJW E760j5t0rdfTBvsnP/RobybqyCCfdYtj68nL2vk0UbYWM55nGGMDjSa3zTXOkEekPSB4 WUxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JgSpjUsOprMoNP6miArQDbGYQomIIBegmMFQuo3COEg=; b=uVN5uOHKHLlvt7Mzo3UpX9LIzBISF2nmNqZ3UU7IRKKpdUvuuwFcuB/YIIKRyytvSD Lph04rZ3Kzy+9NfLMaPEulE+47uoyPEC5Q1T1wVM01mzfqX5dvstx0O8bebwbkZGd1Fq VoHwzVRMOn0w0x2Bhx7+RJ4ilYIRm5kJQ+x6RYu3yzjqB5t1LWZtoeIYT26qYKPpL6GG 37yiSX/2EyAvLIXzv665kwul50Wdhp312SkY+aMDcozh07j3riT67QkZlIjkOlJ/eoDD oSLAk0MqPpU7EOx43or1ZHBnNY8PjMKyx908zHpI59xzNzj9zB4gAR2s55eiZzc0IboC ybuA== X-Gm-Message-State: APt69E3zok3AZhA1KDSX6617mixPyjp62Mf4hOpksJM52fdCzgohdAA5 TGAIvLph+vBEulnR/zEYMfY4wuiPSWfjxVTUagmaqg== X-Google-Smtp-Source: AAOMgpez5/YI2ooQD9Xp7Qeu7bIr6Rl5bxP5MaQeP19K5D2qIYDpn1ViY8qh/zVmJIkj8JEee3tAxPUQzbD7wJDdWwU= X-Received: by 2002:adf:c4f7:: with SMTP id o52-v6mr2239474wrf.173.1529686600950; Fri, 22 Jun 2018 09:56:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:bbc3:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 09:56:39 -0700 (PDT) In-Reply-To: <42293014-1A1C-42BC-AE5B-A4E10B4FB2EC@lodderstedt.net> References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> <42293014-1A1C-42BC-AE5B-A4E10B4FB2EC@lodderstedt.net> From: Nat Sakimura Date: Fri, 22 Jun 2018 12:56:39 -0400 Message-ID: To: Torsten Lodderstedt Cc: Brian Campbell , oauth Content-Type: multipart/alternative; boundary="00000000000077ac3a056f3dea4f" Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 16:56:49 -0000 --00000000000077ac3a056f3dea4f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten, Re: using request object Carrying the scope parameter in the request object solves the integrity issue. However, it does not solve the confidentiality issue unless you also encrypt it, and encryption is not so easy. Re: 2 extra roundtrips You can actually cut the extra roundtrips to one. In fact, you probably want to have the staging object to be signed to have it work as an evidence when something goes wrong, so you could rely on that for the client authentication purpose and that will be more efficient, IMHO. Yes, that will become essentially the request_uri model. Cheers, Nat 2018=E5=B9=B46=E6=9C=8822=E6=97=A5=E9=87=91=E6=9B=9C=E6=97=A5=E3=80=81Torst= en Lodderstedt=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8= =E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F: > Hi Nat, > > > Am 21.06.2018 um 10:35 schrieb Nat Sakimura : > > > > It depends on the use case but if you are talking about payment etc., > putting the transaction details in the scope and sending it over the > regular RFC6749 redirect to the authorization server is inherently a bad > idea, as it is not protected. > > Good point. One could carry the scope parameter as part of a signed > request object to cope with that issue. What do you think about that? > > > > > My preference by far is to set up a staging endpoint and push the > transaction intent into there. Then, do the authorization on that staged > transaction. Once that's done. I am OK with putting the reference to the > staged transaction in the scope parameter. > > > > The beauty of the "staging" strategy is that: > > > > 1) You can push pretty big payload to the staging endpoint as it is a > server to server thing; > > 2) You can do the "auth" and then later "capture" after shipping the > product strategy using the access token the client has obtained; > > 3) The content of the transaction is not exposed via URL nor referrers. > > I agree. That=E2=80=99s really powerful. But one should also admit the cl= ient > needs to prepare and send two more requests. In OB UK the client first > obtains an access token using the client credentials grant and then creat= es > the payment/account information resource. > > best regards, > Torsten. > > > > > Best, > > > > Nat > > > > > > > > On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell 40pingidentity.com@dmarc.ietf.org> wrote: > > In my own personal and humble opinion, Torsten, what you describe as > "(1) Parameter is part of the scope value" is the most natural approach a= nd > works without needing changes to, or going outside of, RFC6749 The OAuth > 2.0 Authorization Framework. There may be AS implementations that have ma= de > assumption about scope values being static (I know of at least one!) but > that's an implementation/feature issue, which can change, and not a spec > issue. > > > > The OIDC "claims" parameter is already a bit of a hairy beast and I > think using it and the ID Token to convey more dynamic access/authorizati= on > is blurring the line between authorization and authentication a bit much. > Also, as others have pointed out, OIDC isn't always in play - particularl= y > for regular old authorization cases. > > > > An additional query parameter might be simple for a one-off case but > it's nonstandard and not very repeatable. > > > > > > On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > > Hi all, > > > > I have been working lately on use cases where OAuth is used to authoriz= e > transactions in the financial sector and electronic signing. What I learn= ed > is there is always the need to pass resource ids (e.g. account numbers) o= r > transaction-specific values (e.g. amount or hash to be signed) to the OAu= th > authorization process to further qualify the scope of the requested acces= s > token. > > > > It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor= =E2=80=9Esign=E2=80=9C, won=E2=80=99t do > the job. For example in case of electronic signing, one must bind the > authorization/access token to a particular document, typically represente= d > by its hash. > > > > I would like to get your feedback on what you consider a good practice > to cope with that challenge. As a starting point for a discussion, I have > assembled a list of patterns I have seen in the wild (feel free to extend= ). > > > > (1) Parameter is part of the scope value, e.g. > =E2=80=9Esign:=E2=80=9C or "payments:" - I think > this is an obvious way to represent such parameters in OAuth, as it exten= ds > the scope parameter, which is intended to represent the requested scope o= f > an access token. I used this pattern in the OAuth SCA mode in Berlin > Group's PSD API. > > > > (2) One could also use additional query parameter to add further detail= s > re the requested authorization, e.g. > > > > GET /authorize? > > ..... > > &scope=3Dsign > > ..... > > > > &hash_to_be_signed=3D > > > > It seems to be robust (easier to implement?) but means the scope only > represents the static part of the action. The AS needs to look into a > further parameter to fully understand the requested authorization. > > > > (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80= =9C parameter to > carry additional data. > > > > Example: > > > > "claims": { > > "id_token": { > > "acr": { > > "essential": true, > > "value": "..." > > }, > > "hash_to_be_signed": { > > "essential": true, > > "value": "" > > } > > }, > > "userinfo": { > > "hash_to_be_signed": { > > "essential": true, > > "value": "" > > } > > } > > } > > > > I=E2=80=98m looking forward for your feedback. Please also indicated wh= ether you > think we should flush out a BCP on that topic. > > > > kind regards, > > Torsten. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited.= . > If you have received this communication in error, please notify the sende= r > immediately by e-mail and delete the message and any file attachments fro= m > your computer. Thank you._______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > > > Chairman of the Board, OpenID Foundation > > > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --00000000000077ac3a056f3dea4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Torsten,=C2=A0

Re: using request object
Carrying the scope parameter in the request object solves the i= ntegrity issue. However, it does not solve the confidentiality issue unless= you also encrypt it, and encryption is not so easy.=C2=A0

Re: 2 extra roundtrips
You can actually cut the extra ro= undtrips to one. In fact, you probably want to have the staging object to b= e signed to have it work as an evidence when something goes wrong, so you c= ould rely on that for the client authentication purpose and that will be mo= re efficient, IMHO. Yes, that will become essentially the request_uri model= .=C2=A0

Cheers,=C2=A0

Nat=

2018=E5=B9=B46=E6=9C=8822=E6=97=A5=E9=87=91=E6=9B=9C=E6=97= =A5=E3=80=81Torsten Lodderstedt<torsten@lodderstedt.net>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3= =81=8D=E3=81=BE=E3=81=97=E3=81=9F:
Hi Nat= ,

> Am 21.06.2018 um 10:35 schrieb Nat Sakimura <sakimura@gmail.com>:
>
> It depends on the use case but if you are talking about payment etc., = putting the transaction details in the scope and sending it over the regula= r RFC6749 redirect to the authorization server is inherently a bad idea, as= it is not protected.

Good point. One could carry the scope parameter as part of a signed request= object to cope with that issue. What do you think about that?

>
> My preference by far is to set up a staging endpoint and push the tran= saction intent into there. Then, do the authorization on that staged transa= ction. Once that's done. I am OK with putting the reference to the stag= ed transaction in the scope parameter.
>
> The beauty of the "staging" strategy is that:
>
> 1) You can push pretty big payload to the staging endpoint as it is a = server to server thing;
> 2) You can do the "auth" and then later "capture" = after shipping the product strategy using the access token the client has o= btained;
> 3) The content of the transaction is not exposed via URL nor referrers= .

I agree. That=E2=80=99s really powerful. But one should also admit the clie= nt needs to prepare and send two more requests. In OB UK the client first o= btains an access token using the client credentials grant and then creates = the payment/account information resource.

best regards,
Torsten.

>
> Best,
>
> Nat
>
>
>
> On Thu, Jun 21, 2018 at 6:59 AM Brian Campbell <bcampbell=3D40pingidentity.com@dmarc.ietf= .org> wrote:
> In my own personal and humble opinion, Torsten, what you describe as &= quot;(1) Parameter is part of the scope value" is the most natural app= roach and works without needing changes to, or going outside of, RFC6749 Th= e OAuth 2.0 Authorization Framework. There may be AS implementations that h= ave made assumption about scope values being static (I know of at least one= !) but that's an implementation/feature issue, which can change, and no= t a spec issue.
>
> The OIDC "claims" parameter is already a bit of a hairy beas= t and I think using it and the ID Token to convey more dynamic access/autho= rization is blurring the line between authorization and authentication a bi= t much. Also, as others have pointed out, OIDC isn't always in play - p= articularly for regular old authorization cases.=C2=A0
>
> An additional query parameter might be simple for a one-off case but i= t's nonstandard and not very repeatable.
>
>
> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
> Hi all,
>
> I have been working lately on use cases where OAuth is used to authori= ze transactions in the financial sector and electronic signing. What I lear= ned is there is always the need to pass resource ids (e.g. account numbers)= or transaction-specific values (e.g. amount or hash to be signed) to the O= Auth authorization process to further qualify the scope of the requested ac= cess token.
>
> It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Co= r =E2=80=9Esign=E2=80=9C, won=E2=80=99t do the job. For example in case of = electronic signing, one must bind the authorization/access token to a parti= cular document, typically represented by its hash.
>
> I would like to get your feedback on what you consider a good practice= to cope with that challenge. As a starting point for a discussion, I have = assembled a list of patterns I have seen in the wild (feel free to extend).=
>
> (1) Parameter is part of the scope value, e.g. =E2=80=9Esign:<hash_= to_be_signed>=E2=80=9C or "payments:<payment_resource_id>= ;" - I think this is an obvious way to represent such parameters in OA= uth, as it extends the scope parameter, which is intended to represent the = requested scope of an access token. I used this pattern in the OAuth SCA mo= de in Berlin Group's PSD API.
>
> (2) One could also use additional query parameter to add further detai= ls re the requested authorization, e.g.
>
> GET /authorize?
> .....
> &scope=3Dsign
> .....
>
> &hash_to_be_signed=3D<hash_to_be_signed>
>
> It seems to be robust (easier to implement?) but means the scope only = represents the static part of the action. The AS needs to look into a furth= er parameter to fully understand the requested authorization.
>
> (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2= =80=9C parameter to carry additional data.
>
> Example:=C2=A0
>
> "claims": {
>=C2=A0 =C2=A0 =C2=A0"id_token": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"acr": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"essential": = true,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"value": &quo= t;..."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"hash_to_be_signed": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"essential": = true,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"value": &quo= t;<hash_to_be_signed>"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0},
>=C2=A0 =C2=A0 =C2=A0"userinfo": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"hash_to_be_signed": {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"essential": = true,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"value": &quo= t;<hash_to_be_signed>"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>
> I=E2=80=98m looking forward for your feedback. Please also indicated w= hether you think we should flush out a BCP on that topic.
>
> kind regards,
> Torsten.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privil= eged material for the sole use of the intended recipient(s). Any review, us= e, distribution or disclosure by others is strictly prohibited..=C2=A0 If y= ou have received this communication in error, please notify the sender imme= diately by e-mail and delete the message and any file attachments from your= computer. Thank you._______________________________________________ > OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> --
> Nat Sakimura
>
> Chairman of the Board, OpenID Foundation
>



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

--00000000000077ac3a056f3dea4f-- From nobody Fri Jun 22 10:51:27 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02111130EBA for ; Fri, 22 Jun 2018 10:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EVs9IF1jcAs for ; Fri, 22 Jun 2018 10:51:13 -0700 (PDT) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F989130EB9 for ; Fri, 22 Jun 2018 10:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1529689872; bh=4JDshtI8nMTXvNQWKHMp4M6GqR4/zHdTYrfUhwL4GNo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=F5et6O6cHcJeLIM/rF108jW1KfNp5HuH4qxnGIe2UE4cx9x+ziDdelKNDRtEfFBMm65ieT15PTRJ+RI/JU6zKUMQDaMqMrbJFc06xws9Jx3jov5NW750df55TZLmv0DOmvmxvmEnt7n7nVJtLoL5veJVy+1VTpqRIEOVuqkD2fvQKvhcQ1Z0RIqHxGvkO0+WNec1M+oJaEtECBmvNXyHociofp5Jgwjta9pPE9D5iRenB8qmw171W2A4h8MfpSveptc1PK6xOl02YQbgTGPLBgY40A4LLU4pfpNXnRz1+Cgn2bgFd6ixb2dAFFgGMcTlqmcqN6KiaYxIA57gfALZ3g== X-YMail-OSG: m5YW91cVM1nuLSoK7ggSGNfHTxMX2.VOX6n1ANnu5ZiKpBe0lOmZ7jycqpE90Ia R_5_NPDvw5kXOiGjjGOiVdaEmmrhxX7sESeqna6kLfcolcjiZY36005f6fmW8X05GRnO0H1MCtg6 n0bNz8j_UVnuQRJr92TuLBSX9q.DDJsWxZM03xcz5u_gmdhKrcKca_4MU6HQjvpNbe36r8feDnrH hEXG6AhN1uyf6iiwzY.yMnwQ0kiei9iwDarV2Y3DYPqLOfs8w0UmwT0A78wpq2mD0jcrdD4FkZbA FPF3D7V0npN1.flgXXeqau2.j4i1w42Pz_GvYORNsjHh2ShITQqvbGw1wiykeUVLnzlEmOX8f.57 UWKrEZmT6OSrWsgc6HW5yhv0bjmG2sFnkHK0ILnudJrRA05.XJBxuf8U5bXjaJ5n0rGN1H6cNRQF ZAuUEJ0W269TrcXRnS7YhFPJh4eWgpwqAbLPiPngDSWxWcmA1Yg.TlTm1CyPekTMYBxR8grLRQ4g 3ZQCv6CIQpNHE1STeSpM_ALLQU_96.kaQsuutaDyqTjE2dZ1y9YA5x0v3P9lngHUFWnyMs_OTZxm zpceZDc5Lysbtg2u9TPl2eMFch_hJKQvX8hcDj4oX5KBm6YEar71_kqqrNJqzbMlORzxo7D_uYHf AneBmUcRwPXYfiseaPYvjKnM6LbWNtt3tWEQM_kvEIlHhmNysUaN0zsEZ13X17.WCpOipYRFSsxi VAkDI9QjJtQjSn3LyUZvr6UFjaRALp4MPK.s_eOlOaZnYHs3nOSRH7oIzb5hx7wS_ILBqMy0hFxf CCuzpwgR0qXw0vK4mRc30ZILQoO8OLAjrQTYRL5j9GqT4TA1HB4UsHe_fTbLJ5gWDLHQF1TNbNly 4dDKTKvofSPq45rexzByXN8AuOX0ZdV9wVXfx0EpA_aNtqeB9pnjOhzkCZiaT7Uc0cwSc2bTXFdr 2MDp45OlL1h9TKMEI6zhRIVbBeS96 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 22 Jun 2018 17:51:12 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp411.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8c63dc04a98f25548b6175346e6a43e7; Fri, 22 Jun 2018 17:51:08 +0000 (UTC) To: Brian Campbell , Torsten Lodderstedt Cc: oauth References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> From: George Fletcher Organization: AOL LLC Message-ID: Date: Fri, 22 Jun 2018 13:51:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2CB4B739AA28B7337007EA68" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 17:51:25 -0000 This is a multi-part message in MIME format. --------------2CB4B739AA28B7337007EA68 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I like the concept of parameterized scopes but I'm not sure they should be used for per-transaction use cases. It seems like the use cases presented are about operating on parameters specific to the transaction. Why are these part of the authorization flow? Is the goal to bind an access token to a particular transaction? If this is the case, would it not be better to either extend the refresh_token flow or may better yet, create a new grant_type that takes the refresh_token and additional "binding" parameters and then have that return the "bound" access token to be used for the transaction. Maybe this is similar to what Nat is describing with the staging API? Thanks, George On 6/20/18 5:58 PM, Brian Campbell wrote: > In my own personal and humble opinion, Torsten, what you describe as > "(1) Parameter is part of the scope value" is the most natural > approach and works without needing changes to, or going outside of, > RFC6749 The OAuth 2.0 Authorization Framework. There may be AS > implementations that have made assumption about scope values being > static (I know of at least one!) but that's an implementation/feature > issue, which can change, and not a spec issue. > > The OIDC "claims" parameter is already a bit of a hairy beast and I > think using it and the ID Token to convey more dynamic > access/authorization is blurring the line between authorization and > authentication a bit much. Also, as others have pointed out, OIDC > isn't always in play - particularly for regular old authorization cases. > > An additional query parameter might be simple for a one-off case but > it's nonstandard and not very repeatable. > > > On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt > > wrote: > > Hi all, > > I have been working lately on use cases where OAuth is used to > authorize transactions in the financial sector and electronic > signing. What I learned is there is always the need to pass > resource ids (e.g. account numbers) or transaction-specific values > (e.g. amount or hash to be signed) to the OAuth authorization > process to further qualify the scope of the requested access token. > > It is obvious a static scope value, such as „payment“or „sign“, > won’t do the job. For example in case of electronic signing, one > must bind the authorization/access token to a particular document, > typically represented by its hash. > > I would like to get your feedback on what you consider a good > practice to cope with that challenge. As a starting point for a > discussion, I have assembled a list of patterns I have seen in the > wild (feel free to extend). > > (1) Parameter is part of the scope value, e.g. > „sign:“ or "payments:" - I > think this is an obvious way to represent such parameters in > OAuth, as it extends the scope parameter, which is intended to > represent the requested scope of an access token. I used this > pattern in the OAuth SCA mode in Berlin Group's PSD API. > > (2) One could also use additional query parameter to add further > details re the requested authorization, e.g. > > GET /authorize? > ..... > &scope=sign > ..... > &hash_to_be_signed= > > It seems to be robust (easier to implement?) but means the scope > only represents the static part of the action. The AS needs to > look into a further parameter to fully understand the requested > authorization. > > (3) Open Banking UK utilizes the (OpenID Connect) „claims“ > parameter to carry additional data. > > Example: > > "claims": { >     "id_token": { >         "acr": { >             "essential": true, >             "value": "..." >           }, >         "hash_to_be_signed": { >             "essential": true, >             "value": "" >         } >     }, >     "userinfo": { >         "hash_to_be_signed": { >             "essential": true, >             "value": "" >         } >     } >   } > > I‘m looking forward for your feedback. Please also indicated > whether you think we should flush out a BCP on that topic. > > kind regards, > Torsten. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > /CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly > prohibited..  If you have received this communication in error, please > notify the sender immediately by e-mail and delete the message and any > file attachments from your computer. Thank you./ > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------2CB4B739AA28B7337007EA68 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I like the concept of parameterized scopes but I'm not sure they should be used for per-transaction use cases. It seems like the use cases presented are about operating on parameters specific to the transaction. Why are these part of the authorization flow?

Is the goal to bind an access token to a particular transaction? If this is the case, would it not be better to either extend the refresh_token flow or may better yet, create a new grant_type that takes the refresh_token and additional "binding" parameters and then have that return the "bound" access token to be used for the transaction.

Maybe this is similar to what Nat is describing with the staging API?

Thanks,
George

On 6/20/18 5:58 PM, Brian Campbell wrote:
In my own personal and humble opinion, Torsten, what you describe as "(1) Parameter is part of the scope value" is the most natural approach and works without needing changes to, or going outside of, RFC6749 The OAuth 2.0 Authorization Framework. There may be AS implementations that have made assumption about scope values being static (I know of at least one!) but that's an implementation/feature issue, which can change, and not a spec issue.

The OIDC "claims" parameter is already a bit of a hairy beast and I think using it and the ID Token to convey more dynamic access/authorization is blurring the line between authorization and authentication a bit much. Also, as others have pointed out, OIDC isn't always in play - particularly for regular old authorization cases. 

An additional query parameter might be simple for a one-off case but it's nonstandard and not very repeatable.


On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Hi all,

I have been working lately on use cases where OAuth is used to authorize transactions in the financial sector and electronic signing. What I learned is there is always the need to pass resource ids (e.g. account numbers) or transaction-specific values (e.g. amount or hash to be signed) to the OAuth authorization process to further qualify the scope of the requested access token.

It is obvious a static scope value, such as „payment“or „sign“, won’t do the job. For example in case of electronic signing, one must bind the authorization/access token to a particular document, typically represented by its hash.

I would like to get your feedback on what you consider a good practice to cope with that challenge. As a starting point for a discussion, I have assembled a list of patterns I have seen in the wild (feel free to extend).

(1) Parameter is part of the scope value, e.g. „sign:<hash_to_be_signed>“ or "payments:<payment_resource_id>" - I think this is an obvious way to represent such parameters in OAuth, as it extends the scope parameter, which is intended to represent the requested scope of an access token. I used this pattern in the OAuth SCA mode in Berlin Group's PSD API.

(2) One could also use additional query parameter to add further details re the requested authorization, e.g.

GET /authorize?
.....
&scope=sign
.....
&hash_to_be_signed=<hash_to_be_signed>

It seems to be robust (easier to implement?) but means the scope only represents the static part of the action. The AS needs to look into a further parameter to fully understand the requested authorization.

(3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry additional data.

Example: 

"claims": {
    "id_token": {
        "acr": {
            "essential": true,
            "value": "..."
          },
        "hash_to_be_signed": {
            "essential": true,
            "value": "<hash_to_be_signed>"
        }
    },
    "userinfo": {
        "hash_to_be_signed": {
            "essential": true,
            "value": "<hash_to_be_signed>"
        }
    }
  }

I‘m looking forward for your feedback. Please also indicated whether you think we should flush out a BCP on that topic.

kind regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited..  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. 

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

--------------2CB4B739AA28B7337007EA68-- From nobody Fri Jun 22 11:51:35 2018 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4522130EF0; Fri, 22 Jun 2018 11:51:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: oauth@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152969348561.3566.1750301117574553073@ietfa.amsl.com> Date: Fri, 22 Jun 2018 11:51:25 -0700 Archived-At: Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-binding-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 18:51:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol WG of the IETF. Title : OAuth 2.0 Token Binding Authors : Michael B. Jones Brian Campbell John Bradley William Denniss Filename : draft-ietf-oauth-token-binding-07.txt Pages : 31 Date : 2018-06-22 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT Authorization Grants, and JWT Client Authentication. This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-binding/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-oauth-token-binding-07 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-binding-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-binding-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 22 11:57:59 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5AC130EC5 for ; Fri, 22 Jun 2018 11:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ7bVNVIqTGt for ; Fri, 22 Jun 2018 11:57:55 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D398E130EC0 for ; Fri, 22 Jun 2018 11:57:54 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id l25-v6so6982644ioh.12 for ; Fri, 22 Jun 2018 11:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=AvT3GJXgSglWJ480CLjzJgXHQRpVBMiECmegpgDuU84=; b=c3ikCXJDg6LBva+468ETKu00lg7sLNrGVAET7uFUUFTQdhHZvHEzpUlm0X2MeHG5Ji dfzeSf21hwCHe6s8A4cJV/sR45zgNAYshZ2Yg2PcDZGbLrzhzKGWuT63xAh+WyJBUgvO aJFK3oANQzuuvCUPIisKyM8cDiriX74M30TKU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=AvT3GJXgSglWJ480CLjzJgXHQRpVBMiECmegpgDuU84=; b=IULCjX1cDUBAtwSJGAMHDmf9HnOHZWNf6Fp3dmENojHbikqf63exLkPZAxLEP38EOY bS8blnVeP8TscH4uSj2WOElfr5mFSckGv/wqOOHd32VHoAe+BZBGo3BdbriLBwNHj7xH xJ+bvOk4cNtKrBaCVLyoI1S/M8HKQU6l2W+FDtz5F/7IsNuDTZZp57m3C4KQTIqbNgYH DTKx30iiw8Nv7Rv2Tb9RShIzrH3V2ytb1u1C0GidHHN94rjqhVXLXCRs3JUSz3i3sTxp NTJoVZjCu7IG4FzujsqAeS22FyhQyJ8lHMNIQlv4o+gH3Je1DxjrkhJ82tgaNT8hYvQw z/4Q== X-Gm-Message-State: APt69E2uVPECLXbb/5J25v54qqX8j7ypJuylm75JbDgLVC+xrLQWl82H k8X4dHPW8jM/MA2qW9/dsIBwgLmoS+9f/+0gSqBAsvaL6nPIQULmV4+sckTC5P7+bl0IZoEmipB vwIFgopBLXALdRa/w X-Google-Smtp-Source: AAOMgpd+hnT6JB29CJW4MwDuRuN22ZXyCleYxcISyBBHpvMu3LDkblo6usmqLk4xj6wWabkBwe103TMDKez53dsr7lI= X-Received: by 2002:a6b:d90e:: with SMTP id r14-v6mr2422253ioc.247.1529693873755; Fri, 22 Jun 2018 11:57:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:9785:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 11:57:23 -0700 (PDT) In-Reply-To: References: <152969348582.3566.3051950788101413538.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Fri, 22 Jun 2018 12:57:23 -0600 Message-ID: To: oauth Content-Type: multipart/alternative; boundary="000000000000f5f26e056f3f9b48" Archived-At: Subject: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-token-binding-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 18:57:58 -0000 --000000000000f5f26e056f3f9b48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable -07 is a pretty minor update to OAuth 2.0 Token Binding. Changes copied from the doc history are listed below for easy/lazy reference. draft-ietf-oauth-token-binding-07 o Explicitly state that the base64url encoding of the tbh value doesn't include any trailing pad characters, line breaks, whitespace, etc. o Update to latest references for tokbind drafts and draft-ietf- oauth-discovery. o Update reference to Implementation Considerations in draft-ietf- tokbind-https, which is section 6 rather than 5. o Try to tweak text that references specific sections in other documents so that the HTML generated by the ietf tools doesn't link to the current document (based on old suggestion from Barry https://www.ietf.org/mail-archive/web/jose/current/msg04571.html). ---------- Forwarded message --------- From: Date: Fri, Jun 22, 2018 at 12:51 PM Subject: New Version Notification for draft-ietf-oauth-token-binding-07.txt A new version of I-D, draft-ietf-oauth-token-binding-07.txt has been successfully submitted by Brian Campbell and posted to the IETF repository. Name: draft-ietf-oauth-token-binding Revision: 07 Title: OAuth 2.0 Token Binding Document date: 2018-06-21 Group: oauth Pages: 31 URL: https://www.ietf.org/internet-drafts/draft-ietf-oauth-token= - binding-07.txt Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-bin ding/ Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-token-binding- 07 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-toke n-binding Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-token-= bi nding-07 Abstract: This specification enables OAuth 2.0 implementations to apply Token Binding to Access Tokens, Authorization Codes, Refresh Tokens, JWT Authorization Grants, and JWT Client Authentication. This cryptographically binds these tokens to a client's Token Binding key pair, possession of which is proven on the TLS connections over which the tokens are intended to be used. This use of Token Binding protects these tokens from man-in-the-middle and token export and replay attacks. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --000000000000f5f26e056f3f9b48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
-07 is a pretty minor update to OAuth 2.0 Token Bindi= ng. Changes copied from the doc history are listed below for easy/lazy refe= rence.


=C2=A0 draft-ietf-oauth= -token-binding-07

=C2=A0=C2=A0 o=C2=A0 Explicitly state that th= e base64url encoding of the tbh value
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 doe= sn't include any trailing pad characters, line breaks,
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 whitespace, etc.

=C2=A0=C2=A0 o=C2=A0 Update to l= atest references for tokbind drafts and draft-ietf-
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 oauth-discovery.

=C2=A0=C2=A0 o=C2=A0 Update reference = to Implementation Considerations in draft-ietf-
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 tokbind-https, which is section 6 rather than 5.

=C2=A0=C2=A0= o=C2=A0 Try to tweak text that references specific sections in other
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 documents so that the HTML generated by the = ietf tools doesn't
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 link to the curren= t document (based on old suggestion from Barry
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 https://www.ietf.org/mail-archive/web/jose/= current/msg04571.html).




---------- Forwarded message ---------
From= : <internet-drafts@ietf.org>
Date: Fri, Jun 22, 2= 018 at 12:51 PM
Subject: New Version Notification for draft-ietf-oauth-t= oken-binding-07.txt


A new version of I-D, draft-ietf-oauth-token-binding-07.txt
has been successfully submitted by Brian Campbell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-oauth-token-bindin= g
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A007
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OAuth 2.0 Token Binding
Document date:=C2=A0 2018-06-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 oauth
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 31
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-oa= uth-token-binding-07.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-oauth-token-bind= ing/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-ietf-oauth-token-binding-07 Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-oauth-token-= binding
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-to= ken-binding-07

Abstract:
=C2=A0 =C2=A0This specification enables OAuth 2.0 implementations to apply = Token
=C2=A0 =C2=A0Binding to Access Tokens, Authorization Codes, Refresh Tokens,= JWT
=C2=A0 =C2=A0Authorization Grants, and JWT Client Authentication.=C2=A0 Thi= s
=C2=A0 =C2=A0cryptographically binds these tokens to a client's Token B= inding key
=C2=A0 =C2=A0pair, possession of which is proven on the TLS connections ove= r which
=C2=A0 =C2=A0the tokens are intended to be used.=C2=A0 This use of Token Bi= nding
=C2=A0 =C2=A0protects these tokens from man-in-the-middle and token export = and
=C2=A0 =C2=A0replay attacks.




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

The IETF Secretariat



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --000000000000f5f26e056f3f9b48-- From nobody Fri Jun 22 13:31:59 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43F3130EEB for ; Fri, 22 Jun 2018 13:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTnPabUZdj8I for ; Fri, 22 Jun 2018 13:31:54 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE32130EE7 for ; Fri, 22 Jun 2018 13:31:54 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fWSil-00041V-46; Fri, 22 Jun 2018 22:31:51 +0200 From: Torsten Lodderstedt Message-Id: <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> Content-Type: multipart/signed; boundary="Apple-Mail=_67D602A6-C049-4871-B9DE-784830A235A4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Fri, 22 Jun 2018 22:31:45 +0200 In-Reply-To: Cc: Brian Campbell , oauth To: George Fletcher References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> X-Mailer: Apple Mail (2.3445.8.2) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 20:31:58 -0000 --Apple-Mail=_67D602A6-C049-4871-B9DE-784830A235A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi George,=20 > Am 22.06.2018 um 19:51 schrieb George Fletcher : >=20 > I like the concept of parameterized scopes but I'm not sure they = should be used for per-transaction use cases. It seems like the use = cases presented are about operating on parameters specific to the = transaction. Why are these part of the authorization flow? The access token is good for a certain transaction only. In case of a = electronic signature, the access token is bound to a certain document or = a set of documents. >=20 > Is the goal to bind an access token to a particular transaction? If = this is the case, would it not be better to either extend the = refresh_token flow or may better yet, create a new grant_type that takes = the refresh_token and additional "binding" parameters and then have that = return the "bound" access token to be used for the transaction. What would be the scope of such a refresh token?=20 >=20 > Maybe this is similar to what Nat is describing with the staging API? The staging API represents the data of a certain transaction in a = resource, which allows to parametrize the scope just with the identifier = of that resource. So the transaction data can be transmitted in a robust = fashion.=20 best regards, Torsten.=20 >=20 > Thanks, > George >=20 > On 6/20/18 5:58 PM, Brian Campbell wrote: >> In my own personal and humble opinion, Torsten, what you describe as = "(1) Parameter is part of the scope value" is the most natural approach = and works without needing changes to, or going outside of, RFC6749 The = OAuth 2.0 Authorization Framework. There may be AS implementations that = have made assumption about scope values being static (I know of at least = one!) but that's an implementation/feature issue, which can change, and = not a spec issue. >>=20 >> The OIDC "claims" parameter is already a bit of a hairy beast and I = think using it and the ID Token to convey more dynamic = access/authorization is blurring the line between authorization and = authentication a bit much. Also, as others have pointed out, OIDC isn't = always in play - particularly for regular old authorization cases. =20 >>=20 >> An additional query parameter might be simple for a one-off case but = it's nonstandard and not very repeatable.=20 >>=20 >>=20 >> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt = wrote: >> Hi all, >>=20 >> I have been working lately on use cases where OAuth is used to = authorize transactions in the financial sector and electronic signing. = What I learned is there is always the need to pass resource ids (e.g. = account numbers) or transaction-specific values (e.g. amount or hash to = be signed) to the OAuth authorization process to further qualify the = scope of the requested access token.=20 >>=20 >> It is obvious a static scope value, such as =E2=80=9Epayment=E2=80=9Cor= =E2=80=9Esign=E2=80=9C, won=E2=80=99t do the job. For example in case = of electronic signing, one must bind the authorization/access token to a = particular document, typically represented by its hash. >>=20 >> I would like to get your feedback on what you consider a good = practice to cope with that challenge. As a starting point for a = discussion, I have assembled a list of patterns I have seen in the wild = (feel free to extend).=20 >>=20 >> (1) Parameter is part of the scope value, e.g. = =E2=80=9Esign:=E2=80=9C or = "payments:" - I think this is an obvious way to = represent such parameters in OAuth, as it extends the scope parameter, = which is intended to represent the requested scope of an access token. I = used this pattern in the OAuth SCA mode in Berlin Group's PSD API.=20 >>=20 >> (2) One could also use additional query parameter to add further = details re the requested authorization, e.g.=20 >>=20 >> GET /authorize? >> ..... >> &scope=3Dsign >> ..... >> &hash_to_be_signed=3D >>=20 >> It seems to be robust (easier to implement?) but means the scope only = represents the static part of the action. The AS needs to look into a = further parameter to fully understand the requested authorization.=20 >>=20 >> (3) Open Banking UK utilizes the (OpenID Connect) =E2=80=9Eclaims=E2=80= =9C parameter to carry additional data.=20 >>=20 >> Example: =20 >>=20 >> "claims": { >> "id_token": { >> "acr": { >> "essential": true, >> "value": "..." >> }, >> "hash_to_be_signed": { >> "essential": true, >> "value": "" >> } >> }, >> "userinfo": { >> "hash_to_be_signed": { >> "essential": true, >> "value": "" >> } >> } >> } >>=20 >> I=E2=80=98m looking forward for your feedback. Please also indicated = whether you think we should flush out a BCP on that topic.=20 >>=20 >> kind regards, >> Torsten. >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >> CONFIDENTIALITY NOTICE: This email may contain confidential and = privileged material for the sole use of the intended recipient(s). Any = review, use, distribution or disclosure by others is strictly = prohibited.. If you have received this communication in error, please = notify the sender immediately by e-mail and delete the message and any = file attachments from your computer. Thank you.=20 >>=20 >> _______________________________________________ >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_67D602A6-C049-4871-B9DE-784830A235A4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILKDCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JW MA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UE AxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0y ODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9 Olg+nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXC A6RQyDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+ KQWWCo63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720Y pMPJQaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUC AwEAAaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5j b20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsG CCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNy dDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4IC AQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE 7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGk SDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFr jAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5 aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F 29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCP Upwv9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj 7fIvxqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9 cbm/vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6 EjGCA7owggO2AgEBMIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UE AxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIR AJIm1HcLmC2uYhZqknoSA5UwCQYFKw4DAhoFAKCCAeEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTgwNjIyMjAzMTQ2WjAjBgkqhkiG9w0BCQQxFgQUHopac/L9upgx Bp5EMFpYoIMX3Zcwgb4GCSsGAQQBgjcQBDGBsDCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENB IExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMIHABgsqhkiG9w0BCRACCzGBsKCBrTCB lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOV MA0GCSqGSIb3DQEBAQUABIIBALP6i9R4dZajdBF7Qp0HoQRFFo5EBtigYyTaFWeO8LekMQqBX0I2 dTOIE0E7r3qd8wKm0Ith5p8FbmRWlcJTEKWeDe8JPeTOXrBH662ylzae/Kg41zt5GTYejw5ejnke lmOs9MapD1FJuwtki39N0e5oLHNhhMgjedRmVAN6pDq8gVu3clk1qVBGvhaqVqoHwt/FgXg31d/k 3tVy3rT9rPwFszm+hKFn8Gj3RcZLgR+eKHXLCCwsiVwevMmcO4Gendo+mIBiAMBpsOauvmF2+YyX j5sA+zI/Ox5WEX7R+OVDllqvhqWd+L36zsN3tDzSEUZWPp/x7uuAtPWaW395b/wAAAAAAAA= --Apple-Mail=_67D602A6-C049-4871-B9DE-784830A235A4-- From nobody Fri Jun 22 14:08:14 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508C2130EF2 for ; Fri, 22 Jun 2018 14:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9QjIjvwIqJ1 for ; Fri, 22 Jun 2018 14:08:10 -0700 (PDT) Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0892130EEB for ; Fri, 22 Jun 2018 14:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1529701688; bh=pIcWKu/NxkDgTVyJCPwPImVTi77E8nBvrb0FHtSCzuI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=n+YekMO/DP0QEp7xhiQn3x/a2eJPvPW0frdJGzjGAQ8FKyw8w9FCtAZlD2TyennkgquMPK/Zl1wM20ykKX/w0drFTNsA9pyOzQgYskQBN41kxP/DUYUHNXQRQssR4Hi22q2aNCozcvGc4uwLB5FaPr/6Nz2JMNgNOopXES+Qb1+4ZJqvgwJszio6Yq/Ndgei8pK3XMR6dkeF5cXB0knne7+byDtQGc6X6CQWJPTxQv+R51lq0C+juIf2tlfkWTRL/1XiY1TvT80KHvVSeML7VCZw9h8IPkLbWEfIHoBRUO4ziDlg8+xphIDN0a0P1zyM/bAvpayyJmqVqY8/67HuQQ== X-YMail-OSG: qGkg2gMVM1nb9rd6VIm8rCdTfyQsTnGph16acJe0k4s0iKC1VeZ83dXIfzVZLKu JqHVYmQYYFYiJZ4OtJmKkZRQIcFOgRCUgyX885zsIMpOHPcZINvsFZ5J3IXGbgniI0fMKBEBvN9E ntGBEQiW4hCdqdLF01YG1OOAoFMPrQ1B52GVzx_pJ0M1wDzs09p78ydYqCTrCtw0FQuKKe1fdJbn LAcdm09ibi7uTkjsoicMqMXDFLVy.OYAjbhj8wix3F4enbUL.HAqPFOgIjFxCxuy0EK4f6VBr_Ec 59cx9YgqnKUpty9422bbvBaUdskYQxupcIfD5wwrpqwjBEhmbpKYi0nLY50GYqzHCS7JOCDhI1Ie zpNoo1w_zGUZsI_uJHECucTavRWALY6mEbXc..j5BJeYaUl20mqm.dsD_54igoiu0rDDiu8_lcaR d8Jscv.g_miOQNqEUzfF_LmIDhvYwpxy5JYfusrge6oWvj_1hZKzsuZpDDYTVTrfvEyhLqc2Rt3T PAVAMLZ_ElhmhxHWwe2JMdIzKZF2MFcNJIAzgblrAgAS3cdaojltkj_Sc32H6MuaoJAlPlFAqBzG XLAbC8rBIXQnQSsNusPXoeximljbC36_0Sy8RmuY6HzqleOA.YrbO_GBxUad0WhFdOUw4.YnvZDZ dfCL3njCKoMNwUQUeP6OykTxi3WwqlGo3bxmWL3G0Lx11MeKsKdshTwqK1V_l.13gGXjNaVtX9yZ L9MGSFRqgqqc1jCY4CXq4P6VCe3GuHoJJnttYvqbu3ME.xoy4Szdndrv0e0iwu438KSF6Nr7Wzat G7m8OmImLXklxfFOgWcS9dxHmbL6TsMlVZ.uKTZFNnj3yZQnEvfYFO0o1Nms6QO4KKkVpM_m06nM iImBe1MdbA06gWB_o945q0iCpZwSQDfR4lA2jEXKzbtxTaKniaV68XOt8Or69ZMH.jM0X8IiCI3t xfpb7OVN8PxLLrl90YmtVuQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Fri, 22 Jun 2018 21:08:08 +0000 Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bc016fc0fa25fa709a75572ea1f44247; Fri, 22 Jun 2018 21:08:05 +0000 (UTC) To: Torsten Lodderstedt Cc: Brian Campbell , oauth References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> From: George Fletcher Organization: AOL LLC Message-ID: <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> Date: Fri, 22 Jun 2018 17:08:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 21:08:12 -0000 On 6/22/18 4:31 PM, Torsten Lodderstedt wrote: > Hi George, > >> Is the goal to bind an access token to a particular transaction? If this is the case, would it not be better to either extend the refresh_token flow or may better yet, create a new grant_type that takes the refresh_token and additional "binding" parameters and then have that return the "bound" access token to be used for the transaction. > What would be the scope of such a refresh token? I would think that the scope issued to the refresh_token could represent the category or class of authorizations the refresh_token should be able to perform. For example, the kind of transactions that can be bound to access tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe I'm not fully understanding the use case :) >> On 6/20/18 5:58 PM, Brian Campbell wrote: >>> In my own personal and humble opinion, Torsten, what you describe as "(1) Parameter is part of the scope value" is the most natural approach and works without needing changes to, or going outside of, RFC6749 The OAuth 2.0 Authorization Framework. There may be AS implementations that have made assumption about scope values being static (I know of at least one!) but that's an implementation/feature issue, which can change, and not a spec issue. >>> >>> The OIDC "claims" parameter is already a bit of a hairy beast and I think using it and the ID Token to convey more dynamic access/authorization is blurring the line between authorization and authentication a bit much. Also, as others have pointed out, OIDC isn't always in play - particularly for regular old authorization cases. >>> >>> An additional query parameter might be simple for a one-off case but it's nonstandard and not very repeatable. >>> >>> >>> On Mon, Jun 18, 2018 at 9:34 AM, Torsten Lodderstedt wrote: >>> Hi all, >>> >>> I have been working lately on use cases where OAuth is used to authorize transactions in the financial sector and electronic signing. What I learned is there is always the need to pass resource ids (e.g. account numbers) or transaction-specific values (e.g. amount or hash to be signed) to the OAuth authorization process to further qualify the scope of the requested access token. >>> >>> It is obvious a static scope value, such as „payment“or „sign“, won’t do the job. For example in case of electronic signing, one must bind the authorization/access token to a particular document, typically represented by its hash. >>> >>> I would like to get your feedback on what you consider a good practice to cope with that challenge. As a starting point for a discussion, I have assembled a list of patterns I have seen in the wild (feel free to extend). >>> >>> (1) Parameter is part of the scope value, e.g. „sign:“ or "payments:" - I think this is an obvious way to represent such parameters in OAuth, as it extends the scope parameter, which is intended to represent the requested scope of an access token. I used this pattern in the OAuth SCA mode in Berlin Group's PSD API. >>> >>> (2) One could also use additional query parameter to add further details re the requested authorization, e.g. >>> >>> GET /authorize? >>> ..... >>> &scope=sign >>> ..... >>> &hash_to_be_signed= >>> >>> It seems to be robust (easier to implement?) but means the scope only represents the static part of the action. The AS needs to look into a further parameter to fully understand the requested authorization. >>> >>> (3) Open Banking UK utilizes the (OpenID Connect) „claims“ parameter to carry additional data. >>> >>> Example: >>> >>> "claims": { >>> "id_token": { >>> "acr": { >>> "essential": true, >>> "value": "..." >>> }, >>> "hash_to_be_signed": { >>> "essential": true, >>> "value": "" >>> } >>> }, >>> "userinfo": { >>> "hash_to_be_signed": { >>> "essential": true, >>> "value": "" >>> } >>> } >>> } >>> >>> I‘m looking forward for your feedback. Please also indicated whether you think we should flush out a BCP on that topic. >>> >>> kind regards, >>> Torsten. >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you. >>> >>> _______________________________________________ >>> OAuth mailing list >>> >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Jun 23 00:43:58 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCE9130FC7 for ; Sat, 23 Jun 2018 00:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2h0yYTVSvAM for ; Sat, 23 Jun 2018 00:43:53 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6113B130EB5 for ; Sat, 23 Jun 2018 00:43:53 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.126]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fWdD4-0003ft-P8; Sat, 23 Jun 2018 09:43:50 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-6797E039-B88C-483F-B06D-3058BDC44820; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (15E216) In-Reply-To: <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> Date: Sat, 23 Jun 2018 09:43:50 +0200 Cc: Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net> References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> To: George Fletcher X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 07:43:57 -0000 --Apple-Mail-6797E039-B88C-483F-B06D-3058BDC44820 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > Am 22.06.2018 um 23:08 schrieb George Fletcher : >=20 > I would think that the scope issued to the refresh_token could represent t= he category or class of authorizations the refresh_token should be able to p= erform. For example, the kind of transactions that can be bound to access to= kens. The scope issued into the access_token could be one of the "parameteri= zed" ones. But maybe I'm not fully understanding the use case :) Let me try to explain ;-) The client is an issuance company wanting the customer to electronically sig= n a new contract (legally binding!). Signing in the end means to send a requ= est containing the hash of the document to an API. The API will respond with= an CM/S Object containing signature, certificate etc that the client will e= mbedded in the contract document (typical PDF). We want the user to authorize the signing request using their bank as IDP/AS= . Therefore the client sends the OAuth authorization request to the AS. The a= ctual signing request needs to be bound to client, user AND hash (document) i= n order to prevent fraud. Regulation (eIDAS) requires to always demonstrate t= he sole control of the user over the whole process. The AS therefore binds (= scopes) the access token to exactly this single document/signing request. If= the client wants the user to sign another document, it needs to got through= the whole process again. One could think about a general signing permission represented by a refresh t= oken, but not in the high assurance level cases I=E2=80=98m looking into. Hope that helps, Torsten. --Apple-Mail-6797E039-B88C-483F-B06D-3058BDC44820 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDYyMzA3NDM1MFow IwYJKoZIhvcNAQkEMRYEFGXZ0WS/YGbatKalyUmJmgDcVWO6MIG+BgkrBgEEAYI3EAQxgbAwga0w gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQCxMc8jtqqCF4UvjyW4 nhJxigWbh9GtT5h+OTSHr/Tp4Ho3gb+dHZIFmfik5aEXzYLD5CC+4Py4VKBXD2BF21UORUh1oM/e A+EKiuApCIyL+g5XGvHaHPq9vMkzom7lQaUNZpGgOuqt5xpOxtC1hJGk5XXAURu4Q3MvfS/H89It 0XrouNJPJ07tcfirkMw+B/wSF/UySDlalLROl5t95bqK19da8jaLjVcw/VzP0iJeoBXVeHuFikk2 rYiRU7vegt7qvgrvM4SXAX4HXKb+KjduSJe7aZ6lDZEdeJB/l55gY6SOr5c3G6KnZcBa0mrCjp9I 3ymjtdG9DhUIoczwqJzXAAAAAAAA --Apple-Mail-6797E039-B88C-483F-B06D-3058BDC44820-- From nobody Sat Jun 23 06:13:27 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C921130E42 for ; Sat, 23 Jun 2018 06:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nri365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DN3a7cMyYpoo for ; Sat, 23 Jun 2018 06:13:23 -0700 (PDT) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD3B130E57 for ; Sat, 23 Jun 2018 06:13:23 -0700 (PDT) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs03.index.or.jp (Postfix) with ESMTP id 02E7317EA43; Sat, 23 Jun 2018 22:13:22 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id AEA144E0046; Sat, 23 Jun 2018 22:13:21 +0900 (JST) Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id w5NDDLVv016420; Sat, 23 Jun 2018 22:13:21 +0900 Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp with ESMTP id w5NDDLOL016419; Sat, 23 Jun 2018 22:13:21 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w5NDDL4U029462; Sat, 23 Jun 2018 22:13:21 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id w5NDDLER029461; Sat, 23 Jun 2018 22:13:21 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id w5NDDLDn029458; Sat, 23 Jun 2018 22:13:21 +0900 Received: from CUEXE02PA.cu.nri.co.jp (192.51.23.32) by CUEXM09PA.cu.nri.co.jp (172.159.253.51) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 23 Jun 2018 22:13:19 +0900 Received: from APC01-SG2-obe.outbound.protection.outlook.com (65.55.88.240) by ex.nri.co.jp (192.51.23.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 23 Jun 2018 22:13:19 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nri365.onmicrosoft.com; s=selector1-cu-nri-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rBI+KZE/9PaindsZRThBNUVaSf29Nk2Hz4Svm4Ov2jY=; b=lxvbC8iLqE/1TPCM/fGjdREwJ1u62rwFu13SNlZe9A6AITI7MgRhghe8aM1I6SAPXg1LYm80RugCC9FcTQFgAyRX2mehxDTX4qWK1eGO2AhTDmz0ecRUSQYs7BRcwAikIUue+F9OlhyeBEbvVPNtp/BI0aJ2IlJYz0oJz5m27f0= Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com (52.133.184.14) by TY2PR01MB2651.jpnprd01.prod.outlook.com (20.177.99.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.884.22; Sat, 23 Jun 2018 13:13:18 +0000 Received: from TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::dd58:eb22:ae46:41e0]) by TY2PR01MB2297.jpnprd01.prod.outlook.com ([fe80::dd58:eb22:ae46:41e0%3]) with mapi id 15.20.0863.016; Sat, 23 Jun 2018 13:13:18 +0000 From: n-sakimura To: Torsten Lodderstedt , George Fletcher CC: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] Dynamic Scopes Thread-Index: AQHUBxoBpDr/OIlzL0GUOtf1C9CbMaRptVSAgALfqYCAACzhgIAACiYAgACxoQCAAFwNkQ== Date: Sat, 23 Jun 2018 13:13:18 +0000 Message-ID: References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com>, <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net> In-Reply-To: <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net> Accept-Language: ja-JP, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=n-sakimura@cu.nri.co.jp; x-originating-ip: [40.90.247.76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; TY2PR01MB2651; 7:WxjAF5Mltw7vGsIChHz9ohPkHLK397fNG62/eP6JQ+BsLd/n1zYoedNWTXSZfB62i7AAvFIdqvXzNFQPiJTdNO9tFyko+32pYgGr6DX10qXlYccxppbZvd39MsIfprvHiNQ6FVajWvhhS4TPNkgeqrmza2v/XBW8+SHtHKPixS0DbtCczRpEzzHtlhTCfQ52pU3l+FP+MTMaS9+RCq48msRNFl0kOHYeB/SHMCRCxPMsGUXkrgWOqdvBnfcfXJix x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 9912f395-796d-419b-2467-08d5d90b1615 x-microsoft-antispam: UriScan:(223705240517415); BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(8989117)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:TY2PR01MB2651; x-ms-traffictypediagnostic: TY2PR01MB2651: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(149059832740258)(223705240517415)(81439100147899); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123560045)(2016111802025)(20161123564045)(6043046)(6072148)(201708071742011)(7699016); SRVR:TY2PR01MB2651; BCL:0; PCL:0; RULEID:; SRVR:TY2PR01MB2651; x-forefront-prvs: 07126E493C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(376002)(396003)(346002)(39830400003)(189003)(199004)(74482002)(3846002)(86362001)(6116002)(5250100002)(97736004)(66066001)(54906003)(106356001)(14454004)(110136005)(316002)(5660300001)(53936002)(105586002)(9686003)(74316002)(4326008)(478600001)(93886005)(39060400002)(6246003)(2906002)(7736002)(68736007)(8936002)(25786009)(102836004)(8676002)(6436002)(26005)(3660700001)(54896002)(76176011)(99286004)(229853002)(3280700002)(81166006)(53546011)(446003)(33656002)(59450400001)(55016002)(6306002)(81156014)(486006)(476003)(11346002)(2900100001)(7696005)(186003)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:TY2PR01MB2651; H:TY2PR01MB2297.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: cu.nri.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: GPC96OJEeNqzVe8uI8FrCOKx+nbG8vaRUTla2v7do7DWwdK6RESFWr4zQP3c8wD0HlOzmmbTrWyVEZmp4DZCal3uO2HIFS6i+YmLkrfn9FirkTkIz3sNeGdFBqatjoNwNJMJukgWtQFCPQsi4J9o/IPWsVBDaif0U1bTP4jKs20EHyFLQ0KOJ3GoMqDm0wNY0sEi8tjkOdWAmECfQqxdm3JH4GleSeMOHcUKK7d/HdCvsYFxvn6z5Igq+1nL2HR/96JNWvx2OukbQkEXQ59qMjyfIPaV3F975d+3/hOGd1pfzABZ7rD3IrXnVwxG0CCSqfypliS83cKuH4O5SmrhrUiZO4tTk9yAs+bORtoEpko= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_TY2PR01MB2297EFB47BCD6A81C549E3F5F9740TY2PR01MB2297jpnp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9912f395-796d-419b-2467-08d5d90b1615 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2018 13:13:18.0294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e3e360d9-7e7f-48d5-ac33-3c5de61f0a75 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2651 X-OrganizationHeadersPreserved: TY2PR01MB2651.jpnprd01.prod.outlook.com X-CrossPremisesHeadersPromoted: CUEXE02PA.cu.nri.co.jp X-CrossPremisesHeadersFiltered: CUEXE02PA.cu.nri.co.jp X-OriginatorOrg: cu.nri.co.jp Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 13:13:26 -0000 --_000_TY2PR01MB2297EFB47BCD6A81C549E3F5F9740TY2PR01MB2297jpnp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Torsten, For the digital signature case, I feel a bit uneasy to sign the hash that w= as sent by the client. The signing mechanism, a bank in this case, should d= isplay what is being signed to the user before the user makes a signature. = The staging strategy works here as well. The client sends the signed docume= nt to the staging server and the bank verifies the signature and shows the = document to the user, where the user can view the document and when he deci= des to sign it, the signature over the document=1B$B!G=1B(Bs hash will be m= ade so that it will result in a mutually signed document. Best, Nat Nat Sakimura =1B$B$3$N%a!<%k$K$O!"K\Mh$N08@h$NJ}$N$_$K8BDj$5$l$?5!L)>pJs$,4^$^$l$F$$$k>l= 9g$,$4$6$$$^$9!#$*?4$"$?$j$N$J$$>l9g$O!"Aw?.e$2$^$9!#=1B(B PLEASE READ=1B$B!'=1B(BThis e-mail is confidential and intended for the nam= ed recipient only. If you are not an intended recipient, please notify the = sender and delete this e-mail. ________________________________ From: OAuth on behalf of Torsten Lodderstedt Sent: Saturday, June 23, 2018 3:43:50 AM To: George Fletcher Cc: Brian Campbell; oauth Subject: Re: [OAUTH-WG] Dynamic Scopes > Am 22.06.2018 um 23:08 schrieb George Fletcher : > > I would think that the scope issued to the refresh_token could represent = the category or class of authorizations the refresh_token should be able to= perform. For example, the kind of transactions that can be bound to access= tokens. The scope issued into the access_token could be one of the "parame= terized" ones. But maybe I'm not fully understanding the use case :) Let me try to explain ;-) The client is an issuance company wanting the customer to electronically si= gn a new contract (legally binding!). Signing in the end means to send a re= quest containing the hash of the document to an API. The API will respond w= ith an CM/S Object containing signature, certificate etc that the client wi= ll embedded in the contract document (typical PDF). We want the user to authorize the signing request using their bank as IDP/A= S.. Therefore the client sends the OAuth authorization request to the AS. T= he actual signing request needs to be bound to client, user AND hash (docum= ent) in order to prevent fraud. Regulation (eIDAS) requires to always demon= strate the sole control of the user over the whole process. The AS therefor= e binds (scopes) the access token to exactly this single document/signing r= equest. If the client wants the user to sign another document, it needs to = got through the whole process again. One could think about a general signing permission represented by a refresh= token, but not in the high assurance level cases I=1B$B!F=1B(Bm looking in= to. Hope that helps, Torsten. --_000_TY2PR01MB2297EFB47BCD6A81C549E3F5F9740TY2PR01MB2297jpnp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Torsten,

For the digital signature case, I feel a bit u= neasy to sign the hash that was sent by the client. The signing mechanism, = a bank in this case, should display what is being signed to the user before= the user makes a signature. The staging strategy works here as well. The client sends the signed document to the s= taging server and the bank verifies the signature and shows the document to= the user, where the user can view the document and when he decides to sign= it, the signature over the document=1B$B!G=1B(Bs hash will be made so that it will result in a mutually signed document.

Best,

Nat

Nat Sakimura
=1B$B$3$N%a!<%k$K$O!"K\Mh$N08@h$NJ}$N$_$K8BDj$= 5$l$?5!L)>pJs$,4^$^$l$F$$$k>l9g$,$4$6$$$^$9!#$*?4$"$?$j$N$J$$>l9g$O!"Aw?.e$2$^$9!= #=1B(B

PLEASE READ=1B$B!'=1B(BThis e-mail is confiden= tial and intended for the named recipient only. If you are not an intended = recipient, please notify the sender and delete this e-mail.
From: OAuth <oauth-bou= nces@ietf.org> on behalf of Torsten Lodderstedt <torsten@lodderstedt.= net>
Sent: Saturday, June 23, 2018 3:43:50 AM
To: George Fletcher
Cc: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] Dynamic Scopes
 


> Am 22.06.2018 um 23:08 schrieb George Fletcher <gffletch@aol.com>= ;:
>
> I would think that the scope issued to the refresh_token could represe= nt the category or class of authorizations the refresh_token should be able= to perform. For example, the kind of transactions that can be bound to acc= ess tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe= I'm not fully understanding the use case :)

Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically si= gn a new contract (legally binding!). Signing in the end means to send a re= quest containing the hash of the document to an API. The API will respond w= ith an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (ty= pical PDF).

We want the user to authorize the signing request using their bank as IDP/A= S.. Therefore the client sends the OAuth authorization request to the AS. T= he actual signing request needs to be bound to client, user AND hash (docum= ent) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the = user over the whole process. The AS therefore binds (scopes) the access tok= en to exactly this single document/signing request. If the client wants the= user to sign another document, it needs to got through the whole process again.

One could think about a general signing permission represented by a refresh= token, but not in the high assurance level cases I=1B$B!F=1B(Bm looking in= to.

Hope that helps,
Torsten.


 --_000_TY2PR01MB2297EFB47BCD6A81C549E3F5F9740TY2PR01MB2297jpnp_-- From nobody Sat Jun 23 07:41:56 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA81313101F for ; Sat, 23 Jun 2018 07:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qokvL3-DpAnM for ; Sat, 23 Jun 2018 07:41:50 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8A2130E71 for ; Sat, 23 Jun 2018 07:41:49 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.111]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fWjjU-0003G7-87; Sat, 23 Jun 2018 16:41:44 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-3D10F438-6076-44C7-813A-50AC1F30528A; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Sat, 23 Jun 2018 16:41:43 +0200 Cc: George Fletcher , Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: <9C2D2FFB-DDFE-4A23-B92E-E79703AD0945@lodderstedt.net> References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net> To: n-sakimura X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 14:41:54 -0000 --Apple-Mail-3D10F438-6076-44C7-813A-50AC1F30528A Content-Type: multipart/alternative; boundary=Apple-Mail-1415FB2F-EA80-484D-905B-CE34752ABEBA Content-Transfer-Encoding: 7bit --Apple-Mail-1415FB2F-EA80-484D-905B-CE34752ABEBA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nat, I thought the same when we started this endeavor. What I learned is this has privacy/confidentiality implications since the AS= learns the content of the document. For example, sending the document to a s= taging API also requires a consent of the user (given prior to the data tran= sfer!) in case PII is contained in the document. Moreover, depending on the format of the document, the AS needs different vi= ewers, which increases complexity. So the current concept (which is also standard practice in this sector) is t= he client shows the prepared and signed document before and after the signin= g process and is legally obliged to do it correctly. The AS is responsible for providing the signing service with verified person= data and captures the user=E2=80=98s intent to sign. Both require consent. best regards, Torsten. > Am 23.06.2018 um 15:13 schrieb n-sakimura : >=20 > Torsten, >=20 > For the digital signature case, I feel a bit uneasy to sign the hash that w= as sent by the client. The signing mechanism, a bank in this case, should di= splay what is being signed to the user before the user makes a signature. Th= e staging strategy works here as well. The client sends the signed document t= o the staging server and the bank verifies the signature and shows the docum= ent to the user, where the user can view the document and when he decides to= sign it, the signature over the document=E2=80=99s hash will be made so tha= t it will result in a mutually signed document. >=20 > Best, >=20 > Nat >=20 > Nat Sakimura > =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E3=81=AF=E3=80=81=E6= =9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE=E6=96=B9=E3=81=AE=E3=81=BF= =E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81=9F=E6=A9=9F=E5=AF=86=E6=83= =85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3=81=A6=E3=81=84=E3=82=8B=E5= =A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84=E3=81=BE=E3=81=99=E3=80=82= =E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81=AE=E3=81=AA=E3=81=84=E5=A0= =B4=E5=90=88=E3=81=AF=E3=80=81=E9=80=81=E4=BF=A1=E8=80=85=E3=81=AB=E3=81=94=E9= =80=A3=E7=B5=A1=E3=81=AE=E3=81=86=E3=81=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1= =E3=83=BC=E3=83=AB=E3=82=92=E5=89=8A=E9=99=A4=E3=81=97=E3=81=A6=E3=81=8F=E3=81= =A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3= =81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >=20 > PLEASE READ=EF=BC=9AThis e-mail is confidential and intended for the named= recipient only. If you are not an intended recipient, please notify the sen= der and delete this e-mail. > From: OAuth on behalf of Torsten Lodderstedt > Sent: Saturday, June 23, 2018 3:43:50 AM > To: George Fletcher > Cc: Brian Campbell; oauth > Subject: Re: [OAUTH-WG] Dynamic Scopes > =20 >=20 >=20 > > Am 22.06.2018 um 23:08 schrieb George Fletcher : > >=20 > > I would think that the scope issued to the refresh_token could represent= the category or class of authorizations the refresh_token should be able to= perform. For example, the kind of transactions that can be bound to access t= okens. The scope issued into the access_token could be one of the "parameter= ized" ones. But maybe I'm not fully understanding the use case :) >=20 > Let me try to explain ;-) >=20 > The client is an issuance company wanting the customer to electronically s= ign a new contract (legally binding!). Signing in the end means to send a re= quest containing the hash of the document to an API. The API will respond wi= th an CM/S Object containing signature, certificate etc that the client will= embedded in the contract document (typical PDF). >=20 > We want the user to authorize the signing request using their bank as IDP/= AS.. Therefore the client sends the OAuth authorization request to the AS. T= he actual signing request needs to be bound to client, user AND hash (docume= nt) in order to prevent fraud. Regulation (eIDAS) requires to always demonst= rate the sole control of the user over the whole process. The AS therefore b= inds (scopes) the access token to exactly this single document/signing reque= st. If the client wants the user to sign another document, it needs to got t= hrough the whole process again. >=20 > One could think about a general signing permission represented by a refres= h token, but not in the high assurance level cases I=E2=80=98m looking into.= >=20 > Hope that helps, > Torsten. >=20 >=20 --Apple-Mail-1415FB2F-EA80-484D-905B-CE34752ABEBA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Nat,

I thought the same when we started this endeavor.

=
What I learned is this has privacy/confidentiality implications since t= he AS learns the content of the document. For example, sending the document t= o a staging API also requires a consent of the user (given prior to the data= transfer!) in case PII is contained in the document.

Moreover, depending on the format of the document, the AS needs different= viewers, which increases complexity.

So the curren= t concept (which is also standard practice in this sector) is the client sho= ws the prepared and signed document before and after the signing process and= is legally obliged to do it correctly.

The AS is r= esponsible for providing the signing service with verified person data and c= aptures the user=E2=80=98s intent to sign. Both require consent.
<= br>
best regards,
Torsten.

Am 23.06.2018 u= m 15:13 schrieb n-sakimura <n-sak= imura@nri.co.jp>:

Torsten,

For the digital signature case, I feel a bit un= easy to sign the hash that was sent by the client. The signing mechanism, a b= ank in this case, should display what is being signed to the user before the= user makes a signature. The staging strategy works here as well. The client sends the signed document to the st= aging server and the bank verifies the signature and shows the document to t= he user, where the user can view the document and when he decides to sign it= , the signature over the document=E2=80=99s hash will be made so that it will result in a mutually signed document.

Best,

Nat

Nat Sakimura
=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3= =81=AB=E3=81=AF=E3=80=81=E6=9C=AC=E6=9D=A5=E3=81=AE=E5=AE=9B=E5=85=88=E3=81=AE= =E6=96=B9=E3=81=AE=E3=81=BF=E3=81=AB=E9=99=90=E5=AE=9A=E3=81=95=E3=82=8C=E3=81= =9F=E6=A9=9F=E5=AF=86=E6=83=85=E5=A0=B1=E3=81=8C=E5=90=AB=E3=81=BE=E3=82=8C=E3= =81=A6=E3=81=84=E3=82=8B=E5=A0=B4=E5=90=88=E3=81=8C=E3=81=94=E3=81=96=E3=81=84= =E3=81=BE=E3=81=99=E3=80=82=E3=81=8A=E5=BF=83=E3=81=82=E3=81=9F=E3=82=8A=E3=81= =AE=E3=81=AA=E3=81=84=E5=A0=B4=E5=90=88=E3=81=AF=E3=80=81=E9=80=81=E4=BF=A1=E8= =80=85=E3=81=AB=E3=81=94=E9=80=A3=E7=B5=A1=E3=81=AE=E3=81=86=E3=81=88=E3=80=81= =E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=82=92=E5=89=8A=E9=99=A4=E3=81= =97=E3=81=A6=E3=81=8F=E3=81=A0=E3=81=95=E3=81=84=E3=81=BE=E3=81=99=E3=82=88=E3= =81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3=81=97=E4=B8=8A=E3=81=92=E3=81=BE= =E3=81=99=E3=80=82

PLEASE READ=EF=BC=9AThis e-mail is confidential= and intended for the named recipient only. If you are not an intended recip= ient, please notify the sender and delete this e-mail.
From: OAuth <oauth-bounces@ietf.org> on behalf of T= orsten Lodderstedt <torsten@lo= dderstedt.net>
Sent: Saturday, June 23, 2018 3:43:50 AM
To: George Fletcher
Cc: Brian Campbell; oauth
Subject: Re: [OAUTH-WG] Dynamic Scopes
 


> Am 22.06.2018 um 23:08 schrieb George Fletcher <gffletch@aol.com>:
>
> I would think that the scope issued to the refresh_token could represen= t the category or class of authorizations the refresh_token should be able t= o perform. For example, the kind of transactions that can be bound to access= tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe I'm not fu= lly understanding the use case :)

Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sig= n a new contract (legally binding!). Signing in the end means to send a requ= est containing the hash of the document to an API. The API will respond with= an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typ= ical PDF).

We want the user to authorize the signing request using their bank as IDP/AS= .. Therefore the client sends the OAuth authorization request to the AS. The= actual signing request needs to be bound to client, user AND hash (document= ) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the u= ser over the whole process. The AS therefore binds (scopes) the access token= to exactly this single document/signing request. If the client wants the us= er to sign another document, it needs to got through the whole process again.

One could think about a general signing permission represented by a refresh t= oken, but not in the high assurance level cases I=E2=80=98m looking into.
Hope that helps,
Torsten.
= --Apple-Mail-1415FB2F-EA80-484D-905B-CE34752ABEBA-- --Apple-Mail-3D10F438-6076-44C7-813A-50AC1F30528A Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKhzCCBTow ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048 LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK 6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6 7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6 xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM 5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYwggVFMIIELaADAgECAhAz25rGqsI3mWtz8QN7mfC0 MA0GCSqGSIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0EwHhcNMTcwMTA5MDAwMDAwWhcNMTgwMTA5MjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkBFhd0b3Jz dGVuQGxvZGRlcnN0ZWR0Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK7Bks2c s/S6vUkVvUr3uSvJ+ZVoaZTghOhx94DMntdg4zqZBRWbdG+97duxte17KellMR4TXr3+3JNAFKb2 FDwhwalRiUiFhfYVgKEhQoEAAjqIf3AxW889T7DGPBJezpiLrOCV7WOP1XaEiIRT94cwE2zQIN9i qfjfL7U7ik8G4J4syUss2U2K7LbZ9y5sGNex1PlPb15aDLrOVP5Z+AA2cdM8sg0rAOoLT8V2CaW4 Ek5x3JFWec30fNILiGed/GNqqrKreVWkkUkdqEMxPxxE5CnP6HT1Yaga1y8r50hZAj6wF1dO63L8 JD7x2XmFbuEHVVsjthyEOItsfa+Zu0sCAwEAAaOCAfUwggHxMB8GA1UdIwQYMBaAFJJha4LhoqCq T+xn8cKj97SAAMHsMB0GA1UdDgQWBBT54B4FcTmexko4vyFuGCTAY9NjxzAOBgNVHQ8BAf8EBAMC BaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZI AYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0 dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwu Y29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdG9y c3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBAAJrnsh44si9amIH3voVUrBr ipYHL4wgHxvCWquPLQtCIz/KR/7RouLi/Qh1Xy51d6Sw544OjNrr6RAae3K2WXJ0jy3lbLPrZIcL /heyEmEMk+H5TZKlVG/J33sGwj3CDddzm36VO65V6CGqxBKZUKOErspmFZbkMUyzhSpuUDjBeCQT MP648uLfeSezHafTRVM0KyjyQ2idia/03E1xXIy7zVZjAYytPefWvb9f9ZokR3dQwbE4dSrwYoBD lDTMb0+blLQev7YqA2agQw5PBr3Z6P8Zsnt2ImrEuyYDERKuVnF6qVhruZDBWTBjxL8jx3gWXqsc d2pn+CJlZ2elr4MxggPAMIIDvAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0 ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHnMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDYyMzE0NDE0M1owIwYJKoZIhvcNAQkEMRYE FB7zajba0BA60wCZnQAv04t7Ew5hMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQM9uaxqrCN5lrc/EDe5nwtDCBwwYLKoZIhvcN AQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhD T01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQ M9uaxqrCN5lrc/EDe5nwtDANBgkqhkiG9w0BAQEFAASCAQBoq2fxZc9KFwlokIZl5MiYjdCzrjVE Xq988PurngS831cH9MCqLJoYc2pjBKiZcKRlw6NtEw9XpUyOKPLfAt8IEuTDUd/yylVkJDMDA6Aq Lzq5Pbl4J1xb5bNmKsXpGurceM+mYj/KQXwVc40MACYZoj/OBHmMYt4eNyaWCkDXl4E/MnupiSbj hnMn8cY4+R6whwPEeDv77pApc+DLiffTf0INAK/Ce7HAf5Yyfku9yGqsCIeC3hwvLjGCd+r+wiKl DZYHMDGSxN0IXPT0qZZjcTAKTw4RdvAbEVQoLNA7X6BvFRMcmnszt5/SVZMUxcTEy6k9Ka1u1wd+ zX+MYjEiAAAAAAAA --Apple-Mail-3D10F438-6076-44C7-813A-50AC1F30528A-- From nobody Sat Jun 23 12:08:06 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09133130EEA for ; Sat, 23 Jun 2018 12:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VktXljNMyrO9 for ; Sat, 23 Jun 2018 12:08:03 -0700 (PDT) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 266BF130EB9 for ; Sat, 23 Jun 2018 12:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1529780882; bh=M8mUixzGwHKKl815SC79Hex8LduLmdG5C+ZVDZ//aD8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=Ku+SughMCbT7a8RuDAtRrAD9b/tIZ+SCGjaBzVp6SSySgeDWnzi15lmjYsKNkNLkSMX2LL9dN0LbWKjOe27TwFskIm5aGX6N4b8zWA3NeYaDhoQVo4wqUamZTIkG2bF3HJnCN5ctjN+abMdsGmmiaLbF+rm2k3qwzPJRl8ajaZ9areReV/XlnxvFKvQF+r0BbKUciqB9o5303dntley8iJy6um4n/gab9vKF2qEeIaX/usBAfmgiE71Q8xeWr8nmoOsGIHV8hEvZZscXdizgxmPkymwz/Y9ctEK8uW/WbScAsx0rr9j/dFJRduRU5F/+jdRo3nzvSpqS3mXL0UZAYw== X-YMail-OSG: bYTDzKUVM1kdT6iLDeycKeFaCV3nDs0goZQf8YQvNB5pNORH0mVJva1QQqLFAA0 dE04Apk8q4fO313xItKQA3ve84agib7snKPSRKeCTo31OjTcPGfTY0OE23HeGLxW5Ab7nYk2KsHY KYdRYPk4qZmURL_6cmsXWsYAQ_M_hWRzXmwgz72xAZZs7b2bgQOmuHnsLei5Inhc3_ul58B4PIZh DTALkiaScbsmwEG7X2WoaJADpda2sORGgLlAKmTreF6EfxECK48y0.KmdVdPT_vrMmL1IjBEB0mw IZwMyVrDB3h10EP4knQiRxR3MEV7L2L8Sl9jIx0gU.FNh_7f_KjpwiWW0XUbtYSvAKasMsojEAjS nyTMY_fGLzPy241HxHf0bVCmuHOnH2V1OZjzBg5iV4HVl9LRGiuMdyYEsVQ2GDC0d1ur1MS.GJJM uf3xmEdWXC6KYJXw.VRjJhsTxwcfsmY1KyaNvz9XoaTNVKqD7Ex5.HVx999ICKNIqLg9yA93uDZ. RwuxXPQ74.OXlzVeJL2Uv39eIz3ow3KGa6WBFL0bL5RMB6YJ8TFdAzZI.S2jwIaaI3LNqCLsmFQr CHobrtnOvEsIkGD_Dr67Tq7u4VenCNJqc8Fldfadw8bqDez2IFaGOnpgxGviRvbQwf7B7efXZGcN zTMruzpML_U7Ohb5SGYWRSambwdu7s5labmfA.SwC3bhmSJPMuq9SEfQ.NTTp8pR6OEDv03XZWfX RbFkNWiQJbl3MrMAi2p6kHA3NMJ7RF67b4q2SHQcmUoDEiwQw6DnjYSjcXNWeWw7UfJhNPt9rWme dX.bAkX08fTuee0fNXmTdwHpcjpD1SJbsMKsAZv28BbF8sBrax527H2V6wk6whcEfDi9K._38Q_L E50FItiNWORc5Xmr29feSkgcsODB4IhFSG9mp3AQh.FOgYuT_bJTzycqSjB8mZ4CgTYyMt.uw_ph Tp2y6CGTvJDgq_t9_dF1tpLnO1bL6zUcI2loO0rh_M20- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sat, 23 Jun 2018 19:08:02 +0000 Received: from 98.139.248.67 (EHLO [10.89.80.30]) ([98.139.248.67]) by smtp428.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2c90f8fb50b74a797b54899b9c6e543f; Sat, 23 Jun 2018 19:07:59 +0000 (UTC) To: Torsten Lodderstedt Cc: Brian Campbell , oauth References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net> From: George Fletcher Organization: AOL LLC Message-ID: Date: Sat, 23 Jun 2018 15:07:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net> Content-Type: multipart/alternative; boundary="------------AFCB0018BBC6254A1338B34C" Content-Language: en-US Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 19:08:06 -0000 This is a multi-part message in MIME format. --------------AFCB0018BBC6254A1338B34C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks Torsten. I think I have a solution :) Just to make sure I have the flow correct... Assumption: Using a mobile client 1. User (using their mobile client) attempts to sign a document with the insurance company 2. Insurance company redirects the user to their Bank asking for identity proof, and signing of specific documents 3. User interacts with Bank to get authorization for the specific transaction 4. Mobile client submits request to insurance company using token that is specific to the user, document etc. This is effectively the UMA 2.0 flow [1] 1. Mobile client attempts to invoke resource at the insurance company 2. Insurance company registers the request with UMA AS (the bank in this case) and gets a permissions ticket 3. Insurance company instructs mobile client to contact the bank 4. Mobile client contacts the bank specifying the permissions ticket 5. User meets banks requirements for the specific transaction (claims interaction) 6. Bank issues mobile client the RPT (token) 7. Mobile client invokes resource at insurance company with RPT Note that the insurance company can specify the necessary bits that need to be in the token when it interacts with the Bank (as the UMA AS). [There might be some profiling required here] I think it's worth exploring whether UMA will solve this use case. Thanks, George [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html On 6/23/18 3:43 AM, Torsten Lodderstedt wrote: > >> Am 22.06.2018 um 23:08 schrieb George Fletcher : >> >> I would think that the scope issued to the refresh_token could represent the category or class of authorizations the refresh_token should be able to perform. For example, the kind of transactions that can be bound to access tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe I'm not fully understanding the use case :) > Let me try to explain ;-) > > The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF). > > We want the user to authorize the signing request using their bank as IDP/AS. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again. > > One could think about a general signing permission represented by a refresh token, but not in the high assurance level cases I‘m looking into. > > Hope that helps, > Torsten. > > --------------AFCB0018BBC6254A1338B34C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks Torsten.

I think I have a solution :) Just to make sure I have the flow correct...

Assumption: Using a mobile client

1. User (using their mobile client) attempts to sign a document with the insurance company
2. Insurance company redirects the user to their Bank asking for identity proof, and signing of specific documents
3. User interacts with Bank to get authorization for the specific transaction
4. Mobile client submits request to insurance company using token that is specific to the user, document etc.

This is effectively the UMA 2.0 flow [1]

1. Mobile client attempts to invoke resource at the insurance company
2. Insurance company registers the request with UMA AS (the bank in this case) and gets a permissions ticket
3. Insurance company instructs mobile client to contact the bank
4. Mobile client contacts the bank specifying the permissions ticket
5. User meets banks requirements for the specific transaction (claims interaction)
6. Bank issues mobile client the RPT (token)
7. Mobile client invokes resource at insurance company with RPT

Note that the insurance company can specify the necessary bits that need to be in the token when it interacts with the Bank (as the UMA AS). [There might be some profiling required here]

I think it's worth exploring whether UMA will solve this use case.

Thanks,
George

[1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html

On 6/23/18 3:43 AM, Torsten Lodderstedt wrote:


Am 22.06.2018 um 23:08 schrieb George Fletcher <gffletch@aol.com>:

I would think that the scope issued to the refresh_token could represent the category or class of authorizations the refresh_token should be able to perform. For example, the kind of transactions that can be bound to access tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe I'm not fully understanding the use case :)

Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again.

One could think about a general signing permission represented by a refresh token, but not in the high assurance level cases I‘m looking into.

Hope that helps,
Torsten.

--------------AFCB0018BBC6254A1338B34C-- From nobody Sun Jun 24 01:27:14 2018 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8CF130DC5 for ; Sun, 24 Jun 2018 01:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0Lv74kUVfeu for ; Sun, 24 Jun 2018 01:27:08 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F2612F1AB for ; Sun, 24 Jun 2018 01:27:08 -0700 (PDT) Received: from [84.158.233.58] (helo=[192.168.71.126]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fX0MR-0003Rr-04; Sun, 24 Jun 2018 10:27:03 +0200 Content-Type: multipart/signed; boundary=Apple-Mail-9631CD20-8443-4939-AFA4-896A5500EC16; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (1.0) From: Torsten Lodderstedt X-Mailer: iPad Mail (15E216) In-Reply-To: Date: Sun, 24 Jun 2018 10:27:02 +0200 Cc: Brian Campbell , oauth Content-Transfer-Encoding: 7bit Message-Id: <9007FECD-C700-4314-B990-3B5B5414F540@lodderstedt.net> References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net> <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net> To: George Fletcher X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Subject: Re: [OAUTH-WG] Dynamic Scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 08:27:12 -0000 --Apple-Mail-9631CD20-8443-4939-AFA4-896A5500EC16 Content-Type: multipart/alternative; boundary=Apple-Mail-E5E1ACD8-1ED2-479A-9C62-90CEB2BE6E22 Content-Transfer-Encoding: 7bit --Apple-Mail-E5E1ACD8-1ED2-479A-9C62-90CEB2BE6E22 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi George, how is the dynamic nature (hash) of the authorization request handled in you= r solution? Note: the signing service is not provided by the insurance company but a thi= rd party, a sol-called trusted service provider. The insurance company as th= e client in this flow sends the request to this provider. best regards, Torsten. > Am 23.06.2018 um 21:07 schrieb George Fletcher : >=20 > Thanks Torsten. >=20 > I think I have a solution :) Just to make sure I have the flow correct... >=20 > Assumption: Using a mobile client >=20 > 1. User (using their mobile client) attempts to sign a document with the i= nsurance company > 2. Insurance company redirects the user to their Bank asking for identity p= roof, and signing of specific documents > 3. User interacts with Bank to get authorization for the specific transact= ion > 4. Mobile client submits request to insurance company using token that is s= pecific to the user, document etc. >=20 > This is effectively the UMA 2.0 flow [1] >=20 > 1. Mobile client attempts to invoke resource at the insurance company > 2. Insurance company registers the request with UMA AS (the bank in this c= ase) and gets a permissions ticket > 3. Insurance company instructs mobile client to contact the bank > 4. Mobile client contacts the bank specifying the permissions ticket > 5. User meets banks requirements for the specific transaction (claims inte= raction) > 6. Bank issues mobile client the RPT (token) > 7. Mobile client invokes resource at insurance company with RPT >=20 > Note that the insurance company can specify the necessary bits that need t= o be in the token when it interacts with the Bank (as the UMA AS). [There mi= ght be some profiling required here] >=20 > I think it's worth exploring whether UMA will solve this use case. >=20 > Thanks, > George >=20 > [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html >=20 >> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote: >>=20 >>> Am 22.06.2018 um 23:08 schrieb George Fletcher : >>>=20 >>> I would think that the scope issued to the refresh_token could represent= the category or class of authorizations the refresh_token should be able to= perform. For example, the kind of transactions that can be bound to access t= okens. The scope issued into the access_token could be one of the "parameter= ized" ones. But maybe I'm not fully understanding the use case :) >> Let me try to explain ;-) >>=20 >> The client is an issuance company wanting the customer to electronically s= ign a new contract (legally binding!). Signing in the end means to send a re= quest containing the hash of the document to an API. The API will respond wi= th an CM/S Object containing signature, certificate etc that the client will= embedded in the contract document (typical PDF). >>=20 >> We want the user to authorize the signing request using their bank as IDP= /AS. Therefore the client sends the OAuth authorization request to the AS. T= he actual signing request needs to be bound to client, user AND hash (docume= nt) in order to prevent fraud. Regulation (eIDAS) requires to always demonst= rate the sole control of the user over the whole process. The AS therefore b= inds (scopes) the access token to exactly this single document/signing reque= st. If the client wants the user to sign another document, it needs to got t= hrough the whole process again. >>=20 >> One could think about a general signing permission represented by a refre= sh token, but not in the high assurance level cases I=E2=80=98m looking into= . >>=20 >> Hope that helps, >> Torsten. >>=20 >>=20 >=20 --Apple-Mail-E5E1ACD8-1ED2-479A-9C62-90CEB2BE6E22 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi George,

how is the dynamic nature (hash) of the authorization request handl= ed in your solution?

Note: the signing service is n= ot provided by the insurance company but a third party, a sol-called trusted= service provider. The insurance company as the client in this flow sends th= e request to this provider.

best regards,
Torsten.

Am 23.06.2018 um 21:07 schrieb George Fletcher <<= a href=3D"mailto:gffletch@aol.com">gffletch@aol.com>:

=20 =20 =20 Thanks Torsten.

I think I have a solution :) Just to make sure I have the flow correct...

Assumption: Using a mobile client

1. User (using their mobile client) attempts to sign a document with the insurance company
2. Insurance company redirects the user to their Bank asking for identity proof, and signing of specific documents
3. User interacts with Bank to get authorization for the specific transaction
4. Mobile client submits request to insurance company using token that is specific to the user, document etc.

This is effectively the UMA 2.0 flow [1]

1. Mobile client attempts to invoke resource at the insurance company
2. Insurance company registers the request with UMA AS (the bank in this case) and gets a permissions ticket
3. Insurance company instructs mobile client to contact the bank
4. Mobile client contacts the bank specifying the permissions ticket
5. User meets banks requirements for the specific transaction (claims interaction)
6. Bank issues mobile client the RPT (token)
7. Mobile client invokes resource at insurance company with RPT

Note that the insurance company can specify the necessary bits that need to be in the token when it interacts with the Bank (as the UMA AS). [There might be some profiling required here]

I think it's worth exploring whether UMA will solve this use case.
=
Thanks,
George

[1] https://docs.kantarainitiative.o= rg/uma/wg/oauth-uma-grant-2.0-08.html

On 6/23/18 3:43 AM, Torsten Lodderstedt wrote:

      

        
Am 22.06.2018 um 23:08 schrieb George Fletcher <gffletch@a=
ol.com>:

I would think that the scope issued to the refresh_token could represent the=
 category or class of authorizations the refresh_token should be able to per=
form. For example, the kind of transactions that can be bound to access toke=
ns. The scope issued into the access_token could be one of the "parameterize=
d" ones. But maybe I'm not fully understanding the use case :)


      

      
Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sig=
n a new contract (legally binding!). Signing in the end means to send a requ=
est containing the hash of the document to an API. The API will respond with=
 an CM/S Object containing signature, certificate etc that the client will e=
mbedded in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS=
. Therefore the client sends the OAuth authorization request to the AS. The a=
ctual signing request needs to be bound to client, user AND hash (document) i=
n order to prevent fraud. Regulation (eIDAS) requires to always demonstrate t=
he sole control of the user over the whole process. The AS therefore binds (=
scopes) the access token to exactly this single document/signing request. If=
 the client wants the user to sign another document, it needs to got through=
 the whole process again.

One could think about a general signing permission represented by a refresh t=
oken, but not in the high assurance level cases I=E2=80=98m looking into.

Hope that helps,
Torsten.




    

    

 =20


=

--Apple-Mail-E5E1ACD8-1ED2-479A-9C62-90CEB2BE6E22--

--Apple-Mail-9631CD20-8443-4939-AFA4-896A5500EC16
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow
ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla
MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p
Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp
vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048
LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp
WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC
AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK
6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF
BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx
AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f
BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu
dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC
hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w
IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6
7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ
koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6
xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM
5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe
Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDYyNDA4MjcwMlow
IwYJKoZIhvcNAQkEMRYEFB8Qixqcg4Qqb7sgaGXRjkCobPr1MIG+BgkrBgEEAYI3EAQxgbAwga0w
gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh
bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID
lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk
MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQB79T5nzfjx2NFVE8NM
dz17CHlSJaVEM+e0ziEz/EG5rcwV1rzj3qj+re9LU2WfKmdF54vnTqFtrHabftRHy1bFnCY939YH
P66mGrqqmFLr1NYyM3gsTdKtpmon4wwmBzG4xBX5jJKyfkOadIjFt0ZlBCegQGBsr4fSTE1Lg7K/
Dvqn58poPcogfjcRaUyDHrXBRxFemBU+QzcSD7DL4AG7pCEgNa4Kd/KKjJ+231IBHcat3OwDbESp
JU2cDsXvXF22T3OQHgewHUVXo9NCuDapwAkXbBPrh3Q3/IpyYcJVU4J76I2jmkhl5K4KmLmRoZ5o
fZ9JdqaKahKB9tlBxIaeAAAAAAAA
--Apple-Mail-9631CD20-8443-4939-AFA4-896A5500EC16--


From nobody Sun Jun 24 13:02:08 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6AC130E65 for ; Sun, 24 Jun 2018 13:02:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.533
X-Spam-Level: *
X-Spam-Status: No, score=1.533 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=0.001, RCVD_HELO_IP_MISMATCH=2.368, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_NUMERIC_HELO=1.164, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79CYXDg4_1T4 for ; Sun, 24 Jun 2018 13:02:02 -0700 (PDT)
Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B20130E5B for ; Sun, 24 Jun 2018 13:02:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1529870521; bh=fVosZQoKjnJOhGbugIeAybFL/2WJ3Mn6lMIs7DNOCP4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=uNPWbhrIS01Urhpx3cr1efeynqxs0OtKxa28mrKaZJ6+hb6WkWMGXEeD5k+PJUADCLY0sxdYqMrriiI+yvg6bNbYbBadzFnTjYcwNtqVzjdvuu4d1Qn1KoEb5cv5XTx5vRTUF2xY48Q3eZsTlrigD1Te5F+talVkHezweYz+sVdGViu5pXMRheU5eUamf8KK5iXh/zQR2/3BHBcB1EFzy3u3f+BVR9yX6MV58XxMUq5Tb0BzOICHMV4gU/l+q04+SJYNGa0FjSwUjEZnHvL4yWm0BsKCCLBYYb+2F4kH/IeVBu22XVGlJplptfpoxxskMgetqjZ7QU543WVnkQ4mvg==
X-YMail-OSG: UQRXG_kVM1nV9S_RwgwrErsArF0eBA_.4vSFRKzU7t_HUchgbOHmhTzBNqW1XkO ol.Ae_53RlIXuPVbLimkul3tXQBybhiGCiZejYzJ2fwP6CUYIQLwSrkqVTcyThKp7lnwbf_s9up7 hsZjzTwu3WlDjFnDZsfWkAJCFasRgA4ihV47TtFBpXhe4ZBHdkGEWSH0XWThB8EmevMNaS8ky9Gg 2UzI4ljJ_itT1zaeJtOV.PRkMEYbCOTvvbLrNco22nv2.KxReHm1jqBD_FhpEimxmlYYCZAq.bwo o0_V.Ed2zJnvGabyNsaC9Bx2NSyEgcjaZucPfVnFdBJTsoNj.4NIF0BkKyWwYWylXWpayQ5_zWX0 UKpCc1hcTtgVMagW6LaY0MX4n_hTB1s0wFaCRbgnqR4HI3lUXNKJTJ0RMOrI9Is6ykRgkRzbTVP9 oIg8GQ1BIAe7bRlsrwfx__3EQAFdI4yirpoU9NjO8NJaZaLFHFhhtf_KOsnjHdn02.Y.j72gtb1w o41DWUMiGjw7a7w7ydHv8S4wA.OLcM0ljQpjAVYNlOeD2rj4LWzn1PuFvfUl6TiFJS9sux7iv1Dj JDWV3W.SaQZ1ohf.ouid.u.Z2Lh2MF6ebvj7C5EXrm.wM8ebwXa9kYmu.xUTEpHmKB5E2U6OtJJh hQzkX18zBFuO_Mcqu.nJmpr.MW0t_5PfIx9z.V9ZR024DVGglJ48wjENko0bq
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Sun, 24 Jun 2018 20:02:01 +0000
Received: from 98.139.248.67 (EHLO [172.135.128.181]) ([98.139.248.67]) by smtp402.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 22a574bb8a5cc0151c504f13be7e505a;  Sun, 24 Jun 2018 20:01:57 +0000 (UTC)
To: Torsten Lodderstedt 
Cc: Brian Campbell , oauth 
References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net>   <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net>  <9007FECD-C700-4314-B990-3B5B5414F540@lodderstedt.net>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <4cf7f274-ceb8-1734-6e83-1f83766e8061@aol.com>
Date: Sun, 24 Jun 2018 16:01:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <9007FECD-C700-4314-B990-3B5B5414F540@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------871AF0412CC34429D28BDB28"
Content-Language: en-US
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Scopes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Jun 2018 20:02:06 -0000

This is a multi-part message in MIME format.
--------------871AF0412CC34429D28BDB28
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Not sure I have the flow exactly correct... here is an attempt to define 
a flow based on UMA. It's a little difficult to label which flows are 
which parts of the specs. Specifically I am using...

https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html
https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html

If you want the see the image... take the following text and load it 
into https://www.websequencediagrams.com/

title Signing Sequence

participant "Browser" as B
participant "Insurer" as I
participant "Signer" as S
participant "Bank\n(UMA AS)" as A

B->I: complete process
I->S: sign doc\n(required params)
S->A: permission req\n(what the signer needs)
A->S: permission ticket
S->I: Not authorized\n(AS + permission tckt)
I->A: request RPT\n(permission tckt)
A->I: need_info
I-->B: redirect
B->A: claims interaction endpoint
A->B: user verification & consent
B->A: user meets required claims
A-->B: redirect
B->I: user met claimns\n(permission tckt)
I->A: request RPT\n(permission tckt)
A->I: RPT issued
I->S: sign doc\n(RPT)
S->A: introspect\n(RPT)
A->S: permissions\n(required params)
S->I: Signed doc



On 6/24/18 4:27 AM, Torsten Lodderstedt wrote:
> Hi George,
>
> how is the dynamic nature (hash) of the authorization request handled 
> in your solution?
>
> Note: the signing service is not provided by the insurance company but 
> a third party, a sol-called trusted service provider. The insurance 
> company as the client in this flow sends the request to this provider.
>
> best regards,
> Torsten.
>
> Am 23.06.2018 um 21:07 schrieb George Fletcher  >:
>
>> Thanks Torsten.
>>
>> I think I have a solution :) Just to make sure I have the flow correct...
>>
>> Assumption: Using a mobile client
>>
>> 1. User (using their mobile client) attempts to sign a document with 
>> the insurance company
>> 2. Insurance company redirects the user to their Bank asking for 
>> identity proof, and signing of specific documents
>> 3. User interacts with Bank to get authorization for the specific 
>> transaction
>> 4. Mobile client submits request to insurance company using token 
>> that is specific to the user, document etc.
>>
>> This is effectively the UMA 2.0 flow [1]
>>
>> 1. Mobile client attempts to invoke resource at the insurance company
>> 2. Insurance company registers the request with UMA AS (the bank in 
>> this case) and gets a permissions ticket
>> 3. Insurance company instructs mobile client to contact the bank
>> 4. Mobile client contacts the bank specifying the permissions ticket
>> 5. User meets banks requirements for the specific transaction (claims 
>> interaction)
>> 6. Bank issues mobile client the RPT (token)
>> 7. Mobile client invokes resource at insurance company with RPT
>>
>> Note that the insurance company can specify the necessary bits that 
>> need to be in the token when it interacts with the Bank (as the UMA 
>> AS). [There might be some profiling required here]
>>
>> I think it's worth exploring whether UMA will solve this use case.
>>
>> Thanks,
>> George
>>
>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html
>>
>> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote:
>>>> Am 22.06.2018 um 23:08 schrieb George Fletcher:
>>>>
>>>> I would think that the scope issued to the refresh_token could represent the category or class of authorizations the refresh_token should be able to perform. For example, the kind of transactions that can be bound to access tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe I'm not fully understanding the use case :)
>>> Let me try to explain ;-)
>>>
>>> The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF).
>>>
>>> We want the user to authorize the signing request using their bank as IDP/AS. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again.
>>>
>>> One could think about a general signing permission represented by a refresh token, but not in the high assurance level cases I‘m looking into.
>>>
>>> Hope that helps,
>>> Torsten.
>>>
>>>
>>

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


--------------871AF0412CC34429D28BDB28
Content-Type: multipart/related;
 boundary="------------94A230CB6D64448942D2CD7D"


--------------94A230CB6D64448942D2CD7D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Not sure I have the flow
      exactly correct... here is an attempt to define a flow based on
      UMA. It's a little difficult to label which flows are which parts
      of the specs. Specifically I am using...

      

https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html

https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05.html

      

      If you want the see the image... take the following text and load
      it into https://www.websequencediagrams.com/

      

      title Signing Sequence

      

      participant "Browser" as B

      participant "Insurer" as I

      participant "Signer" as S

      participant "Bank\n(UMA AS)" as A

      

      B->I: complete process

      I->S: sign doc\n(required params)

      S->A: permission req\n(what the signer needs)

      A->S: permission ticket

      S->I: Not authorized\n(AS + permission tckt)

      I->A: request RPT\n(permission tckt)

      A->I: need_info

      I-->B: redirect

      B->A: claims interaction endpoint

      A->B: user verification & consent

      B->A: user meets required claims

      A-->B: redirect

      B->I: user met claimns\n(permission tckt)

      I->A: request RPT\n(permission tckt)

      A->I: RPT issued

      I->S: sign doc\n(RPT)

      S->A: introspect\n(RPT)

      A->S: permissions\n(required params)

      S->I: Signed doc

      

      

    

    
On 6/24/18 4:27 AM, Torsten Lodderstedt
      wrote:

    

    

      
      
Hi George,

      


      

      
how is the dynamic nature (hash) of the authorization request
        handled in your solution?

      


      

      
Note: the signing service is not provided by the insurance
        company but a third party, a sol-called trusted service
        provider. The insurance company as the client in this flow sends
        the request to this provider.

      


      

      
best regards,

      
Torsten.

      


        Am 23.06.2018 um 21:07 schrieb George Fletcher <gffletch@aol.com>:

        

      

      

        

          
          Thanks Torsten.

            

            I think I have a solution :) Just to make sure I have the
            flow correct...

            

            Assumption: Using a mobile client

            

            1. User (using their mobile client) attempts to sign a
            document with the insurance company

            2. Insurance company redirects the user to their Bank asking
            for identity proof, and signing of specific documents

            3. User interacts with Bank to get authorization for the
            specific transaction

            4. Mobile client submits request to insurance company using
            token that is specific to the user, document etc.

            

            This is effectively the UMA 2.0 flow [1]

            

            1. Mobile client attempts to invoke resource at the
            insurance company

            2. Insurance company registers the request with UMA AS (the
            bank in this case) and gets a permissions ticket

            3. Insurance company instructs mobile client to contact the
            bank

            4. Mobile client contacts the bank specifying the
            permissions ticket

            5. User meets banks requirements for the specific
            transaction (claims interaction)

            6. Bank issues mobile client the RPT (token)

            7. Mobile client invokes resource at insurance company with
            RPT

            

            Note that the insurance company can specify the necessary
            bits that need to be in the token when it interacts with the
            Bank (as the UMA AS). [There might be some profiling
            required here]

            

            I think it's worth exploring whether UMA will solve this use
            case.

            

            Thanks,

            George

            

            [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html

          

          
On 6/23/18 3:43 AM, Torsten
            Lodderstedt wrote:

          

          

            

              
Am 22.06.2018 um 23:08 schrieb George Fletcher <gffletch@aol.com>:

I would think that the scope issued to the refresh_token could represent the category or class of authorizations the refresh_token should be able to perform. For example, the kind of transactions that can be bound to access tokens. The scope issued into the access_token could be one of the "parameterized" ones. But maybe I'm not fully understanding the use case :)


            

            
Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sign a new contract (legally binding!). Signing in the end means to send a request containing the hash of the document to an API. The API will respond with an CM/S Object containing signature, certificate etc that the client will embedded in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS. Therefore the client sends the OAuth authorization request to the AS. The actual signing request needs to be bound to client, user AND hash (document) in order to prevent fraud. Regulation (eIDAS) requires to always demonstrate the sole control of the user over the whole process. The AS therefore binds (scopes) the access token to exactly this single document/signing request. If the client wants the user to sign another document, it needs to got through the whole process again.

One could think about a general signing permission represented by a refresh token, but not in the high assurance level cases I‘m looking into.

Hope that helps,
Torsten.




          

          

        

      

    

    

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


  


--------------94A230CB6D64448942D2CD7D
Content-Type: image/png;
 name="uma-signing-rpt.png"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="uma-signing-rpt.png"

iVBORw0KGgoAAAANSUhEUgAAAsUAAARzCAIAAAAL6swdAAAABmJLR0QA/wD/AP+gvaeTAAAg
AElEQVR4nOzdd1xT1/84/pO9FyNsRVDBjaJVcePes7VVqVbfVq3Wvq3WVa22ttZqtdU662ir
Vuugbqu4qKNahbeLOlAQQWYgZEMgyf39cT7NNz9GTCDjhryef/AIl3PvfYW7Xvfcc86lEASB
AAAAAADqgeruAAAAAADg8SCfAAAAAEB9QT4BAAAAgPqCfAIAAAAA9QX5BAAAAADqC/IJAAAA
ANQX5BMAAAAAqC/IJwAAAABQX5BPAAAAAKC+IJ8AAAAAQH1BPgEAAACA+oJ8AgAAAAD1BfkE
AAAAAOoL8gkAAAAA1BfkEwC4wY0bN/773/9OmTLl8ePH7o7l9TwrWgCAW9DdHQAAXuTp06f7
9+8/cuTI06dP8ZS4uLiSkpKzZ88uW7aMy+Xau8Dr16/Xed7XqjHaFi1aOHxFAIAGAPIJAFwh
NTV127Ztv/76a3l5OULIx8fn448/btGixYgRI9q3b5+WlqZSqTZv3mzvYmfNmlXneesWrQPX
AgBoSCgEQbg7BgAauIqKCj8/P7VajRAKCQn55JNPpk6dKhAI8F8XLly4bt06Go329OnTyMhI
u5Zcn3nrFi0AANQI6icAcDqCIJhMJkIoICDg8OHDcXFxln9du3bt8OHD//zzz4CAAHuXXJ95
6xatpZKSEpPJ5O/v75D12rW04uLi8vLykJAQCoXi7MAAADYhAADOd/ToUR6Phw+6kSNHXrt2
zXr5nJwcmUxmOaWgoIAgiMLCwpkzZ+7bt6/6LNYLVF9gfaLNzs4eMmQILhAfH19UVFSlQGFh
YU5Ojk6nIwhCJpMtXbr07Nmz5r8WFRXl5eVZX1ptX0ev17/33ns4jejatatSqbQrMACAk0A+
AYCLvHz5curUqXT6/1UKvvPOO2VlZQRBqNXqdu3a/fLLL7jYixcvhg0bhhCi0+kbNmzAE/fv
348Q2rdvX69evRBCFArl1q1blvPWVqC2BdY5WoIgZDJZWFgYQsjHx4fD4SCEPvroI/ynysrK
OXPmNG/e3HzH0rFjx08//RRf3c0L7969u1Qq1ev1tS2ttq9jMBhGjhxpeUc0ffp082KtBAYA
cDbIJwBwqaysrFmzZuEHChMmTCAIIjs7GyE0atQogiBycnLwFZFKpeJr8Mcff/zdd99t27at
Ss3inDlzLOetrUBtC6xztARBjB49GiFEo9Fu3LgxefJkhFDfvn0Jgnj06FFMTEz1StD27dsj
hBYvXoxnVygUAoGARqPhqoUal1bb18HTmUzmzz//fPjwYYRQjx49zNHWFhgAwAUgnwDA6Z4/
f25Z208QxIULF4RCIYPBkMlkuOVj69atCYKYOHEiQqh58+ZPnz5VKpVnzpxBCPH5/HXr1uHL
KofD2bBhA0Koc+fOBEGY562tQG0LrHO0Dx48qJ4xbN26lSCIAQMGIIREItHkyZMTExODgoIQ
Qo0bNx48eDBCyFwB88UXXyCE3nzzTYIgaltabV9n4MCBCKH169fjRW3ZsuXSpUv4s5XAAAAu
AONZAeB0kyZNGjJkyLvvvnvr1q20tLR79+7l5+eXlZUZDAaDwcDn89lsdlpamkKhkMlkCKG2
bdviKfjSGx8fL5fL8aJ27dr10UcfCQSC4uJihJB53szMzBoL1LbAOkd79OhRhNDkyZOHDRvG
YrEaNWr0zTffzJo1CyGE17h+/fqlS5d+9dVX+fn5eGlNmzZFCJ08ebKsrCwxMXHNmjUsFmvV
qlUIodqWVtv3xf1Xy8rK8F8/+OAD83exEhgAwBXcndAA0PAtWLCgxqPvww8/xAUiIiIQQnK5
/Lfffqte7Pr16wkJCcii9r5169ZUKlWlUpnnxS0kqheobYF1jhZfoVeuXFl9xoULF1afa8+e
PU+ePMFPTPAzFwqFsmfPHjxLbUur7ft+//33eLH9+vXbuHHj7du3jUaj9UUBAFwD8gkAnM5g
MGzcuLF9+/YMBgNfUKOiotavX28ymXCBJUuWtGzZEn9eu3Zto0aNeDxeYGAgQqhRo0ZGoxHX
+ZvzAHxzf+7cOfO8VgrUuMA6R3vw4EGEEJ/Pv3nzpnmWoqKiI0eOLFu2jE6nUyiUkJCQDRs2
4Av86dOnCYK4ePFiSEgIlUodNmzYlStXzDPWtjTcSfWzzz6r8nWMRuPcuXMt8xUejzdr1izr
gX377bfnz5+vw4YDANgO8gkASOrWrVsIodGjR+NfHz58aP6TVqtdtWoV7o1p9toCVRZYN0aj
sUePHriyITY2tlu3bvhxBhYbG2su+cMPPyCE5s2bV/+lVfk6jx49mjdvXseOHfEo48OHD7cr
MACAM0A+AQBJ/f777wihNWvWkG2BSqXy/fffrzKQVMuWLadPn37v3j1zsczMTA6Hw2KxHjx4
UP+l1UilUv3zzz8Gg6H+iwIA1BOMtw0Auej1+tLS0sDAwLVr1y5atOj06dNDhw4l1QKxV69e
paSkGAyGgICANm3aiMXi6mVWrFjxxRdftG7d+uHDh/VfmgMDAwA4HIy3DQCJlJeXR0VFlZSU
3L1799GjRwihZs2akWqBZqGhoaGhodbLfP75561atVIoFA5ZmgMDAwA4HNRPAEAicrk8ICDA
YDDgd08UFxer1Wrz0NdkWCAAANQIxp8AgER8fHwOHz7s5+cnk8lkMlmPHj3qee13+AIBAKBG
UD8BAOk8f/783Xffffbs2eXLl9u0aUPCBQIAQBWQTwBARgRBVFZW4mGgyLlAAACwBPkEAAAA
AOoL2k8AAAAAoL4gnwAAAABAfUE+AQAAAID6gnwCAAAAAPUF+QQAAAAA6gvyCQAAAADUF+QT
AAAAAKgvyCcAAAAAUF+QTwAAAACgviCfAAAAAEB9QT4BAAAAgPqCfAIAAAAA9QX5BAAAAADq
C/IJAAAAANQX5BMAAAAAqC+6uwNwCqPRqFKplEql5l9VCggEAjqdjn+KxWKJREKhUNwSKrCR
Wq2urKxUKBR6vV6n01UvwOfzGQwGQojL5bJYLMspADiE0Wik0WjujgI0ZHq9vrS0VKFQaLVa
hUJBEIRarTYYDFqttqKiora58LUMWZz9WCwWl8vlcDhsNlskEjEYDKFQ6Ozg7csnysvLqVQq
k8l0UjSvZTKZiouLi4qKCgsLCwoKZDJZQUEB/lBYWFhaWqpSqbRabVlZmXkWnDdUWY5KpTIa
jZZTJBKJj4+PRCLx8/MLDAwMCwsLDAwMDQ0NDg4OCQkJDAyEhEOv1zOZTAf+H3Q6XW5urkwm
w5uvsLBQJpMVFRUVFBTgLLCiosJKAmELGo0mFAp5PB4+qLhcLpvNFluQSCRVPgcEBMC2Jqfy
8nKj0cjj8Zy0fKPR+PLly+f/yszMVCqVCoUC/8Qnd8vybDabw+Hgz0wmUygUikQisVgs+hee
gj/gfQxPkUqlsI+RU3l5OY1Gc/Z9iFKpzMrKys7OfvnyZU5OTnZ2dk5OTlZWllwut7x4SSQS
9G+ugDOD2hZo3jlx8oEQ0ul0er2+SjG8xwoEAgaDIRaLeTyeUCgUCAR4/zR/xj8lEolAIBAI
BEFBQTZ+L0qVI8SKoqKiMWPG3LhxQyQSBQQE+P1LKpX6+PiYDxtzQGKxGFmkS7UpKysrKytT
KBQ6na6srEypVOKEoLS0tLi4GF9scMaAfzWZTAghoVAYFBTk7+8fEBBg/uDj4yMQCPh8Pp/P
FwqFQqGQz+db2QYajQbf8paWlpaUlJSWlsrl8uLi4oKCgpycnPz8/Nzc3MLCQqPRmJ+fHxgY
aOM/qkFSKpWjRo26efNmk3+FhIQEBQVJpVKpVOrr64v3VJFIRKVS8a5cXl5e+i/8T8b/0ry8
vLy8vNzcXKVSiRBiMpl48wUEBPj7+0ul0qCgID6fb97pmUwmj8fDlQ0SiQT/WmOEeN8wH1Eq
lUqv16vVao1Go9frlUqlTqcrLy9X1AIffrCtyUmhUIwcOfLq1as0Gs182caXZ3yw41OQebrl
bQ/eLc2/6nQ6pVJpzhUKCwtxApGVlVVRUSEWi5s2bdq0adOIiAiJRIKXiT9YLgQhVFFRodVq
8efKykpcJ4rvapRKpeVP87rwbQzsY+R0586dt99+OzMzUyqVWl5cAgMDpVKpRCIx33ZKJBJb
8lqDwVBYWJiTk/Pq1atnz549e/YsPT392bNnRUVFCKGgoKBGjRqFhYU1atSoUaNGjRs39vX1
lfyLy+XW/xvhWg2FQmEwGFQqVXl5eVlZmbmuV6vVqtVqlUqlVqtLS0vNn9VqNd5jcXqQl5dn
Y0phRz5x9uzZhISEK1eu4JvI4uJifIEvKirCp2OlUokDssywzHCqVUVpaen/LxoKBSdNHA5H
LBb7+/v7+fnhzYk/S6XSgIAAqVRqJUtwrMrKSg6Hc/v27Q4dOrhmjeT07Nmz5s2bnz9/vrCw
MDMz88WLF3l5eTjPKyoqwhfyGrFYLPMRIpVKw8LCgoKCQkJCgoODg4ODg4KCatwx3EImk0ml
0vT09GbNmrk7FlDVo0ePWrVqde/ePb1er1KpSktL8dXafNlWqVT4RIQ/W96cVamPxHVU5uRD
KpU2adKkWbNmOI3w9/d33rfA+9jTp0+bN2/uvLWAupkzZ05ubu5nn32Wn59vWfmdn59fXFyM
bzjNGSSVShWJRLj+u8pNjlarNV+YEUIMBiM4OLhp06bNmjVr1qxZ8+bNmzdv3rhxY+t32mSg
0WjCw8P37ds3ePBgW8rb8bzjwYMHbdu2bdu27WtL4lRIoVCgf2tdCILAv1YhFos5HA6Hw5FI
JNbrc9yFwWAEBATk5uZ6eT6h0WgoFErfvn2rPz/GGxdnvuaUViwWs9lsR2XZruHn50elUvEp
AJCNXC5ns9nt2rVzdyD14ufnR6fTVSqVuwMBNXj06NHAgQPbt2/fvn372spUVFTgOld8E28w
GNRqdZVnslwuF9eZSSQSXPPqoY+3+Hx+mzZt7t+/7/h84vHjx61atbJpoXS6j4+Pj4+P7Qsn
s5CQkNzcXHdH4WYajYbD4dTYGI1CoZCnjqE+KBQKl8ut3noXkEFpaWkD2M0oFIpAIIB8gpwy
MzMjIyOtl2EymThFcE1Ibte6detHjx7ZWNiO/qI5OTmNGzeuU0ieLTg4GPIJjUbjvHZw5CEQ
CKB+gpwUCkUDyCcQQkKhELccAmRTXFwslUrdHQW5hIeHv3z50sbCduQTubm5ISEhdQrJswUF
BeXn57s7CjfTarV8Pt/dUTgd5BOk1TDqJxBCQqEQ6idIiCCIsrIyD3o+6xrOyicKCwu9p5LH
kq+vr1wud3cUbqbRaCCfAG7UYPIJkUgE9RMkpNPpTCaTN5zl7OLr61tSUmJjYVvzCYIgNBpN
9YEcvIFEIoF8Ap53APdSKBS4C7qng/oJcqqsrEQIwQh4VYhEIq1Wi3vgv5at+URZWZnRaPTO
3M3Hx6dKv1Yv5CXPO/h8PuQT5NRg6icgnyAn3AXDStd378ThcAiCqD40Vo1szSfwSJ9uHBnT
jXx8fKB+QqvVQv0EcCPIJ4BTeWiXTmfD/f+rjORWG1vzCfy/tn3wq4aEx+OZxzDxWvC8A7hX
g3neIRKJIJ8gIaifqBF+0mHja2tszSdweuKd+QSbza5xxE+v4iWtZ7hcLmxrcmow9RMCgQDa
Y5IQbjmBW1EAM7lczufzbXw0YWs+gUeu9M5TLYfDwUN8ujsQd/KS5x2QO5JWg8knoH6CnFgs
FpVKLS8vd3cg5FJUVGT7CPS25hMMBoPD4XjnYcBmswmC8PL9zEv6i3I4HMgnyEmn0zWMjBb6
i5IThUJhsVhw+FdRXFzs5+dnY2E7xp/w2mZE+FmPlz9X85L2E5BPkFZlZSWdbsf7AUgLxtsm
LS6Xa/kaDoAQksvltr86w47j02vzCczLW/96Sf0EPO8gLaPR2DDyCR6PBxctcnL47URKSsqV
K1e6d+8eHR3toU/rCgoKbB/H0o7j02ur6by85QTmJe0noH6CtBpM/QSdTrdxdCDgYhwOx7HP
tdPT05csWWI0GhFCAQEBHTt27NGjx9SpU21vkeB2r169atmypY2F7Xje4bXNiHA+AfUT3lA/
AfkEaRmNRhs7rZEcjUaDfIKcHH74T5gwwWAwEARBEMTdu3cTEhJu3boVHh6+f//+Oi9z9uzZ
u3btcmCQ1tn13i478gmJROKdw0RqtVoajYZ7uHgtrVbrDW/KgXyCnEwmk8lkajD1E/iGFZCN
kw7/xMTEJUuWBAUFjR8//tixY9u3b588efLJkyfrtjSCIK5fv15loslkun//flpaWr2DrcpZ
+YRUKi0qKqpTSJ5NpVIJBAIvr58wGAzeMLI9m8328o485IRv6BtGPgH1E6TlpHzi4cOHOTk5
5l8TEhImTJiwevXqui1NKpVmZWWZf62oqNi6dWvTpk07d+68aNEix+5aRqOxsLDQKfmEv7+/
d+YTarXaG4Zysq7B1DZbR6PR4N6RhOwapI/koP0EaTmpf0dubm6V21EfH5/6JC7mhoypqakd
OnRYsGDBiBEjnj9/fubMGcfm3IWFhUajMSgoyMbykE+8nlqtFgqF7o7Czbwkn6BSqV7eMZic
8FmyYYxdSKfT8eMbdwcCquLz+c54tYJCocAnT4PB8Pjx4wULFmzevHn48OF1XqDJZNJoNAsX
LuzSpYuPj09aWtr3338fGhrquJD/T1FREYVCkUqlNpaH5x2vh593uDsKNzOZTDa+EsajQT5B
Tkwmk8/nN4z2W+ZLi7sDAVU56fU9BEEcPHiQQqEwGIyWLVuuX7++a9euy5cvx3/V6/UffPAB
g8GgUCht2rSx3MnT0tKOHDmCEFq/fj2NRktMTMTTX7x4ER0dvXHjxsWLFycnJ0dERDg8Zqyo
qEgsFtv+pBvyideD+gkE9RPA3Xx8fBpGPgHj45GWk8ZYolAoFRUVEonEfGHOz8/Py8tDCBkM
hnHjxl25cuXQoUPPnj0LCQmJj483j1Bw9erVTz/9NCUlZcmSJSaTafHixXhparU6Nzd3y5Yt
q1atcuptnkwms71yAtmbT+h0Oi9806ZSqYR8AuongHv5+PjI5XJ3R+EAGo2GTqd7eX8xcnLS
0KW+vr7BwcFyubyioiIvL2/37t0EQQwZMsRkMu3YsePatWtJSUljxowJDw9/+PDhvXv3Tp06
hWc0GAzFxcVDhw7t16/fnj17nj9/npOTIxKJWCyWRCJJTU11eKhVyGQyu4bKsK/9BF6B3UF5
uKKiIrtytAYJ8gngXg2mvzrUd5KWk553zJo1a9asWfhzUFDQ1KlTz5w58+TJk+vXr1+9enXc
uHFhYWEIoWXLlsnl8sjIyEWLFlVUVCCESktLS0tL+Xz+0aNHx48fT6PRioqK0tPTAwMDFy5c
uHPnznPnzjm1P5q9+YQdbUElEgmVSpXL5eHh4dZLNoBBRi0VFBR07drV3VG4Ex6PxRued0D/
DtIKDAzMzc11dxQOUFBQAPcn5OTw5x1paWlUKrVdu3bt2rWznH7t2jWEEJfLjYyM/OGHHwQC
QUpKyo0bN/bt29euXbs33nhj2LBhiYmJ+fn5CKHt27fjsX/CwsIePXr0448/9u3bd8GCBefO
nRsyZAidTk9PT3/tRblunJhP0Gg0kUhUUlLy2pINYJBRS4WFhbYPYN4g4U0J9RPAjaKiov7+
+293R+EAL168aNy4sbujADVwbD6h1+tjYmKMRuMbb7yBayCwrKys1NTUGTNmdOzYMTIy8q+/
/tq4cWN4ePj58+f79++PEDp8+PD48eM/+OADqVQ6YMAAPBEh1KtXr+vXr7du3XrGjBl0Ov3s
2bPvv/9+UlISi8VyVMxVlJSUREdH217evr6qNj7CnDBhwoQJE/Dn/Pz8q1ev/vbbb1988cWO
HTsmTZpk1xrJoLCw0MvvJ/Al1hvqJyCfIK2oqKi9e/faNUt5efmZM2e2b99+6dKlN95449at
W06KzS537txp3769u6MANXDs8w4WizVo0KDLly/fvn379u3bCCEKhRISEtKpU6fZs2dPmTIF
ISSRSJKTk6vMOGzYMNxOsaKiwvKC+9lnn929e3fHjh34Vy6XW59xu21h79hL9uUTvr6+ttRP
YImJiSkpKV9//fX48ePHjx+/b9++yZMnC4XCESNG2LVS9yIIQiaTQf0Esr9+Ii8vT6vVBgYG
pqWlyWSy+Ph48r8BBPIJ0mrRokVWVlZZWRmHw3lt4YyMjM8///z48eNqtbpLly67du2KiYkZ
O3asyWQ6duyYC6KtDUEQN2/efP/9990YA6iNw9tPnD59uj6zM5nMwMBA868RERHO6xpaIxsP
NzP7rhC+vr62N7F27CCj7qJQKCoqKqB+AtmcTxw+fJhKpeJMvHnz5kKhMC4ubuTIkWvWrHFy
mA6A62CgCQUJNW3alCCIzMxM68WMRuOIESOioqL27dsXGxt77ty5mzdvTp06tUOHDgih48eP
//bbby6Jt2bPnj2Ty+Ve3h6LtIRCoU6ng8PfzN58winPOzCHDzJaI7Vaffbs2ZSUlLZt2yYk
JDh24QihgoIChJCX108wmUxk8+iEjRo1at26NZfLTUtLi42NnT59emBg4I4dO8yPwKpz9ka0
Hd5j4Q31JMTj8QICAjIzM1u1amWlmEajwd3tLly40K9fP8s/HTly5Ndff3Vv34qUlJQmTZr4
+fm5MQZQG4FAQBCEWq0Wi8XujoUUnJtP2PW8Q6FQ8Hg8hJDBYHj27Nnu3bs3b968ZMkS/NeS
kpJ169a9evUqJiZm2rRp9nYDMRgM8+bNKygoOH/+PK6hCg8Pr3Ip+vvvvy9duhQYGDhx4kTc
YqUOKy0qKuJyueSvqHcqBoPBYDBsHHqkS5cuDx48QAj16tXrww8/HDduHEKoypndLDMzc8OG
DXv37q1tI1ZX20Z0yOaGsYbILCIiIiMjw3oZkUj01VdfLVu2bOrUqStXrkxISDAPIkSlUuuT
rTpkB0tNTY2Nja1zDMCpcK6pUqkgn8DszSf+ryugjZYvXz5y5EgbC48dOxbf15p169atvLyc
IIjKykrLGr+wsLDbt28nJibiZ0UUCiUuLi45OZkgiC1btvj5+eXn51dZOG7MghDq1KnTnTt3
KioqqhSYP38+QsjX1xch1KtXr9pW+tpvcfTo0caNG9v4lRswiUSSlJRk1ywRERFPnjwx//rw
4cPDhw8TBPHtt99SqdSjR48SBDFkyJAaN+LBgwfFYnFeXp55ypYtW168eFHbRnTU5sYv/C0r
K7PrmwLXSEhImDNnji0l//rrr169euHtvnXrVqPRSBCEyWS6d++eZZklS5acP3/ePKXGXRRz
1A42ePDgzz//3NYvDFwLV5//888/7g6ELAICAk6fPm17efvyidWrVw8YMMDGwvjG1HKQ0YiI
iMzMTIIgcIXk+vXrjUajXC6fN28eLsBkMlevXr1v375BgwbRaLRff/118uTJCKH79+9bLvng
wYM0Gm3OnDkMBsPX13fv3r34fGG2adMmOp3+yy+/EASxfft2hFBOTk71lcbGxr72W2zevPmN
N96w9R/UcIWGhh47dsz28gqFgslkGgwG85QtW7Y0a9bszp07eH/Aj8OPHDlS40acM2cOn8/X
aDTmKf7+/uvXr69xIzpwc9+7dw8hVD09BWTw6aef2n4/QxBEcnLyoEGDEEJvvfWW0Wh8+fIl
g8HAyeLHH39sfhqbnZ2t0+mIWnZRwqHnk5iYmJ07d9blywOXYDAYt27dcncUZCEUCi9fvmx7
efvyie+//7579+42Fp4xY0ZwcDD+jAcZbdKkSXR0tNFoXLJkSWBgoOX1Y9asWXQ6/ebNm+Yp
X3zxhUQimTNnTkhICEEQEyZMGDZsGEEQt2/f5nK5mzdvJggiJSUF34W0bds2MTHRZDIRBCGX
ywUCAZ/PHzdu3OzZswMCAkJDQysqKqqv1BYrVqwYPny4XbM0SNHR0fv377e9/MWLF1u2bGk5
ZePGjRKJRCqVDh48eM+ePfg8TtSyEcePH9+tWzfzvLhN/oMHD6pvRMdu7lu3btFoNLtmAS6z
du3aPn362DvX5s2bEUL79+/Hbb8yMjK+++47hNC8efN0Ot2rV6/++ecfFot1/vz5GndRx+5g
QUFBp06dsvcrAJeRSCQXLlxwdxQEPg26Zi4rGAyG5UX5tezr38HhcGx/PbyVQUblcjmPx7Ps
L8BisRo1atSlSxfzFJ1OZzAYjEZjZGTk9evXDxw4cPr06XPnzo0aNeqtt96aPXs2Qig2NjY5
Ofnu3bthYWFjx46Nj49XKpUHDx5kMplHjhzJzMzcuXNno0aNzp07x2Awqq/UFjDYNsbj8TQa
je3lk5KSgoODLafUOHYsqmUjstns3Nxc3NBao9EsW7Zs/Pjxbdq0qb4RHbu57X5eCFxIKBS+
tjvfokWL1q1bZzll2rRpQqHw2bNnYrGYTqdfv3792LFjwcHB69ev53A4ISEhu3fv1uv1/v7+
Ne6ijt3B7O3QD1zMSUNu2+Wnn37y9/e363xr+1wbN2785ptvbFmgwWCorKx0YntMHo9nSz7x
2kFGNRpNlSZv3bt3//7775cuXdqnT5/i4uJffvnlwoULBw4cSEtLy83NnThxYuvWrdPS0gYP
HtyzZ8+tW7cihEwm08SJExcsWBAbG3v69OkrV65MnTp15syZEomkZcuWgwYNwlWdZtVXaguZ
TBYZGWnvXA0Pn8+3sT3m5s2bFy1apNPpOBxOmzZt8Gv0/vrrrxrHjm3fvn2NG3H69Om//PLL
pEmTevfuvXnzZoPBgOuZq2/EtLQ0B27u8vJyyCdISygUKpVK62XS0tLOnj2bmJjYpUsXOp2u
1WovXLhgMpkmTJhAoVD8/f0LCwsHDBhw9erVUaNGvfHGG1evXk1KSoqPj2/fvj0eKajKLurY
HaysrAwvHJCTLTmr2Z07d77++us5c+bEx8c7MIYrV66UlJSo1Wq7+gHYOOuyfrgAACAASURB
VFd2dvaGDRuio6NHjhxpfYF6vR7927nPRvblExwO57UdPm0ZZJQgiJcvX+p0OvOhNWbMmKVL
l+7atevrr7/mcrl9+/a9du1aXFxcmzZtvvvuu3Hjxu3atWvZsmXl5eVffvml+Yx/7dq148eP
jx07NjQ0VKPRaLXau3fvzpgxY8eOHSkpKR07drQMrPpKbaFUKqGtL0KIz+fbeJhlZGSUlZUJ
BIKwsLB+/fq1atWqR48eUVFRPB6v+tixEydOrHEjxsfHb9++fd68eefOnRs3btzq1avxVqi+
EZs1a+bAzV1eXg4vfiQtW4ZD3rdv39q1aw8cOLBp0yaCIFgsVvfu3Q8dOtS8eXOEUM+ePcPD
w0ePHp2dnf37778nJSWFhoYihPC4vTXuotHR0Y7awcrLy41GIySsZGb7ie7+/fv9+vWbPXt2
z549HRvD/fv30b991x0+17p16+7du7d06dIRI0ZYL1yXzvN2PU05e/asv7//a4sNHTrU8pih
UCihoaGjR4/es2cPfsBz8eLFESNG2LXqGhUXF8+cOTM4OJhCoUgkkt69e9+6dUuj0TRp0kQq
lR44cCA9PT09Pf3kyZMLFy7EweAGobaLi4vDJyYvN23atBkzZtRnCXq93rKfTkZGBm4/X+NG
rG0h1fccx27uX3/9tXnz5nZ+M+AiV69e5XA4jl3mkydPEELPnz8natlFHbiD4brox48fO/Yr
AAfq37//119/bUvJnj171qE1z2vJ5XI8ql71Xo11m6usrOzo0aP9+vWjUCidO3cmCAIP/n3i
xAnry8RvLn348KHtYdiXTyQnJ/N4PLtmcYvnz593797dMm1isVhdu3ZdtWqVvV0B27Zti19X
7+U+//zzwYMHuzuKmjlwc+/evbtdu3ZOihPUkzN635w+fTo0NNR6GUftYLhy164TNHAxXFP+
2mJ4V6zS8bC6goKCLVu2WE5JSkrCnQkIgsjKyqre2nHbtm24Uc6rV69sD7vGuZ4/f56QkIDb
63Tp0mX37t2pqan4T7169Ro6dKj1ZeJ3plt2sX6tujzvIAjC3qoYF4uMjLx27VpqampWVhaV
Sm3atGl0dLS526pdtFotHpXLyzVq1Ojw4cPujqJmDtzc0B6TzPAdmGNHG8vJyWnZsqX1Mo7a
wZwRP3AsG9tjHjp0qGPHjm3btjVPUavVrVu3PnHiRExMjHnijRs3Zs+eHRcXhycSBDFz5sz8
/PyZM2fSaLTJkyffuXOnSru0H3/8ccaMGdu2bVOpVCEhITaGXWUuo9E4evTos2fPGo3G3r17
L168eODAgZbl586d++abb+bm5lpZRR0G97Mvn+ByuSaTSa/Xe8Qz5tjY2PoPRafT6SCfQAg1
atTo5cuX7o7CGodsbmg/QWa4v49D3nO7adOmnj17xsTEPHnyJCoqypZZ6r+DwdthyM/GfCIp
KalTp06WU1JTU7Ozs6u0hcSv7zLfopw5cwa/gKaysvJ///vf1atXmzZtaln+4sWLubm5M2fO
3LZtm43t32ucy8qo89ioUaNCQkIOHjy4YMGC2hZbh3zCvs5OXjgasUaj8fLBtrHGjRtrNBrb
R1v3UNC/g8wclU/k5+d/9NFHI0eOTE9P/+uvvxo3buyI6F4PvycP8gkyszGfUCqVBoPBcsrV
q1ebN29ePT/w8/Nr1qwZ/tX8TkS9Xv/BBx8QBDF06FBzYaPRuHTp0kWLFuHyNuYTNc6FR52n
UChTp07ds2dP9VcvUanUAQMGnD9/3sqSKRQKlUq1a3e1L5/wNgRBQP0E1rhxYwaD8ezZM3cH
4ly4m6u7owA1MxqNFAql/g9bg4KCVq5cmZeXFxUVdefOHVe+7dPeEzRwMVv6MCKE/P39//77
b8spL1++rPIycYIgfv75548++gjfhx87duzmzZt9+/ZFCM2dOzclJQUhNHjwYHP5zZs3q9Xq
OXPm4D3cxldv1jbX0qVLb9y4ERERMW3atMjIyG3btlWpCGjTps2LFy+sL5xKpTqxfsLb3r6I
+3dBf3GEEJ1Oj4yMTE9Pd3cgziWXy318fNwdBaiZ0Wh0yMMOhNCKFSsuXLgQFhb2zjvvxMXF
OWSZtrD3BA1czMZ84u2333748OEff/xhnlJeXl5lpLKjR4/m5ubOmDEDIaTRaBYuXDh9+vRh
w4YhhPbu3Yunmzshl5aWrlq1qn///vv37//www8RQuPGjdu2bZv1MKzP1bVr1+Tk5OTk5Fat
Wn3wwQfvvPOO5b7HYrFeO/iVvburfe0nvA2u0apby76GJyoq6unTp+6OwrlKSkqq3GQA8nBg
PoEQ6t27d0ZGhouPbhqNBvUTZMZms3E/Sevee++9zZs3z5kzJzU1FQ+N4+fn97///c9cQCaT
zZ0796uvvvL390cIzZgxQ6/Xr1279q+//kIITZgwoUuXLidOnDDfvbz//vslJSU//PAD+veK
07Nnz9e+DteWuXr16tWrV68tW7bMmTNnxIgREydOxNOfP3+OB2Wxwrn1E94G18SQvDOLyzRv
3rzBP+8oKSnB75AEJOTYfAK541YB8gmSs7F+QiAQHDhwIC8vb/Dgwbi9Rc+ePW/cuHHr1i2E
kEKhGDVqVJMmTWbOnIkQ2rFjx8GDB3ft2iUUCvv37//jjz/u3r27qKjIPN7jN9988+effw4Z
MmTBggVJSUnFxcV9+vTx8/Oz3nTPylxWRp3Hvz5+/Pinn37Cw7hZYe/ual/9hLddX73nyY4t
goKC8NHSgMlkMj8/P3dHAWrm8HzC9SCfIDkb8wmEUMeOHXfu3JmQkNC9e/ejR4+OHDkyOjp6
0KBBAwcOvH79ulgsvnLlCpVK3bt376xZs+bPnz9gwACEEI1Gmz59OkKoqKgIt6vYs2fPypUr
L1++bNmORywW4wYWtbE+l5VR57Va7fTp048cOdKkSRP8+m4rnFs/gQe4YLFYds3luXA+Ye8r
fxoqqVSK3+DVgEH9BJmZTCZPzyfodHqVfgGAVNhsto35BEJo0qRJ27dvf/jw4aBBg6hU6unT
p9u2bfv77783a9bs0qVL+EWSGRkZQ4YM+frrr6vMazQacWa5du3akydPVmkUHBQU9PLlSytP
XqzPtW/fvkWLFuXl5W3atGn9+vU//fRTeHh4cnJy8+bNs7OzExMT33777QsXLrz2Uu7c9hOV
lZVUKtXTD2nbeVv7U+ukUmlhYaG7o3CukpISqJ8gLYPB4OknHy6Xa/srmoHr2V4/gc2YMSM4
OPg///lPZWVlRETE1atXqxT4/PPPa5yxQ4cOx44dQwjhEd+r+O6770aPHm1lLBzrc7HZ7DVr
1pi7p1pq0aIFftGXLRgMRvW+plbYXT/hVY0T8avVcK0M8Pf3VyqVdu1enkWj0ej1eujfQVqV
lZV0umc3Iefz+fa+hxq4EofDsaU9pqXhw4cXFhbaW22fkJCQlZVV21+ZTGaN41BZV7e5rLCx
daqZ3fmEXW8v9XR4F7E9m2vYaDQaHqTd3YE4C659wbWUgITUanWVLnkeh8fjQT5BZnY972jw
7K1Og/oJa6hUKp1Oh/oJDP8fGvAOkJOTw+VyoX6CtBpAPgH1EyTH4XAMBgO0ccGcm0944duS
WCwW1E9glZWVDAajAffuefXqlbkHFyAhyCeAs+H7JbiHxHg8nhPzCa1W620vs7C3eU4DhvMJ
d0fhRDk5OaGhoe6OAtSqYeQTtr/nCQD34nA4TswnGsDxbC8bXw/jDRp8PgH1EyTXAM4/kE+Q
XAOuf60DLpdr1+20ffmEF75sUygUqlQqd0dBCg0+n8jNzQ0JCXF3FKBWDSOfgOcd5NeAW53b
xen5hKcfz/aCfMKstLQUj1TfUOXn5wcFBbk7ClAryCcAcCV7uyNB+4nXgOcdZkVFRQ27L2Vh
YWFgYKC7owC1UqlUnp5PQH9RksOt771nDGjr7L2dti+faADHs72gfsJMJpPhd+U1VEVFRQEB
Ae6OAtQK6ieAs5WXlzMYDE8fNs1RhEKhUqm0vbx9+YRcLpdIJHaG5NkkEklpaam7oyCFhp1P
6HS6srIyeHkHmUE+AZzNC8dEsEIkEjmxfkImk3nbCdfPz08mk7k7ClJo2PkEHsHGq4Z/9TiQ
TwBn02q1PB7P3VGQhUgkcmL9hBe+fdHf37/Bv1TTRoWFhQ34cQCHw6FQKHCuJ7MGkE9A+wmS
y8vLg0bZZs593lFSUuJtoxH7+/tD/QRWXFzcgN+9yWAw/P39s7Oz3R0IqFUDyCegfoLk8vLy
goOD3R0FWdhbP2FfqxO5XE6j0W7cuFFWViYQCMLCwgICAjz9DcLWQT5hZu7fUVFRodVqlUql
Xq+vcnLkcDhsNtvyp5uCrYv27dunpKQMHz7c3YGAGhgMhrKyMsv+ZZWVlebdTygUesSJSCAQ
lJWVGY1Gj4jWC2VkZNgySK5CoVCpVCqVSqfT4RYGSqXSZDKVlZXV+EJOPp/PYDDwXioSiXg8
nlgslkgkJG+rgbsjEARh4zBfFNsH7sCDT9BoNCaTyWazNRoNfn1wQEBAWFhYcHBwaGhoaGho
cHAw/lUqlQqFwnp8F1K4ceNG9+7dy8vLvbwHUUVFBZvN7tSpU3Fx8cuXL41Go40zcrlcFotl
+ZPH4/F4PD6fLxaLeTwel8sVCoVCoRBPF4lEfD4ff5ZIJHgWp341s3Xr1v3222+pqamuWR2w
S2lpqY+Pz8SJE/Py8p48eVJaWlrlxI13MLFYzOVyuVwu3pFEIhE+ceOf5g9isVgkErm+tiM9
PT0qKkqhUIhEIhevGryW0WgMCgqaOXNmjx49ZDKZTCYrLi4uKioqKioqLi6Wy+UqlUqtVlve
sjMYDJzjikQiKpWK76OqL1mlUhmNRsufeDqLxZJIJFKpNCQkRCqVBgcHBwYGBgQE4AtoSEiI
ewdo+Oeff1q3bq1Wq20Mw458Iisrq0mTJnv27Jk8eTKVSjWZTIWFha9evcrLy8vOzs7Ly8vN
zc3JycnLy8vJycGDajEYDJ9/+fr6+lgQiUQsFkskEuENgBM3gUCAO+qYP9jFYDCYx4owmUxK
pZIgCIVCgRDCfTQUCgVBEDiRVKlUBoNBoVBotVqdTof3Ep1Op9Pp8EStVmu++4E3O+h0ulWr
VjEYjFatWjVr1gyfjplMZpUzslarxbUXFRUVOp1Or9fjnzhtxz8t/+H4/4yPUvxZoVDgVNW8
TBqNhhMOLpeL83qchQgEApFIhC8eeKAt3PlILBZTKBT8Ex/k+Kd5UXix5h2gsrIyJycnIyPj
ypUrZ86cKSgogAZZJJSdnd24ceO4uLiRI0dGR0f7+vry+Xy8++HDHO9gpaWluKsO3rsUCoVC
oSgtLS0tLcUfFAqF+ZUEeD8Ri8VCoVAkEgmFQoFAgH/FpyB8W4l/8ng8JpOJf9YWJD7D6PV6
5b8UCoVcLi8oKMjPz8/LyyssLDQaja9evYKRWEkI3z0ihAQCQWBgoL+/v5+fn1QqDQgI8Pf3
9/HxEf4L7yRCobBudztlZWXmvVEulxcWFubl5RUVFeXm5hYWFubn5xcUFOBrKJfLxUlGYGBg
UFBQQEAAzjwsU+Q6xKBUKlUqldKCXC4vLi6WyWQFBQVFRUUymayoqEgulyOEbN9d7cgnUlNT
d+7cuX37dlsKl5aWymQyuVwul8tLSkrk1eDacqVSWVsFEWZOLGob7BmfRF4bj+U1xnylodPp
lnfD+M6Gx+Phswm+aEkkEh6P5+fnB/WTroSrsqVS6Z07dyoqKswJh06nwxcMrVarVqtxfSNO
AfFFpcpPG1cnFosjIiJatGgxa9asbt26OfWrgbrJzc29cePGm2++Wf83LOj1eoVCgU+pOOHA
51aVSvXll19OmjQJ30vgnbDGn7UtGWe0+E4Jwyf9wMDA4ODgkJCQkJAQfFWA90SQUElJSVlZ
mb+/Pxlqo2k02sOHD2UyGU5DcZJRUFCQl5cnk8lKS0vNL0HFt0w48a1eQYJvrRFCeNe1fEqI
EGKz2XhHlUgk/v7+/v7+gYGBUqnU399fKpXipEoqleL7sdeyI5/IyMgICgricrk2lrdLlWuA
+QOuS0AIjR49et++fdVrXeh0uuUtsuXwGJZ3q86IGTgbn88vKCioT42f5X6FaxotF85gMCQS
ibnGEgCJRPLixQu7xpXX6XQMBqNhv9oGuB6TydRqtVb2K1z9hh/8KRQKXDGM64OrlMSXQnzG
w48FcQ5R5/qV2tjxTCEyMtKBK67Csr66RgKBoHPnztCTx6uwWCxzDl43r92vALDEZrOtVJfW
yEm3WMDL0Wg0g8FgJZ/A1eqkenBmX39RN+JwOHa96Aw0AEwms575BAB2gfMMIAk6nW57s3eS
8Jh8gs1mw3HubSCfAC5Wh/oJAJyBRqNBPuEsHA4HjnNvA/kEcDHIJwBJQD7hRFAP6YUgnwAu
BucZQBKQTzgRPO/wQpBPABeD+glAEpBPOBE87/BCkE8AF4N8ApAE5BNOBPWQXgjyCeBicJ4B
JAH5hBPB8w4vBPkEcDGonwAkQafTDQaDu6Owj8fkE/C8wwtBPgFcDPIJQBJQP+FEUA/phSCf
AC4G5xlAEpBPOBE87/BCkE8AF4P6CUASkE84ETzv8EKQTwAXg3wCkATkE07kWfUTn3322bp1
69wdhceDfAK4GOQTgCQ8MZ+w4/2i7uVZ9RMqlSonJ8fdUXg8yCeAi7HZ7NLSUndHAYBH5hMe
Uz/hce2ktFqtu0PweJBPABfzuPMMaKigv6gTedbzDoPB4HG7AglBPgFcDJ53AJKA+gkn8qzn
HTqdzt0hkEtGRkYd5oJ8ArgY5BOAJCCfcCLPqocsKytjMpnujoJETpw4cfnyZXvngnwCuJhn
nWdAAwb5hBN51nGu0+l8fHxeWyw/P/+XX35xQTxuN2HChDFjxiQnJ9s1F4PBgHwCuBLUTwCS
gHzCiTzrOKdQKH5+fq8t9vfff//nP//xuJYWarX60KFDn3zyyb59+2yZjhAKDAzs2bPngAED
7KqlgPoJ4GKedZ4BDZgn5hOe1F/UgfUTaWlpx48f5/P577//PpfLddRizTQaTVBQkOWUv//+
+9KlS4GBgRMnTmSxWObpBoOhtLTU39+/yhJqK2+jkpKSdevWvXr1KiYmZtq0aRKJxEphK/+N
KmFkZmZu2LBh7969arUaIRQeHp6QkIAQqm26pY8//vj06dPDhg07e/Zs7969bfkWkE8AF/Os
elDQgHliPoEID/HkyZOoqCiHLOr06dPmK3Tv3r3N0xMTEwMDAxFCFAolLi4uOTnZcq7c3Nyi
oiKCILKzs3fu3Gmefu3atQ4dOohEosWLF7969QpP7Nat2++//24uM3/+fISQr68vQqhXr154
olqtXrt2LUKoR48ezZo1o1KpCKHExMTaytemegCVlZVdu3Y1b+KwsLDbt2/X9u1q+2/UGMaQ
IUMQQp06dbpz505FRYW5ZG3Tq2jcuDFCiMvlXrp0yfqXwrZu3Tpr1ixbSgLgEHfv3o2JiXF3
FAAQI0aMOHHihLujsI/H5BMvXrwIDw+v/3JSUlLYbPYbb7xx/fp1PITlixcvCIJYtmwZQojJ
ZK5evXrfvn2DBg2i0Wi//vrrxYsXly9frtVqRSJRnz59KisrO3bsiBD6888/CYKQy+UikQgh
FBMTExsbGxAQkJGRQRBEVFTUH3/8gde4adMmOp3+yy+/EASxfft2hNAnn3wSFBSEEwiEUEBA
wNtvv/3DDz/cvHmzoqKievmcnJzavk6NAZw6dQohtH79eqPRKJfL582bh1dU/dvV9t+oMeyc
nJwjR44wGAxfX9+9e/cajUZzGLVNr2Ljxo08Hs/2lGLXrl3Tpk17bTEAHMWB9y0A1Mfo0aMt
b0o9gsfkE3l5eUFBQfVfzoQJE3x9fYuLiwmCqKys/Pzzz8vKygiCmDVrFp1Ov3nzprnkF198
IZFIfv7555iYmBUrViCE2rVrN2/ePBaLxePxVq5cSRDETz/9hBDy8/MrKSnRarUdOnTo27cv
QRCRkZEnT54kCEIulwsEAj6fP27cuNmzZwcEBISGhk6cOJHD4YwZM2batGkIodu3b5tXWmN5
K3f8NQawZMmSwMBAy+t6bd9u/PjxNf43rISRkpLSq1cvhFDbtm0TExNNJhNeYG3TLSkUCnNd
CJfLvXLlivWNtXfv3oSEBOtlAHCgzMzMJk2auDsKAIhx48YdOXLE3VHYx2PaY7JYLL1eX//l
ZGVlderUCdfh0+n0zz77jM1m4+U3atSoS5cu5pI6nc5gMBiNxgcPHnz55ZctWrR4/Pjxpk2b
9u/fP3ToUDycdmZmJkIoIiLCx8eHy+VOmTIlJSUFIUShUORyOULo4MGDTCbzyJEjmZmZO3fu
bNSo0blz5/bs2SOTyRITE1evXo0QIgjCvNIayzMYjNq+To0ByOVyHo9nrv+w8u0yMjJq/G9Y
CSM2NjY5Ofnu3bthYWFjx46Nj49XKpVWplsSiUSxsbHmAIYOHWq9eSa0nwAu5qjzDAD15Int
J7wun2jfvn1SUtLmzZurtOLu3r17Zmbm0qVLL1y4cPDgwUGDBq1du3bnzp1MJtNkMr311ltv
vfVWRUXFRx99NG7cuMjIyGfPniGE8vLyxGLx7du3Fy9enJyc/Ntvv+GWlUKh8Pnz5wihtLS0
li1bDho0KDU1Va/X3759u1WrVkwmE1f7C4VChNCjR4/MYdRY3srXqTEAjUZjMpls+XadO3eu
8b9RWxgmk+mdd95JTU2NiYk5ffr05cuXs7KyZs6cWdv06gG//fbb5iafOp1u+PDhVjqRQj4B
XAx2OUASnphPeMzzjsrKSjqdXv/lqFQqXC3P5/MHDBiwfPnyc+fOGY1Gk8m0dOlSqVSKEOJy
ucOHD79x4wZBEFeuXAkODi4tLd25c2f79u3Ly8sJgrh27RqfzycIYtKkSQkJCRs3buTz+RQK
pU+fPg8fPiQIYuXKlZ06dSIIYsOGDVQq9c6dOzUGo9frqVTqe++9Z55ivXx1NQYwYcIEKpWq
1WrNxWr7drX9N2oLw2g0hoSEsNnsiRMnLlq0aPbs2f7+/lFRUbVNrx5wdnY2rgIxs/Lg4/Tp
00OHDrXxXwFA/alUKoFA4O4oACASEhL27t3r7ijs4zH5BEEQNBrNYDDUfzlGo/HYsWPvvPNO
REQEQohGo6WlpdVtURMnTpw6daqVAhqNpkmTJlKp9MCBA+np6enp6SdPnly4cGGXLl1at26d
mZn5888/p6en217elgAuXrw4YsQIG79Cjf8NK2EEBQUNHDgwODiYQqFIJJLevXvfunWLIIji
4uKZM2dWn15dVFRUlaS2tpQiKSmpf//+Nn4RAOqvvLycyWS6OwoAiClTpvz000/ujsI+npRP
cDgcy3tuh8jPz7fSe+K1pkyZ8toOCM+fP+/evbvl5ZPFYnXt2nXVqlW48WN9ytsSgO0s/xv2
hm27H374gc/nV08pqvf4SE5Ofm13WQAcyGQyUSiUGlsTA+BK//nPfywHJvAIHjOeFfq3CYVj
h5/CQzLUmY+Pj0wms14mMjLy2rVrqampWVlZVCq1adOm0dHRVppY2lXelgBsZ/nfsDds2yUk
JCxcuLDKRNyW4tSpU/Hx8eaJ8DAbuBiFQmEwGJWVlfD+HeBenth+wvPyCXdH8f8TFBR08eJF
W0rGxsaauzY4sLztAdSNvWHbQiQSjRgx4ujRo1WOluopBeQTwPXweQbyCeBekE84F5vNJls+
ERcX98knn/zvf//r0KGDy1ZaUlLy9OlTmUymVCrz8vIePHgwefLkKo0ca8TlcvHwDzweD58u
BQIBnU5HCAmFQhqNhhASi8V0Ol0oFLJYLC6Xi0uKRCLL3qf1N3fu3DNnzmg0mirTq6QUkE8A
14O9DpAB5BPORcL6iS5dunTo0OHFixeuySd27ty5YcOGJ0+eVJl+6NAh/BiIwWBUb5qAECII
QqFQIISMRqNKparDqqlUqkgkwj1dcV4iFArpdLpYLMYr5XA4bDZbLBZzuVwulysSifh8PpfL
5fP5IpEITxSLxXhpcXFxvr6+1fMJ9G9KcebMmd69e8OZHbgeCc8zwAtBPuFcVCr17t27RqPR
fN2qw4uyHB5Samqqa9b1/PnzGTNmdO3a9dtvv23VqpVUKhWLxWKxWCQS4aoFuxgMBvzuroqK
Cq1WixDS6/U6nc5kMimVSjxRp9Pp9XqVSmUwGBQKRWVlpUajKSsrKy8vV6vVBoNBLpcXFRWp
1ery8vKysjKNRlNZWWl9vTgdEQgEBoOhtgNGp9MNGjRoxYoVXbp0ee0CAXAsyGIBGUA+4Vwq
lertt9+2nEKhUHBiYc4wavvA4XA4HE6NH9z1dewllUppNNqAAQPwa7rqiU6nW3/paN3gnEOp
VOp0Op1Op1AocF6iVqtVKhWeWFpain/+8ccftS1Hr9cvXbp03rx5kE8AF4P6CUAGkE84V1BQ
0H//+9/w8HClUllWVqbT6ap/UCgU+fn5eEp5eTm+87aOzWZzOBxc28Hn8xkMBm5MIJFIcCU/
nU4XCAS4qr+2wjizwQs0tzYwt06wV0VFhVqtViqVSqVSrVbn5OSkp6dfvXrVaDQ64+3qDsRg
MCQSiS2ZyqNHj65evYrrSKrgcrlxcXHz58/39/c/ePCgE8IEoFZMJhPyCeB2dDrdYDC4Owr7
eFI+gd/+YNmf0BbmxMLKB1yxj6vrVSqV0WhUKBQlJSVKpRI/FzA/FKgb86MZ3MjRMrYqA2Mj
hLRabfXqVhqN1rZt2zVr1phfFurpjh07VmPdA4vF6tu374kTJygUSklJCdRPABdjsVjwvAO4
HdRPOFfd6iFFIhF+o3f94VYC1ZMPc7sB3LYAWTRKsGz/WFpa+tpV4LoQsVgs+JdIJAoJCQkP
D3d7YxEH0uv1GzZsqPLSEEwoFO7du5dCoSCE8EgALo8OeDV43gHIP99WcwAAIABJREFUAPIJ
53L7cc5ms9lstjOaHXibPXv21HgLyOVyjx8/bn5yBPkEcD1ojwnIgEajeVxe6zHvF0UkyCeA
Q1RWVq5YsaJ6Z1Eej7d69eq4uDjzFE98ggg8HZxnABl4Yv0E5BPA1Q4fPlz9SQeXyx01atRH
H31kORHnEwRBuDA64O2gfgKQAeQTzgX5RMOwcuXKKt06OBxO165df/755yolKRSKJx5UwKPB
eQaQgSee+jwsn6ixBR/wIJcuXSooKLCcwmKxWrRocerUqRr71kITCuBi0F8UkAHkE84F9w0N
wMqVKy173rJYrOjo6CtXrnA4nBrLQz4BXAz6iwIy8MTWY5BPANfJzs5OSUkxt4dgs9lt27a9
fv26UCisbRbIJ4CLwXkGkAHUTzgXHOeebv/+/XhgCYQQm81u3759cnJyjS8wM4N8ArgYtMcE
ZAD5hHOR8H3lwC47duwoKytDCPF4vO7du1++fPm1w4dDPgFcDO5bABlAPuFcnvg8CZhlZGQU
FxcjhHg83rhx486dO8dms187F51Oh3wCuBK0xwRkAPmEc8Gtqkc7e/aswWDgcrnz58//+eef
bXzHOoPBgCQSuBK0xwRk4In5hCeNtw35hEc7dOiQwWD44Ycf3n//fdvngo0OXIzJZNb42lsA
XAnyCeeCqm/PVV5e/uzZs/Pnz/fr18+uGSGfAC4GuxwgAxqN5nFVs56UT0DVt+d6/vx5UlJS
u3bt7J0RTu7AxWCXA2RAp9OhfsKJ4Dj3XK1bt67bjLDRneSTTz5p1qyZXc+evATscoAMPPF5
B7THBKQGG91Jjh079scff7g7CjKCXQ6QAeQTzgXHuReCje4MFRUVWVlZ8I+tEexygAwgn3Au
aI/phbx20JGxY8eOHj3aSQt//Pix0WjUaDROWr5Hg3wCkAHkE84F7TG9kDef3I8fP/7bb785
Y8l5eXkIIR8fH2cs3NN58y4HyMMT8wlojwlIzUs2ulqtPnv2bEpKStu2bRMSEhBCR44c+fXX
X628Ka0+8CteAwICnLFwT+cluxwgOegv6lxwnHuhBr/RMzMzN2zYsHfvXjyGUnh4OM4nqFQq
/uAM5eXlCKE+ffq8tmRaWtrx48f5fP7777//2petNAwNfpcDHsET+4t62PMOOM69TYPf6B9+
+OGWLVuio6Pv3LlTUVHx4sULPJ0giPv375uL3bx5c+nSpUlJSeYpaWlpR44cQQitX7+eRqMl
JiZaX9G2bdsYDAaPx9uzZw/OJ4YMGYL/9PvvvwcFBVEoFCqV2q1btz///BNPP3PmTMeOHZcv
Xz5v3ryhQ4c67kuTWoPf5YBH8MTnHZ6UT3ht0zxv1uBP7u+99x6DwcjMzHz8+LHlO01ycnI6
deqEL/zz58/v1q3b119/PXDgwJycHPyO1qtXr3766acpKSlLliwxmUyLFy+2spY9e/Z88MEH
kZGRgwcPfvbs2ZUrVxBCLBYLIbR8+fKxY8fK5fLVq1fv3btXKBT27dv3wIEDqamp48aNa9eu
3fXr19etW5ecnJyVleXUfwVJNPhdDngET8wn4HkHILUGv9HHjRvXpEmT+fPnv/vuu99+++2K
FStGjx5NoVAEAkFlZWVeXt7Jkyc3bNgwb968r776Si6XK5XKZs2anTx50mAwFBcXDx06tF+/
fm+++ebUqVNzcnLCwsJqXMvmzZuHDBly7NgxJpN57969jh07IoSSk5P79+9fUlJCp9P//PPP
Ll26IIQmTZq0atWqOXPmDBgwgMfjnT171tfXt3PnzjqdLjAw0KX/Gjdp8Lsc8AiemE94Uv0E
HOdeyBs6CcfGxiYnJ9+9ezcsLGzs2LHx8fFKpVIsFtPp9OvXrx87diw4OHj9+vUcDickJGT3
7t16vd7f37+0tLS0tJTP5x89enT8+PE0Gq2oqKi2VeTk5EyZMoXJZObn548dO7Z3794jRow4
fvw4QojFYjVq1AgnE5hOpzMYDBkZGZ06dfL19UUI0en0zz77zJb3yzcAcJ4BZAD5hHPBce6F
GnwnYZPJ9M4776SmpsbExJw+ffry5ctZWVkzZ86kUCj+/v6FhYUDBgzIy8sbNWrUV199NXDg
wA0bNsTHx7dv3z4/Px8htH37di6Xy+Vyw8LCHj16VNtafHx8vvnmm/nz53fo0IFCofz666/T
p08/ePCgWq3u3r17Zmbm0qVLL1y4cPDgwUGDBq1du3bnzp2dO3dOSkravHkzfubiPeA8A8jA
E/MJeN4BSM0bNvq1a9eOHz8+duzY0NBQjUaj1Wrv3r2LEOrZs2d4ePjo0aOzs7N///33pKSk
0NBQhNCkSZMQQjweb8CAAf3798cL6dWr1/Xr12vrEvLVV19NnTr1/v37I0aM2Lp1a0BAwLBh
w0aOHJmTkzNmzJilS5fu2rXr66+/5nK5ffv2vXbtWlxc3JAhQ9LS0j788MMlS5bExcV17ty5
W7du/fv3p1I96SakDryhSgyQnyfmExSCINwdg61evXrVtWvXnJwcdwcCXGfp0qUCgWDJkiXu
DsSJSkpKli1bdvLkyfz8fLFY3K5duzVr1nTu3Ll6yadPn0ZHRz9//jwyMrKiokIul5vbNGRm
Zt69e3fs2LEODMxkMp08efLw4cN///13ZmYmjUa7f/9+q1atHLgKEnr69OmIESOePn3q7kCA
V3v69OnIkSOfPHni7kDsAPUTgNS8YaP7+vpu27Zt27Ztry35/Pnz0NDQyMhIhBCTybRsIBkR
EREREeHYwKhU6qhRo0aNGoUQKigoMBgMuIKkYfOGXQ6QnyfWT0A+AUiNwWDo9Xp3R0EWOTk5
LVu2dMuqvaRzB/KCJjvAI3hiPuFJj0Ihn/BCsNERQps2bbp37x5C6MmTJ1FRUe4Op4GDXQ6Q
AeQTzgXtpLyQJx5UjpWfn//RRx+NHDkyPT39r7/+aty4sbsjauAgnwBk4ImnPk/KJ6Ae0gt5
4kHlWEFBQStXrszLy4uKirpz507Xrl3dHVEDB/kEIANPPPV5Uj6B34/iQR1SQP154kHlcCtW
rLhw4UJYWNg777wTFxfn7nAaOMgnABl44qnPk9pjon9f4cFgMNwdCHAReGkL1rt374yMDNjz
XQDyCUAGnnjq86T6CQSHuvfxxCTdSRpwMrFx48ZvvvnG3VH8H6gHBWTgiac+yCcAqbn9oLpz
586YMWMuX77sxhhs9Mknn/z444/ujqIusrOzFy9efOLECXcH8n888dYQNDBuP/XVgYflE3Cc
exv3HlT379/v169fdHR0z5493RWD7Y4dO/bHH3+4O4q6WLduXXx8/NKlSx1VK1DPUXThvgW4
HeQTTgfHubdxbwY5d+7c2NjY1atX0+lkb2lUUVGRlZXloUcHlUpds2bNo0ePTp065ZAFHj9+
vD5VSkwms6KiwiGRAFA3kE84HeQT3saNB9X9+/evXr36/fffu2BdY8eOHT16dH2W8PjxY6PR
qNFoHBWSi3Xq1KlXr16Oel7z1ltvjRkzJjk5uW6ze+KpHDQwnrgTQj4BSM2NB9WhQ4c6duzY
tm1b16zu+PHjv/32W51nz8vLQwj5+Pg4LiJXmzt37h9//JGbm1v/RQUEBHTr1m3AgAF1q6WA
56rA7ahUKkEQntUuGPIJQGpuzCeSkpI6duzomnUdOXJk7969QqGwzkvQarUIoYCAAMcF5Sxq
tfrQoUOffPLJvn37LKePGjUqJCTk4MGDDlnL3LlzDQbD8OHD61BLQaPRIJ8AbudxVRRkfypc
Bdw3eBs3bnGlUll91SUlJevWrXv16lVMTMy0adMkEgme/vfff1+6dCkwMHDixIksFsvedVGp
1ISEhPqsory8HCHUp08fe1f9WrXFUweZmZkbNmzYu3evWq1GCIWHh5u/NUKISqUOGDDg/Pnz
CxYsqH/Y/fv39/Pzk8lkQ4cOPXXqVHx8vO3z4i6j9Y8BgPrA+QT5G2/9P4RHiYmJuXv3rruj
AK5z8uTJ4cOHu2XVXbt2bdOmjeWUyspKy+Guw8LCbt++TRDE/PnzEUK+vr4IoV69epnLl5WV
nTp16osvvlizZs3PP/+sUCgOHjwoFovz8vLMZbZs2fLixQuTyXTv3j17V7F161Y6nc7lcnfv
3r1z506EkFqttv6lrl271qFDB5FItHjx4levXuGJ5eXls2bNwqet1q1by+Vy61/ZSnmz3Nzc
oqIigiCys7N37tyJJw4ZMgQh1KlTpzt37lRUVFSf6/vvv4+MjLT+FWy3YsUKLpeLEOJyuZcu
XbJ9xoiIiIyMDEeFAUDdcLlcrVbr7ijs4GH5RKdOnfDpFXiJM2fODBkyxC2r3rhxI0Lo7Nmz
5im498H69euNRqNcLp83b15sbOymTZvodPovv/xCEMT27dsRQjk5OQRBbN26lUKhWObu8+fP
nzNnDp/P12g05mX6+/uvX7/+5cuXDAYD5x82rmL37t0IoaioqLFjxy5evHjChAkIoRov0mZy
uVwkEiGEYmJiYmNjAwICMjIyKisrhw0bFh0dnZiY+OzZs4EDB8bExJhMptq+crt27ayUv3jx
4vLly7VarUgk6tOnT2VlJX5m9OeffxIEceTIEQaD4evru3fvXjxmVBXbtm0LCAio54Yze/Xq
lbkix66UolmzZunp6Y4KA4C6EQgEKpXK3VHYwcPyibi4uBs3brg7CuA6586dGzhwoFtWrVKp
mjVrFhERUVpaiqcsWbIkMDDQ8kIol8sFAgGfzx83btzs2bMDAgJCQ0MrKio+/vhjhFBERMQX
X3xx9erVgQMHIoQ+//zz8ePHd+vWzTz7sWPHEEIPHjyQy+UIoYyMDNtX0b59+yFDhuj1eoIg
7t69S6PREEJJSUlWvtFPP/2EEPLz8yspKdFqtR06dOjbt+/mzZtFIlF2djZBEJWVlcHBwQih
EydO1PaVrZfft29fTEzMihUrEELt2rWbN28ei8Xi8XgrV67EBVJSUnr16oUQatu2bWJiojkR
webPn9+jRw97t5QV8fHx5qzO9pSiRYsWjx49cmAYANSBWCw2n3w8goe1x4RXlnsbN7afEAgE
Bw4cyMvLGzx4MH7eL5fLeTwelfr/jpqDBw8ymcwjR45kZmbu3LmzUaNG586dYzAYly9f7tq1
a3p6+vLlyzMyMi5cuMDj8ebNm8dms3Nzc/GzeY1Gs2zZsvHjx7dp00YsFtPp9OvXr9u+ipyc
nClTpjCZzPz8/LFjx/bu3XvEiBHHjx+38o0yMzMRQhERET4+Plwud8qUKSkpKVevXh03blxY
WBhCaNmyZXK5PDIyctGiRXgAhurxWC+PEHrw4MGXX37ZokWLx48fb9q0af/+/UOHDjUPMBUb
G5ucnHz37t2wsLCxY8fGx8crlUr8p8ePH//000+TJk2q/7Yz++9//ysQCPBnnU43fPhwW3p8
QDstQAYe1x7Tw/IJeGW5t3HvEdWxY8edO3feunWre/fuz54902g0JpPJskBaWlrLli0HDRqU
mpqq1+tv377dqlUrhFBUVNTTp0+///77qVOnTp06VSAQtG7dWiAQvPvuu1lZWZMmTdqxY0fX
rl0NBgN+fkGhUPz/P/bOPKypo/37kwSSkIQsQNgEVBDBDZG4YVFQKiJWW3FBRStV22p9Wmtd
sD62LrU+VayKKy0uVWpBkYqodV/RoixaN1RUZJOdhJAFkpCc9495e678IMGwJTkynz9ynQyz
3HPImfmemXtm+PyKigrDi7Cxsdm8efOyZcv8/PxIJNLRo0c//fTTxMREKH10UlpayuVyMzMz
V61adf369aSkJD6f7+HhcezYsaVLl44cOXLLli379+9PTU0tLCz84IMPJBJJc3tajg8A0Gg0
06dPnz59ulKpXLJkydSpUz08PF68eAH/NHPmzJycHF9f3zNnzly9erWgoGDhwoUymWzWrFk+
Pj62trZz587tsP8fAGFhYdrnnhgoKQjXjiPeSYina009QNI6QkNDz507Z2orEMbj5s2bHTsA
3gbi4uJIJJK7u/uMGTPIZLK2h9S2bdvIZHJWVlaTJC9evOjXrx+FQhk2bFh6evqCBQuCg4Px
3KysrLhc7oIFC6DHIiQiIuL48eOzZs0ysIjk5GRra2sLC4vw8PDy8nIYGBUV9eTJE30VmT17
9pw5c2JjY1ksFolEGj169KNHj4RCYWBgIIlE6tmzJz5dcvr0aQaDMXv27Ob2tBz/2rVrzs7O
IpEoPj5+0KBBDQ0NGIalp6ezWCwMw9Rqdbdu3eh0emRkZHR09OLFi/l8vpeXV25uLpVKnT17
dkFBgSH/kVaxcuVKKpWq3egxGIxr1661kGTw4MHNbzgCYWScnZ3fvHljaitaAcH0xMSJE9PS
0kxtBcJ43L59e8SIEaa2AktLS7O3tz979uykSZO0w6VSac+ePe3t7f/444+8vLy8vLy0tLSV
K1cOHz68f//++fn5MNqGDRt8fHwMKejy5cttK8IQIiMj582bZ3h8nfa0k+rq6oULFzo7O5NI
JB6PFxQUdOfOnQ7MvzlPnz6FqzyaSIoWfCmGDRvW2VYhEG/F1dUVOioRBYLpifDw8JSUFFNb
gTAed+/eHTp0qKmtaImXL18GBARo91U0Gs3f3/+HH36or6+Hce7cuQMAuHnzZucVYQhRUVHz
589vmw2Epnv37s2HZluQFO+9996tW7eMbCQC0YQePXq8fv3a1Fa0AuJslAEAQP6YXQ/zn8n2
8PBIT0/PyckpKCggk8m9evXy9vbWnrMHAAwbNmzatGnQdaANW1gaUoQh2NjYVFVVtTYVEVEq
lXDDUACASqWaMmXK3r174ZZfONCXQudWV8Sbt0a8i5h/69cEgukJ5I/Z1SDKEyUQCAQCQQsR
EhIS4uPj5XJ55xXxVpycnC5fvtyeHMyH6urq0tLSoqKiN2/evHnzpqioqKqqqqampqqqqrq6
uq6uzpBMoKQ4e/ZsUFCQdjhRfnWIdxvC/Q6JpyfQ+ESXgnBPlD5oNNp//vMf09owYsSIFStW
3Lt3z8/Pz7SWGEh5eTkuF0pLS0tKSoqLi9+8eVNcXKw92GBhYeHo6Ojs7Gxra+vp6WlnZ2dr
a2ttbW1lZYXHWblyJb4wVRu5XB4aGpqamhoaGqqdIXpvQZgcwrV+SE8gzJqqqiqpVPr8+XMG
g8FisbhcbpNNJxGGM3z4cD8/v9evX5uPnpDJZBUVFRUVFeXl5cXFxSUlJVA9QBmB72kBAKBS
qc7Ozi4uLoMHD/7www9dXFxcXV2dnZ3d3NwcHBzgdl4t8Pz58127dulsPRQKRVhY2NixY1ev
Xg332iJcO454JyGcrkV6AmHWnDx58vXr197e3niIlZUVg8HgcDjW1tYMBoPJZHK5XCaTyWAw
2Gy2tbU1vObxeAwGAway2Wx43Z6zrN4ByGRyTk6OccpSqVS1tbUikUgkEtXW1lZXV1dXV1dW
VpaXl1dVVVVVVZWXl1dWVjaZAKLT6VAlBAQEdOvWrVu3bm5ubvDCwcGhPVLy888/3717t76/
kkika9eu+fv7Qz1BuHYc8U5COF1LMD2BnvOuxkcffZSSkrJ9+3axWCyVSuVyuVQqra2tlcvl
crkcBlZUVMhkMhjYxOeuOVBtWFtbs9lsJpNpZWXF4XDIZLL2J5vNplAo8BPu8QA/WSyWpaWl
9ieTyWyyt8E7RmNjo0QikclkDQ0NYrFYLpcrFAqRSNTQ0FBfX19bWws/cd2Af0ql0ua5UalU
Pp9vb2/v6OjYu3dvPp/v6OjI5/P5fD4UDXZ2dp1UkSdPnlhZWWkPeOAwmcwhQ4b89ttveOmo
nUGYA0hPdC5UKlVni4B4V/Hw8KBSqREREQbGV6vVdXV1EolELpdDkSGTyeRyOQyE1yKRCMqR
urq6uro62AViGAY/xWJxkx0h3wpUFQwGg0ajwU8AAJQmMAIUH/AajwAAoNPp+Bw/lUplMpnw
GiqYVtnQhLq6Ou2WCFbNwAuxWKxQKKRSqUQiMaRb5XA4XC6Xx+PxeDxPT0/8msfjaV87ODhw
udz2VKo9HDt2TKeTJpPJnDx58uHDh7X3FCdcO454JyHc75BgeoJw9xfRTiwsLFr1H6dQKLD3
ame5UFXAXln7E3ax8FMqlapUKvgpk8ngGkWlUglf4mE+MJVIJAIAwJgwXDuOQqFoz7oPA4Fa
R+cFlDJcLhfXNDweD2odLpcLD/Ris9l0Op3FYrFYLDqdDkd3aDSaCSWC4Wg0mvPnz0O1pA2T
yYyMjIT7n2qHo/EJhDlAuP6OYHqCTCa39t0RQWhM9UTBc72N728BBQq8hiIGAAAnYtqWIS4a
ujK3bt1q3m4wGIyQkJDmYgIQsB1HvJMQ7neI9ATCrCHcE9VOLC0ttUVM5/kTdCn279+Pb28F
oVKpffr0SUxM1OnjicYnEOYA4Vo/gp0vivREV4NCoaCWHdEe5HL5n3/+qd1uUCgUJyenS5cu
4Y4sTUB6AmEOEO53iPQEwqxprf8EAtGE/fv3aw9CkEgkDodz48aNFiazCPdeiHgnIdzvkGB6
gkQiNXeqQrzDEO6JQpgVDQ0NP/zwg/biVQaDcfHiRZ0nhOEQ7r0Q8U5CuNaPYHoCjU90NQj3
RCHMil27dtXX1+NfGQzG8ePH33oMCpplQ5gDhGv9kJ5AmDXoTRHRZmQy2caNG3FPTAaD8b//
/S8sLOytCdEsG8IcIJyeQOs7EGYN4Z4ohPkQGxuLi1Emk7lw4cKvvvrKkIRIxSLMAcK1fmh8
AmHWkMlkDMOQ0wyiDezZswduFGZlZTV27NiYmBgDE6J2BmEOID3RuaDnvAtCuIcKYQ7cu3cP
7gZGp9P79++flJRk+HFiqJ1BmAOE8+NBegJh7iA9gWgD586dUyqVdDq9b9++ly9f1rfVhE7Q
OjKEOUA4Px6kJxDmDtITiDaQmpqq0WgGDx6cnp7OZrNblRa1MwhzgHBNH9ITCHOHcA8VwuQ0
NDQUFRWtXr362rVrbTi+BLUzCHOAcE0fWt+BMHeQsz2itajV6pcvX7b5zHcSiYTaGYTJQXqi
c0F6ogtCuIcKYXLgqetthkwmo58cwuQQrulD8x0Ic4dwDxWC6CB/TIQ5QLimj2B6gnD3F9F+
0D8dYWTQewvCHEDrRTsX9Jx3QZD/BMLIoHYGYQ6g9aKdC3rOuyBofAJhZFA7A5kyZcrkyZON
mRChDeGaPqQnEOYO4R4qBNFB/hM4qampSUlJxkyIwCFc04fWdyDMHcI9VAiig9oZSHJy8tGj
R/HdwCQSyV9//ZWdne3j4zNnzhw8WvPwJgkRbYNwTR/SEwhzB/lPIIzMO9PO3L1798qVK46O
jpGRkXDH8ZqampiYmJKSEl9f3/nz5/N4vBaSk8lkqA/y8/O3bdt25MgRiUQCAOjRo0fL4XjC
jkKf2c0r+C5BOD0BMEJx9OjRWbNmmdoKhFHx8fF58OCBqa1AdCG2b9/+9ddfm9oKQ0lPT/fz
8+NwOKtWrSopKcHDly1bBgCwtbUFAAQGBmIYplKp/P398cbf1dU1MzMTRn7z5k1lZSWGYUVF
RfHx8TBQo9H8888/GIaFhYUBAIYMGZKVlaVUKvEi9IXjCTEMS0lJcXR0BACQSKQRI0Zcv34d
w7BHjx4dP34cw7CtW7eSyeQTJ060UEF9ZjevIKS+vv706dMbNmz46aeffvvtt9ra2jbfW9Oy
fv3677//3tRWtAKC6YnExMQZM2aY2gqEURk0aNC9e/dMbQWiC7Fjx44lS5aY2gqDEAqFHA4H
AODr6ysQCBwcHF69eoVh2M6dOy0sLA4fPoxhWFxcHACguLj49OnTAICff/5ZrVYLhcKlS5cC
AL777juZTMbhcEaPHq1SqQYPHgwAuHHjBoZhhYWFlpaW9fX1ycnJlpaWtra2R44cUavVeOn6
wvGEa9asAQBQqdRNmzYlJCSEhoZSKJSjR4/u2bPH09MzKyvL0tISANCrV68W6tjcbIFAoLOC
GIbt3bu3yUGyy5Yt65x73+ls3Ljxv//9r6mtaAUE0xPHjh2bPn26qa1AGJXBgwdnZWWZ2gpE
F2Lnzp1ffvmlqa0wiEOHDgEA7OzsampqZDKZn59fcHCwUCi0trZmsVhTp05dvHixg4ODi4uL
Uqn89ttvHR0dtTv+hIQEX1/ftWvXAgAGDhy4dOlSGo3GZDLXrVuHYZhQKAQAQIGSnZ0dGBgI
APDx8UlJSdFoNDAHneF4wkWLFllYWGRkZOAlbtiwgcfjbdu2jcfj2dvbjx8//uDBgwCAoqIi
fXVsbra+Cn7zzTcAAHd39w0bNty8eXPcuHEAgPXr13f0XTcSP/30U3R0tKmtaAVofQfC3EH+
EwgjQ6B2Jj8/HwDg7u5uY2PDYDCioqKys7MTExOpVGpycnJ+fn58fLybm9v58+ctLS2FQiGT
ySST/0+z//Dhw40bN/bp0+fp06c7d+78/fffJ0yYUFxcDADgcrkWFha3bt0CAAgEguvXr9+/
f9/V1XXKlCljxowRi8X6wvGENBrNzc1t+PDheHFyubyxsbG6ulokErFYrBMnTkRERFAolMrK
Sn11bG62vgpevXrV398/Ly/vu+++e/Xq1aVLl5hMJhyGISIE+h1CkJ5AmDvEc0pCEBwCtTOl
paVcLjczM3PVqlXXr19PSkri8/mPHz/u27dvaGhoTk6OQqHIzMzs168fAEAqlTavl0ajmT59
+vTp05VK5ZIlS6ZOnerh4fHixQsAAIlE4vP5FRUVGo1m5syZOTk5vr6+Z86cuXr1akFBwcKF
C/WF4wkDAgLy8/NXr1596dKlxMTE0NDQLVu2xMfH19TUAADi4uIYDAaDwXB1dc3NzdVXx+Zm
66ugl5fX8+fPd+zYMW/evHnz5llbW/fv37/Nx8KZHAL9DiFITyDMHaQnEEaGQPtPKBSKiRMn
xsbG7tmzZ8yYMTQa7eTJk56enrdv387Ozm4SGcOwwsJCuVwV9VVyAAAgAElEQVSOh7i4uDg7
O+/du9fFxWXQoEGbNm0CAISFhd27dw9GGDVqVI8ePQAA6enpAQEBs2fPXrVqVUpKikwmu3//
fgvhMGF4ePjq1asPHDgQEhKyYMECKpWanp4eERHBZDJDQkLGjh0LSwkMDISjIDppbra+Cm7c
uNHJySk6Ojo3N/fmzZvTpk1jsVhtvLNmAPH6OxPPt7SSU6dOTZo0ydRWIIzK6NGjr169amor
EF2IX3755bPPPjO1FQYRGRk5b968JoFSqbRnz5729vZ//PFHXl5eXl5eWlraypUrYZufn5/f
hoKqq6sXLlzo7OxMIpF4PF5QUNCdO3daCG8ZhUJRVlaGf3316lULSzwuX77cpNnXV8Hhw4f3
798fr+CGDRt8fHzaUFkzITY29quvvjK1Fa0A7T+BMHeQ/wTCyBConbG0tGyynAEAwGQyL126
FBUVNWvWLDyQRqP5+/uHhYU5OTm1oSBbW9t9+/bt27fPwPCWoVKpcBEpxN3d3d3dXV/k4ODg
4OBg7RB9FfTz84uIiMArGBIS8v3336enp48cObJV5pkJBPodQpCeQJg7aL4DYWQI1M7Y2NhU
VVU1D/fw8EhPT8/JySkoKCCTyb169fL29oaLM98NDKngsGHDpk2bBj08HBwcTGVqmyFc04f0
BMLcIdxDhSA6BPKfcHJyunz5sr6/CgQCgUBgTHuMzFsrmJCQEB8fr+17QSAI198hf0yEuYP0
BMLIEKidGTFixMOHD3H3SUQTaDTaf/7zn549e5rakLZAoN8hBOkJhLmD/CcQRoZA7czw4cP9
/Pxev35takMQHQ/hXqXQfAfC3CHcQ4UgOgRqZ8hkck5OjqmtQHQKBPodQtD4BMLcQXoCYWQI
5D+BeIchXH+H9ATC3EF6AmFkUDuDaC2xsbGbN2/u2DwJ1/QhPYEwd5D/BMLIdEg7k5WVFR4e
fvXq1Q4xCWFaVqxY8euvv7YQoaioaNWqVadOnerAQgnX3xFPTxBLryHaD+FEOoLotL8df/Dg
wfvvv+/t7T1q1KiOsgphQk6ePHnu3LkWIsTExIwZM2b16tVNZsrgyWptA+mJzoVCoRDr/iLa
D9ITCCPTfv+Jr776SiAQbNq0ycLiLT7vFRUV7SmoPZiwaGKhVCoLCgpUKlULcchk8k8//ZSb
m3v69Gnt8NTU1DaPURGu6SOYniCcXkO0H8I9VAii08525sGDBzdv3tyxY4chkdetW9exg+SG
06lFT5kyZfLkyZ2UuZF5+vSpWq2WSqUtRxsyZEhgYGCTaZGIiIjw8PDr16+3oVzC9XdITyDM
HeQ/gTAy7Wxnjh07NnjwYB8fHwPjZ2RktKGUsrKyw4cPtzN+24o2kNTU1KSkpM7L32iUlpYC
AGxsbN4a86uvvjp37tybN2/wEHt7+4CAgJCQkDaMUhBufh/pCYS5g8YnEEamne3MxYsXBw8e
bGBkNpv98uXLNpRy9+7dBQsWGC61m8dvc9HNkUgkx44dW7FiRUJCAgxJTk4+cuQIm83ukPxN
i0wmAwBonwDSvL6Qjz76qFu3bomJidqBS5YsaWxsnDhxYmtHKQg3v4/2s0KYO0hPIIxMO9sZ
sVhsYDff2NgYFxfn5ubWtoIaGxtFIhGfz29bfCsrq9raWn2R7969e+XKFUdHx8jISBqNpi9a
fn7+tm3bjhw5IpFIAAA9evSYM2cOAIBMJsOLttG89JqampiYmJKSEl9f3/nz5/N4vA7JtuVw
SENDAwBg9OjRQH99IWQyOSQk5MKFC8uXL8cD33//fQcHh/Ly8gkTJpw+fXrMmDEGWku8/s60
x6W3locPHw4YMMDUViCMysqVKzdv3mxqKxBdiLNnz4aFhbU5ub+/f5Nmas+ePXZ2dmVlZU1i
RkVFAQB69+6NYdg///zTvXv3oUOHKpVKDMMaGhoWLVoE3Tn79+8vFAq1E0okki1btgAARo4c
6enpSSaTAQApKSn6TNIZf+DAge+9917zojEMW7ZsGQDA1tYWABAYGNhCZcPCwgAAQ4YMycrK
wpNjGKbRaP755x/8699///3tt99euHABD3n06NHx48cxDNu6dSuZTD5x4gT+p+alq1Qqf39/
vNtydXXNzMzUaU+rsm0hfO/evRYWFgwG48CBA/Hx8QAAiUTSQn1xduzY4eHh0STwhx9+YDAY
AAAGg3HlypUW7qc2586dCw0NNTCyOUAwPfH48eN+/fqZ2gqEUYmOjv7pp59MbQWiC9HOdjw2
NhYA8Ndff+Ehc+fOBQA8ePBAO1piYiKFQpk8ebJAICgrK3NxcYGd5b59+1Qq1QcffODt7Z2S
kvLixYtx48b5+vpqNBqYuZOTExQEAAAHB4cZM2bs2rUrIyNDZ/fWQvyYmJjmRWMYtnPnTgsL
i8OHD2MYFhcXBwAoLi7WV9nk5GRLS0tbW9sjR46o1Wo8vLCw0NLSsr6+HsOwb775hkQiwSKK
iorkcjmGYXv27PH09MzKyoKHjPfq1Qsm1Fk6XDTx888/q9VqoVC4dOlSgUCg055WZasv/MCB
AwAALy+vKVOmrFq1atasWQAAeHv11Rdn3759Dg4OTQLLysrwYQ/DJcWFCxdCQkIMiWkmEExP
5Obm9unTx9RWIIzKqlWr/ve//5naCkQXop3teF1dnaenp7u7u0gkgiFLlizp1q0bhmGzZs36
4IMPMAzLzMxkMBi7d+/evXu3h4fH0KFDe/fu/eTJE19f3+Dg4N27d3M4nKKiIgzDVCqVs7Mz
AODUqVMYhkVFRVlZWYWHh8+fPx8AoO81HaeF+DqLFgqF1tbWLBZr6tSpixcvdnBwcHFx0alU
cLKzswMDAwEAPj4+KSkpUPcIhUIAwKtXr7Zv3w4AWLp0qVwuLykpefLkCY1Gu3DhQmxsLI/H
s7e3Hz9+/MGDB6HU0Ff6t99+6+joqLP/bkKrstUXPmjQoLCwMIVCgWHY/fv3KRQKAODixYst
1Bdn2bJlI0eObG5YSEgILqoMlBSXLl16//333xrNfCCYnnj27JmXl5eprUAYlW+//fbHH380
tRWILkT72/GsrCw6nT58+PC6ujoMw5YsWTJq1Kj09HTYnZw7d87Z2TkqKgrDMLhJM5PJzM/P
xzBs/fr1dnZ206ZNmz9/PswqOjqaTqd7eHh4e3srFAqFQiGVSjEMg7tH3L17t2VLWoivs+jd
u3fb2tqeO3fOz8+PSqUOGTLk8ePHhlT5/v37EyZMAAAEBQXV1tZqNBr43j9q1ChnZ2e80/3m
m28AAPfu3Vu3bh0AwN3dXSaTyWQyCoWSnZ29Z88enaV//vnnzScRdNKqbPWF29nZwUmT0tJS
d3f34ODgSZMmffHFFy3UFwbm5uba2Nj88ssvzQ3766+/tL1TDZEUV69eHT16tCG1NhMIpify
8vI8PT1NbQXCqPz3v//duHGjqa1AdCEuX74cHBzczkyg57+Pj09eXt6aNWs8PDzc3Nz69+8P
u5NRo0bBYf+vv/4ajuTDVI8ePQIAhIeHs1isr7/+OiAggEQi/f77748ePbKysho7diwUKBiG
1dfXAwAOHTpkoD3N4+ssesyYMTpfr/WhVqtnzJiRnZ0Nv169erVHjx4zZszAMMzJyWnLli0b
N24EAEyaNGnjxo0hISGwCAzDPv/8c+2X/h49ehw5cmTRokU6S4+MjOzZs6ch9rQqW33hvXv3
FggE33zzjaOjo4eHR3l5+enTp3k8Xl1dnb76SqXSmTNnWlhYeHp6NjQ06LxRTVacMhiMa9eu
tVCX69evt+y8Ym4QbL0ohmH4kBGii4AOe0QYmQ7xq589e3ZcXNyjR49CQ0MjIiLKy8tHjx59
//796OjoJUuWnD171srKCgDg5eXl6+u7ePFimKp///6TJk366KOPBAJBbGzsmzdvLly4EBkZ
2b9//+PHj9++ffuLL77AjSSTyTdv3jS8Uk3i6ywaAHD79u3s7GzDa5qenh4QEDB79uxVq1al
pKTIZLL79+8DAEaNGtWjR4/o6OjPPvvs77//3rhxY35+PrwzAAAmkxkSEjJ27FiYSWBg4K1b
tzw9PXWWjmFYYWGhXC5/qzGtylZf+I8//piXl7dz584RI0bcvn3bwcHhgw8++PDDD+Hm2Trr
W1RUlJKSMmPGjEuXLulcDkMmk6dPnw6nTiByuXzChAkt7EuB1nd0Ls+fP4e+0Iiuw/fff79+
/XpTW4HoQnTge2FaWpq9vb3OF9b289tvv+Xl5XVsfKlU2rNnT3t7+z/++CMvLy8vLy8tLW3l
ypXDhw/v378/nBlpQnV19cKFC52dnUkkEo/HCwoKunPnjs7Mnz17BgB4+fIlhmEKhUJ7wcur
V69OnDihr3TYW+ksvQmtynbAgAEwZ8Mr26r6NuHatWscDqdJF9zCKMXt27dHjBhhSM5mAtIT
CHNn7dq169atM7UViC7EzZs3WzXm/47x8uXLgIAA7T6PRqP5+/v/8MMPcL1Gmzlz5oyLi4tJ
SteXbVRUVJPNxzqqss1RqVR0Or35W70+X4qMjIzhw4d3rA2dCsH2s0J0QdB8B8LIdPGfnIeH
R3p6ek5OTkFBAZlM7tWrl7e3N1x+2U6Ki4v79u3b4aWLRKK3Fm1jY5OUlJSTk1NSUkKhUPr3
7+/p6clkMplMJgCgMyrbHAsLi8DAQOjboR0ul8snTpx49uzZoKAg7XDCzXcQTE9gyH+i60Ei
kYj1UCGIDuHa8c5AIBAIBIIOyWrnzp2jRo3y9fWFC/RUKpVUKhWLxXAJRl1dXV1dHbwWi8US
iUQul8tkMpFIpNFoxGIxAEAqlapUKpgQACAWizUajUKhMMSjwhCsrKzgyIG1tTXcQwzuv2lh
YWFtbQ0AYDKZLBaLxWJxuVy4xJTFYrHZbA6Hw/oXHo/HZDKpVGoLBX3zzTd///033FtTG+hL
0WT3TMJtDUwwPYHogpDJ5JZPCkYgOhakJ1qLUqmsrq6uqakRiUS1tbUikQi/KC0tPXHiBI1G
c3NzKywsxDBs165dLecGO2bYhQMAYJ9Np9OtrKxIJBKXywUAMBgMGo1GoVDwRZi4JjAQiUQC
t0WHwxtqtbqurg4AgMsUmUymVCoBAGKxWCgU1tbWSiQSqVQKV8rog0ql4rKDw+HY2tra29vb
/YuNjQ2dTm+uJ8C/oxTakoJwv0OkJxDmThcffEYYk8rKSolEolaridWOdx4NDQ01/1L9LzVa
VFZW1tTU6OwgAQBcLpfH4zk5OZWXl7948QIAMGvWrH79+kG5wOFwrK2t4TWXy2WxWPgEhDkD
lYdYLJb+i0gkwq/FYnFdXR28FgqFeXl5GRkZ1dXVhhzpIpfLx48f/+23386aNat3795ofAKB
6GAIJ9IRxGXv3r3r168nk8kUCuW9995z+5fu3bt3797dzc2tuX8+QZHL5VAQVFVVNZEIMBBe
wPmFJrDZbD6fD1+4vby8bP/Fzs6OpwWXy8Wnp69fv/7xxx8HBAQcPXrUuBXteCgUCqxgq1KJ
RCJ4q58/f/7ZZ5/pkxdKpXL9+vUAgHXr1hGu6UN6AmHuoPEJhNGYPn16z549//777z///JPB
YNy7dy81NRUeLwnhcDhQYWh3onZ2drZatHAaZ6cil8vhyzH8FIlE8KK2traJSqipqdE5aG9j
YwPr4uzsPGDAAFg7Pp9v+39pg7tiUFDQq1evOsnPkRBACdK7d2+pVMpisXSe7EomkxkMxr59
+4KDgwEBX6UIpieQP2YXBOkJhNHo27dv3759fXx8srKyLl26BAPLy8uL/qWwsLCwsLC0tPTx
48f6Xt9ZLBbsd62trS0tLVkslqWlJXT00/5ks9nauxs1R6lUymQyAEBDQ0N9fb1cLoebZ6tU
KrhRI9zWura2FuoGfW5GJBIJVzzdu3f38/OztbWFAwxNhELL9rSTriwmtLl48aLO6SFLS0s7
O7sbN254enrCEDTfgUB0MIQT6Qii0+Qn5+jo6OjoOHTo0OYxFQqFzmkCiEKhkEgkIpEIdv/a
n601CXojQidEKFDYbDaXy+VyuTQajcPh4F/hogP4iYe363YgOpQ//vij+Q+ARqO5uLjcvHkT
nv0GIVzTh/QEwtxB4xMII2P4T45Gozk7O2v3AQaCawsSiQRXJOqDSqWav4siwkDu3LnTfEyL
wWD4+fmdO3cOrmfBQXoCgehgkJ5AGBkjtONwlWNrffoQRGf79u1N9sxgMpmhoaGJiYnN54MI
N9+BzgNDmDuEE+kIooN+cojOoKKiIi0tTVsiMJnMDz/88Pjx4zqdSwj3OySYnkB0QdD4BMLI
EK4dRxCCrVu3an9lMplTpkxJSEggk3V3xIT7HSI9gTB3CPdQIYgOkrCIDkcmk8XFxeFrj5lM
5pw5c3777Td9YgKg+Q4EosNBjTvCyCAJi+hwDhw4gLdjDAZj/Pjxe/fubXn6nnC/Q6QnEOYO
0hMII4P8tBAdi1qt3rRpE9xNhEqlDhw48OjRo2/9jaHxic4FPeddEMKJdAQCgdDmxIkT+LIO
BoNx6tSplo8hhRCu6SOYnkB0QdD4BAKBIDTff/893BOTxWLt27ePz+cbkgrpCQSigyHcQ4VA
IBA4t27dKisrAwDQ6fQhQ4ZEREQYmJBw8x1oPyuEuYPGJxAIBHHZv3+/TCZjMBgDBgw4deqU
4VP2hHuVItj4BPKf6IIgPYEwMqidQXQg165dI5PJ06ZNu3HjRst7qzeBcHoCjU8gzB3CPVQI
BAKBg2HYkSNHZs6c2dqEaL4Dgehg0PgEAoEgLleuXMGPIG8VhHuVIth8B6ILgvQEAoEgLm0T
EwDpCQSiwyHcQ4VAIBDth0wmYxhGoLcpgukJ5CfVBUHjEwgEQieLFy/ev3+/qa3oRIj1NkUw
PYHoghDriUK8A7TqvaW0tLS0tLRT7ek8pkyZMnnyZGMm7NhSMAy7detWk0CNRvPgwYPHjx93
pmlGglitH9ITCHMHjU8gzJakpCSBQMDj8UxtSNtJTU1NSkoyZkJ9lJWVHT58uFWl2NvbFxQU
4F+VSuXevXt79eo1bNiw6OjoxsZGwwsyT4i1xAPpCYS5g/QEwgyRy+Xh4eGRkZG9evWysrIy
tTltJDk5+ciRI2w2G36VSCTHjh1bsWJFQkKCdrTm4U0Sdgh3795dsGCBtggwpBSxWAwvcnJy
/Pz8li9fPmnSpJcvX549e9bCQvcCxuYFmS3EGp8g2HpR5D/RBSHWE4XoCkgkkjFjxuTm5tJo
tBkzZpjQkrt37165csXR0TEyMpJGowEAampqYmJiSkpKfH1958+f3/LYCZlMnjNnDgAgPz9/
27ZtR44cgcdM9OjRo+VwPGHH0tjYKBKJ8OMtmpTy+PHj1NRUFov12WefMRgMGKjRaKRS6YYN
G7Zv3+7v75+Wlubu7o4naX5/dBZkthCs9cMIxcOHDwcMGGBqKxBGJSkpKSIiwtRWILoQT58+
9fb21vdXmUw2YMAAOp0OALCysiooKOhse9LT0/38/DgczqpVq0pKSvDwZcuWAQBsbW0BAIGB
gRiGqVQqf39/vHl3dXXNzMyEkd+8eVNZWYlhWFFRUXx8PAzUaDT//PMPhmFhYWEAgCFDhmRl
ZSmVSrwIfeF4QgzDUlJSHB0dAQAkEmnEiBHXr1/HMOzRo0fHjx/HMGzr1q1kMvnEiRMt11Ei
kWzZsgUAMHLkSE9PTzKZDAA4ceIEXsqZM2dwQRAUFAQD165da21t3a1bNyqVumbNGrVarZ1n
8/ujr6CUlBRD/xnGhcPh1NbWmtoKQ0F6AmHuHD9+fNq0aaa2AtGFyM3N7dOnj84/qdXq0NBQ
fILD3d29s40RCoUcDgcA4OvrKxAIHBwcXr16hWHYzp07LSwsDh8+jGFYXFwcAKC4uPj06dMA
gJ9//lmtVguFwqVLlwIAvvvuO5lMxuFwRo8erVKpBg8eDAC4ceMGhmGFhYWWlpb19fXJycmW
lpa2trZHjhzR7pX1heMJ16xZAwCgUqmbNm1KSEgIDQ2lUChHjx7ds2ePp6dnVlaWpaUlAKBX
r176KhgbG+vk5AT7dQCAg4PDjBkzdu3alZGR8fLlS1hKdnY2nU4fOnTorVu3YmJiAACvX7/G
MGzdunUwFa6QcJrfnxUrVugrSFsqmRU8Hk8oFJraCkNBegJh7iQnJ0+dOtXUViC6EC3oiWXL
ljGZTNgh0en0TZs2dbYxhw4dAgDY2dnV1NTIZDI/P7/g4GChUGhtbc1isaZOnbp48WIHBwcX
FxelUvntt986Ojpqd/wJCQm+vr5r164FAAwcOHDp0qU0Go3JZK5btw7DMKFQCACAAiU7Ozsw
MBAA4OPjk5KSotFoYA46w/GEixYtsrCwyMjIwEvcsGEDj8fbtm0bj8ezt7cfP378wYMHAQBF
RUU6KxgVFWVlZRUeHj5//nwAAD6gol3KrFmzbG1tq6urMQxTqVTr16+vr6/HMGz79u00Go3H
4y1cuFA7T533JzIyUl9BZgtea0KA/DER5g7yx0SYCYcPH46Li5PJZHhIZ/gQNCE/Px8A4O7u
bmNjw2AwoqKisrOzExMTqVRqcnJyfn5+fHy8m5vb+fPnLS0thUIhk8nEX8EhDx8+3LhxY58+
fZ4+fbpz587ff/99woQJxcXFAAAul2thYQGXXAoEguvXr9+/f9/V1XXKlCljxoyBro46w/GE
NBrNzc1t+PDheHFyubyxsbG6ulokErFYrBMnTkRERFAolMrKSp0V/OWXX6qqqlJSUjZt2gQA
0H7Y8VIKCgqGDBkCZy4sLCy+//57ON+Ul5fn6Oi4cuXK+Pj48+fPNzQ0wIQ678/Bgwf1FWS2
oPUdnQiG/DG7HgTzSEK8o9y6deuLL77AxQSJRBo8eLCLi0tnl1taWsrlcjMzM1etWnX9+vWk
pCQ+n//48eO+ffuGhobm5OQoFIrMzMx+/foBAKRSafOHRaPRTJ8+ffr06UqlcsmSJVOnTvXw
8Hjx4gWsBZ/Pr6io0Gg0M2fOzMnJ8fX1PXPmzNWrVwsKChYuXKgvHE8YEBCQn5+/evXqS5cu
JSYmhoaGbtmyJT4+vqamBgAQFxfHYDAYDIarq2tubq7OClKpVDjkA9dxaEfDSxk0aNDFixd3
796NKwbIr7/+6uXltXz58oCAgLCwMDabDZeP6rw/LRRkthCr9SOYnkB0QdD4BMLkFBUVTZw4
US6X4yEsFuv77783QtEKhWLixImxsbF79uwZM2YMjUY7efKkp6fn7du3s7Ozm0TGMKywsFDb
ThcXF2dn571797q4uAwaNAi+moeFhd27dw9GGDVqVI8ePQAA6enpAQEBs2fPXrVqVUpKikwm
u3//fgvhMGF4ePjq1asPHDgQEhKyYMECKpWanp4eERHBZDJDQkLGjh0LSwkMDGy+8VQTyGQy
mUy+efOmdiAs5X//+9/IkSO//PJLPp8/bty477///sKFCxqNpn///p9//rmFhcVff/01a9Ys
LpcLfTb13Z8WCjJPiKUnCOY/8eDBAx8fH1NbgTAqqampH374oamtQHQhnjx50rdvX/yrRCLx
9PRssplB7969cQ+DTiUyMnLevHlNAqVSac+ePe3t7f/444+8vLy8vLy0tLSVK1dC2/Lz89tQ
UHV19cKFC52dnUkkEo/HCwoKunPnTgvhLaNQKMrKyvCvr169eusSDwzDfvvtt7y8PJ1/UqvV
J0+enDlzJlwOSqFQHj9+rC8fffdn+PDh/fv3z8/Pb6Egs8LV1VWf34kZgvQEwtxJS0ubOHGi
qa1AdCG09YRKpQoMDISz9TgsFuvs2bPGMSYqKmr+/PnNw1++fBkQEKBtFY1G8/f3/+GHH6Cv
4jtMWVlZcXFxy3HejfvTvXt3IyxI7ijQflYIcwfNdyBMBYZhc+fOzc7ObjJt36NHD7gxgxGw
sbGpqqpqHu7h4ZGenp6Tk1NQUEAmk3v16uXt7Q0XZ77zwO0uWubduD/E8sckmJ5AdEEINoOI
eFfQaDTz5s07deqU9oIOAACLxdq+fbvRzHBycrp8+bK+vwoEAoFAYDRjOg+pVKpSqVqOU19f
D4WdhYWFtbU1AIBEInG53BaSEP3+EKv1Q3oCYe6g8QmESZg9e3ZaWloTMQEA4PF477//vtHM
GDFixIoVK+7du+fn52e0QtuJQqGoqqoqKyurrKysrKyEF1VVVRKJpL6+HkoHkUjU2NgokUga
Ghrq6+vbXyibzaZQKAAAJpNJpVIBAHQ6He48ZmlpyWKx8AsrKys6nc5isSwtLeGSVDabDVd/
MBgMGo1mbW1tYWHB4/EoFAqbzabRaPj23kYG6QkEoiNBegJhZOrq6goKCgoLC5uLCSqVGhUV
ZUxjhg8f7ufn9/r1a7PVEyKR6J9//nn+/PnTp0+fPXv27NmzoqKiJnFYLJazs7O1tbWVlRWL
xbK2tvbw8OByudodPNCSAoYgk8mUSiUAAFckKpVKKpUCADQaDX5OmFgshl0y1DFFRUW4psH/
ZAhQarDZbAsLC7iQhMlkcrlcJpPJZDJZLBZ+bW1tzeFw4DWbzWaz2XDRrIEFaYPmOxCIjoRY
Ch1BaIqLi2/fvr148WLostc8gpWVVXBwsDFNIpPJOTk5xizREJ4+fZqRkXH79u2MjIxnz57B
e2Vtbe3l5TVq1KjevXs7OTk5ODjw+XwnJyd7e3uzPYIVKg8oROB8CpQatbW1jY2NdXV1SqVS
JpPJ5XKFQiGRSOBBYmq1uq6urq6urqysTCaT1dbWvnW+Bk7NsFgsqDN4PJ62EGEwGLj4YDKZ
ffr06dWrFyBa60cwPYH8MbsgaHwCYTQOHDiwfv36FiJIJJJDhw6dP3+ey+VyOBz2v8BXUi6X
C99fjWaw0ZBKpY8ePbp79+7Nmzdv374NN7vk8/n+/v4ff/zxkCFDvLy8jLC7V4dDJpPhEaz2
9vbtzAoqD5FIBPWHRCIRi8UymUwmk0HxAa/FYrFEIgGuR/sAACAASURBVJHJZEKhsLa2FgbC
YRWctWvXwqNJkJ5AIDoSYj1RCEITGRlJp9PXrl0LB9Kbg2FYcnKyUqlsbGzUlwmDwcBFBo/H
s7a2ptPp8DgJOp0OX0DpdDqHw4Hj/DweD870c7lcOp1uqql6HLlcXlhYWFpa+ubNm8LCwkeP
Hv3zzz+vXr2Cj2GvXr3CwsJGjRr13nvv9e7d27SmmhVUKpVKpbZ8QHwL4NpCIpHgB6mj+Q4E
oiNB4xMIo+Hp6blq1apu3bpFRUXpVLEYhjEYjLq6OoVCUVdXJ5FI6urqRCJR3b/AkNraWrFY
DEPgaygcSxeJRIaYweFw6HQ6HACnUCgcDodMJkPfQKDlZgjdBgEAsA/DvQ5bAMOw2tpaAIBc
Lq+vrxeLxVKpVC6XS6VSsVgsl8vfvHkDI0BIJJKHh4evr+/cuXMHDhwoEAicnJwMvZuI1sDl
cpuvVSHW2xTSEwhzB+kJhJHx8/Nzc3OrrKzU3rgaR6FQnD9/fsKECQwGw5CNEJoAnQdra2sb
GhrkcrlYLG5oaIBvpQ0NDRKJRCqVNjQ0wOHxhoYG6FcI5++rq6uhCyHub6hQKHQaaQi4nyCP
x2MwGDY2Nu7u7sHBwXCLbjc3t27dunXr1g3uYI0wCUhPdCIajabJ0XmIdx5iPVGIdwAMw1gs
VkJCwvjx45tMbAMApFLp0aNHJ0yY0LbM6XQ6nONot5lNrYL+gLW1tRQKBW7PoA98/waEmYPm
OzoRpCe6IGh8AmESAgICTp8+PWHChCYDABiG/fXXX+bWFuEzHR2uVBAmhFhvU2b0PBiCuT3D
CCOA9ATCVAQFBV24cKG5UwKGYbdv3zaJSYguBZlMJtD4BMH6ZqQnuiDEUuiId4yAgIBz5841
kRQymez33383lUmIrgOFQiFQ60ewvhnpiS4IGp9AmBY48cFkMvEQtVp94sQJAjX0CIJCrLcp
gvXNSE90QYj1RCHeAZrvmxcUFHTmzBltSdHY2HjlyhWjm4boWhDLH5NgfTPSE10QND6BMAeC
goLOnz+PT3xIJJJt27aZ1iTEOw+x3qYI1jcjPdEFQXoCYSZo+1JgGHbt2rWysjJTG4V4l0F6
ohNBeqILQqwnCvFuoy0pyGTywYMHTW0R4l0GzXd0IkhPdEHQ+ATCrMAlRX19/a5du5DYRXQe
xHqbIljfjPREF4RYTxSiK4Cv+KisrERemYjOg1itH8H6ZqQnuiBofAJhZJqv72gOdM+0tLSM
jY01jlWILgia7+hEkJ7ogiA9gTBPAgICLly4cOvWrYqKClPbgng3QeMTnQjSE10QYj1RiC4F
3JfixIkTpjYE8W5CrP220XlgCHMHjU+8S6xYscLT0/Ozzz4ztSEdRkBAgJubm6mtQLyboP22
OxGkJ7ogSE+8S5w8efLcuXOmtqKDQXoC0UkQa3SWYH0z0hNdEGI9UWaI+czuK5XKgoIClUpl
akPegiH+mAiEEUD+mJ0I0hNdEAKNT+zdu7empsbUVjRl3bp1p06danPyKVOmTJ48uUMsefr0
qVqtlkqlHZIbAvHOQ6y3KYL1zUhPdEHM9ol6+PDh1q1btb8uXrz45s2b+uKXlZUdPny4s63S
WUpGRkZ78kxNTU1KSmpPDpDS0lIAgI2NTfuzQiC6Ambb+umEYH0z0hNdELMdn9i1a9eKFSsU
CgX8mpyc3KNHj7CwMH3x7969u2DBgsbGxk61qnkpbDb75cuXbc4wOTn5yJEjbDa7/bbJZDIA
gIODQ/uzQiC6AsSa70DrOxDmjnlOZkul0qSkJAsLCxqNBgBQqVS//fbbsmXL4Fd9NDY2ikQi
Pp/fqbY1KcXKyqq2ttbw5DU1NTExMSUlJb6+vvPnz+fxeHPmzAEAPH78uL6+3sfHp4U63r17
98qVK46OjpGRkc2jNTQ0AABGjx7d6iohEF0SND7RiSA9gTATdu/eLZVKeTwe/JqYmCiVSj/5
5JM///zTycmJRCKRyeT33nvvxo0bMIJUKn3x4gUAYMqUKb1796ZQKCQS6c8//9SXv0Kh+OKL
LywtLUkk0oABA0QiEf6npKQkHo+nfbLl3r17CwoK9JWSmpoKO/IHDx706NFj2LBh0CNSp6mN
jY0TJ07cvHnz0aNHV6xYMXDgwMzMzAcPHgAATp48OXToUDqdzuFwhg0btmjRomPHjmnbvHz5
8uHDh2/btm3+/Pnjxo2Dgfv27bO0tGQymQcPHoRmtDCEg0AgtCGWngAYoTh8+PDHH39saisQ
RuX58+e9e/c2tRX/h5KSEiaT6ezsDA1TqVSenp4//PDDmjVrAABUKnXTpk0JCQmhoaEUCmXY
sGFOTk64DnZwcJgxY8auXbsyMjKUSqXO/FUq1QcffODt7Z2SkvLixYtx48b5+vpqNBr41//8
5z8sFksqleLx+Xx+9+7d9ZUSExMjEAjKyspcXFzgX/ft26fT1KNHj54+fRoA8PPPP6vVaqFQ
uHTpUj6fb2lpWV9f39DQkJycvH379jVr1tjZ2QEAmEwmXoWdO3daWFgcPnwYw7C4uDgAQHFx
8YEDBwAAXl5eU6ZMWbVq1axZswAA+mptPty/f9/X19fUViAQ2OLFi3fv3m1qKwyFYHri0KFD
UVFRprYCYVTMUE+Eh4dPmjTpxx9/dHZ2xjDshx9+4PF4YrF40aJFFhYWGRkZeMwNGzbAbjs8
PHz+/PkAgMzMzLfmv3v3bg6HU1RUhGGYSqVydnYGAJw6dQr+NSIi4r333sMjnzx5EgAgEAis
rKx0lrJ7924PD4+hQ4f27t37yZMnvr6+wcHBOk3l8XgrV650dHRUq9V4uFAoBAC8evUKfs3K
yhozZgyNRvv000+fPn2Kx7G2tmaxWFOnTl28eLGDg4OLi4tSqRw0aFBYWJhCocAw7P79+xQK
BQBw8eLFVt9x44L0BMJM+PLLL3fu3GlqKwyFYHMHaL4DYXJu37598eLFHTt2ODo6lpWV7dq1
a926dVu3bmWz2TQazc3Nbfjw4XhkuVxOo9HKy8tTUlI2bdoEAMAM8C29efPm1KlTXV1dAQBr
1qwRCoUeHh7R0dFKpRIAQKfT37x5A720pFLpmjVrIiIi/v7776qqKp2lyGSyV69ePXny5Pz5
83379p08efKDBw+oVGpzUxsbG6uqqphMpvZTxuVyLSwsbt269erVq48//jggIGDw4MEFBQW/
/vqrt7c3jJOYmEilUpOTk/Pz8+Pj493c3OBZWcXFxVFRUVQqtaysbMqUKUFBQZMmTUpNTW3f
fwCB6CoQa76DYH0z0hMI09LQ0DB37tx169b17Nlz8ODBGIZ99dVX48aNmzdvHgAgICAgPz9/
9erVly5dSkxMDA0N3bJly+HDh6GbBVwikZub+9ZSPDw8jh07tnTp0pEjR27ZsmX//v2pqamF
hYUffPCBRCL5+OOPCwoKZs+e/csvv/j7+zc2NsbFxVGpVCaTqbMU6GmxYcOGnj17AgDCw8Or
q6vt7e2bmxofH69UKpu0XyQSic/nV1RUrFmzJiEhgUKh3L17d/bs2ePHj1+8eDHc7PLx48d9
+/YNDQ3NyclRKBSZmZn9+vUDANjY2GzevHnZsmV+fn4kEuno0aOffvppYmKiRCLpsH8JAvHu
Qqz1HQSb74iLi/v8889NbQXCqDx79szLy8vUVvx//ve//1lbW8tkMvh13Lhxffv2LS0thV81
Gs3q1avt7e0BAAwGY+LEibdv38bTKhQKMpn8ySefvLUUoVAYGBhIIpF69uyJzw6cPn2awWDM
nj0bw7C4uDgrKysul7tgwYLKykrttM1L2bdvn6+vb0NDAx4yadKktLQ0nabOmjWLTCbjFYRE
REQcP378ypUrvr6+zQX9yZMnt23bRiaTs7KymlQkOTnZ2trawsIiPDy8vLwcBkZFRT158uSt
N8GEoPkOhJmwfPnymJgYU1thKGa6sl8f+/bte/To0d69e01tCMJ4PH/+/MMPP3z27JmpDQEA
gPT09Lq6ugkTJrQt+eHDh0eMGOHp6dmxVnVgKVeuXNm5c2dr99OUyWQDBgyQyWQ7duwYPHgw
AODZs2e3bt26efOmVCpNS0uDQyNE4d69e59++mlOTo6pDUF0daKjo21tbVeuXGlqQwwC7T+B
QLSCkSNHtif53LlzO8qSTiolODg4ODi4tamYTOalS5eioqLgCg4IjUbz8/OLiIhwcnJqsz0m
AbUzCDPBbHfz0wnSEwgEogPw8PBIT0/PyckpKCggk8m9evXy9va2tLQ0tV1tATPLLdQQXRCk
JzoRpCcQCHNGIBAIBAJTW9FeUDuDMBPQ+o5OBD3nCASis0HtDMJMINb4BMGeGfScIxCIzgbN
dyDMBKQnOhGkJ7ogqHFHGBnUziDMBKQnOhH0nCM6DwI9t4hOBbUzCDMB+U90Iug5R3QShw4d
4vP5UqnU1IYgWkFsbOzmzZs7PFs0JIYwE9D4RCeC9ASizWRlZYWHh1+9elXnX69du1ZTU4P2
gSYWRUVFq1atau3uW28FtTMIMwHpiU4EPeeItvHgwYP333/f29t71KhR+iIAANBbKbGIiYkZ
M2bM6tWrO7bNRe0MwkxAeqITQc854q08fPgQnoClzVdffSUQCDZt2mRhoWPPFZFI9OTJE525
NTQ0pKSkjB07lkwma5/GiegMFi9evH//fsPjk8nkn376KTc39/Tp0x1oBprvQJgJyH+iE0HP
OaJlzpw5ExwczOfztQMfPHhw8+bNHTt26Et17Ngx+BKgfZQfPJ7b3t5+6tSpUql0//79hhwc
8+LFi379+sGDxU3IlClTJk+ebMyEHQKGYbdu3WoSqNFoHjx48PjxY51JhgwZEhgY+Ouvv3ag
Gei9BWEmoPGJTgQ9510Qw0VkTEzMhx9+aG9v32QQ4tixY4MHD/bx8dGX8Ndff/38888BAHV1
dQAAtVo9adIkLy+vhIQEgUBw/vz5jIyMefPm+fn5vdUGhUKRm5srl8sNMbhTSU1NTUpKMmZC
fZSVlR0+fNiQmPb29gUFBfhXpVK5d+/eXr16DRs2LDo6uri4WGc+X3311blz5968edNRBqN2
BmEmID3RiaDnHKETlUo1d+7c9evXk0ik5sdZXbx4ER56qZPLly+/efNm4cKFAACZTAYAkEql
p0+fVqvVly5dunbt2rhx4wy3RHuEw4QkJycfOXKEzWbDrxKJ5NixYytWrEhISNCO1jy8ScIO
4e7duwsWLGhsbDQkslgshhc5OTl+fn7Lly+fNGnSy5cvz549m5OTozOfjz76qFu3bomJiR1l
MBoHRZgJxNIT6PwOBOGRy+UhISH379+Xy+UsFkv7iEuIWCzW15mp1erVq1dHR0fD072hnuBw
OD/++OOaNWvmzZu3bt26OXPmGHiulUQiuXbtGgBg8+bNfn5+3bt3Hzp0aNsqdffu3StXrjg6
OkZGRtJoNABATU1NTExMSUmJr6/v/PnzeTxeC8nJZPKcOXMAAPn5+du2bTty5AhcutKjR4+W
w/GEHUtjY6NIJGoyD/X48ePU1FQWi/XZZ58xGAwYqNFopFLphg0btm/f7u/vn5aW5u7u3nI+
ZDI5JCTkwoULy5cv7xBrUTuDMBOI5T8BMEIRHR39008/mdoKhFHJzc3t06ePvr/W1dUJBALY
G5FIJIFA0DyOv7//gAEDdCbfsWOHt7e3QqGor68HAPz555/4n/7+++/AwEAAgKur6969e9Vq
dQtG3rt3T2cHHxISotFo9KVKT0/38/PjcDirVq0qKSnBw5ctWwYAsLW1BQAEBgZiGKZSqfz9
/fFsXV1dMzMzYeQ3b95UVlZiGFZUVBQfHw8DNRrNP//8g2FYWFgYAGDIkCFZWVlKpRIvQl84
nhDDsJSUFEdHR3hjR4wYcf36dQzDHj16dPz4cQzDtm7dSiaTT5w40cJtwTBMIpFs2bIFADBy
5EhPT0/YT6ekpJw5cwbqJABAUFAQjLx27Vpra+tu3bpRqdQ1a9Zo33N9+cC/7tixw8PDo2VL
DCctLW3ixIkdlRsC0Wa2bNmyYsUKU1thKATTEytWrNiyZYuprUAYlRb0hFwu9/HxodPpsFti
MBh3795tHi02NhYA8NdffzUJFwqFtra2X3755YEDBxYsWAAAIJPJe/fu1Y5z/fr10NBQAMD0
6dNbkBT5+fksFis0NPTrr78GACxbtmz37t1ff/31tGnTGhsbdSYRCoUcDgcA4OvrKxAIHBwc
Xr16hWHYzp07LSwsDh8+jGFYXFwcAKC4uBiuX/j555/VarVQKFy6dCkA4LvvvpPJZBwOZ/To
0SqVCs7p3LhxA8OwwsJCS0vL+vr65ORkS0tLW1vbI0eOaNuvLxxPuGbNGgAAlUrdtGlTQkJC
aGgohUI5evTonj17PD09s7Ky4JhNr1699N2T2NhYJycn/EXfwcFhxowZu3btysjIyMjIoNPp
Q4cOvXXrVkxMDADg9evXGIatW7cORsaFUcv54Epo3759Dg4O+ixpLadOnZo0aVJH5YZAtJmY
mJjly5eb2gpDIZieWLZs2datW01tBcKotKAnPvzwQ3ycnEKhhIaG6oxWV1fn6enp7u4uEom0
w6dOnYq/8cPeMSgoSCKRNM9h9+7dAIDff//9rdZmZmYCAJ4/f/7WmIcOHQIA2NnZ1dTUyGQy
Pz+/4OBgoVBobW3NYrGmTp26ePFiBwcHFxcXpVL57bffOjo6anf8CQkJvr6+a9euBQAMHDhw
6dKlNBqNyWSuW7cOwzChUAgAgAIlOzsbDrT4+PikpKTg4yU6w/GEixYtsrCwyMjIwEvcsGED
j8fbtm0bj8ezt7cfP378wYMHAQBFRUU6KxgVFWVlZRUeHj5//nwAAD6ggmHYrFmzbG1tq6ur
MQxTqVTr16+vr6/HMGz79u00Go3H4y1cuNCQfHCWLVs2cuTIt95zAzl58uRHH33UUbkhEG3m
559//uabb0xthaEQbI4QzWt2QTA9znHJycmXL1/GV1LQaDQ4Ht4ca2vrP/74o7S0dPz48fgO
mJs3b75x40ZYWNjy5csvXrxYXV09evRoOzs7FosVHR0NX5px5s+fz2azX7x48VZrYf76Fjdq
k5+fDwBwd3e3sbFhMBhRUVHZ2dmJiYlUKjU5OTk/Pz8+Pt7Nze38+fOWlpZCoZDJZDb58T98
+HDjxo19+vR5+vTpzp07f//99wkTJhQXFwMAuFyuhYUFXHspEAiuX79+//59V1fXKVOmjBkz
Bvo86gzHE9JoNDc3N+0tN+RyeWNjY3V1tUgkYrFYJ06ciIiIoFAolZWVOiv4yy+/VFVVpaSk
bNq0Cfzf41EKCgqGDBkCJ3QsLCy+//57OMiUl5fn6Oi4cuXK+Pj48+fPNzQ0tJwP5OnTp4cO
HZo9e/Zb77mBoHYGYSYQyx+TYM8Mes4RELFYvHDhQug+Cenfv/+AAQP0xR88eHB8fPydO3cC
AgJevHhx8ODBdevWnTp16uzZszExMWPHjmWz2VwuNzs7GwDw+PHjlStXDh8+/Ouvv16+fPmi
RYv69++v0Wiae3o2x97enslktuwsCSktLeVyuZmZmatWrbp+/XpSUhKfz3/8+HHfvn1DQ0Nz
cnIUCkVmZma/fv0AAFKptLlblkajmT59+vTp05VK5ZIlS6ZOnerh4QFFD4lE4vP5FRUVGo1m
5syZOTk5vr6+Z86cuXr1akFBwcKFC/WF4wkDAgLy8/NXr1596dKlxMTE0NDQLVu2xMfH19TU
AADi4uIYDAaDwXB1dc3NzdVZQSqVymQyAQBwtYh2tEGDBl28eHH37t1QMeD8+uuvXl5ey5cv
DwgICAsLY7PZBQUFLeQjk8lmzZrl4+Nja2s7d+7ct95zA0HtDMJMIJaeINh8x5dffrlz505T
W4EwKk+ePOnbt692SGNj45gxY3C3CQAAm81+q2MghmFxcXEkEsnd3d3T0/PixYtN/vrFF1+Q
SKT6+vqampro6GhXV1c4LkKj0YKDg7OzszuyVhg2e/bsOXPmxMbGslgsEok0evToR48ebdu2
jUwmZ2VlNYk8a9YsMpksk8nwkGvXrjk7O4tEovj4+EGDBjU0NGAYlp6ezmKxYISIiIjjx4+r
1epu3brR6fTIyMjo6OjFixfz+XwvLy994XhCjUazevVqe3t7AACDwZg4ceLt27cxDPvmm29C
QkJwM+bOnfvZZ5+1XFOFQkEmkz/55BM8pK6uDk61sFiskJCQ77777vz582q1euDAgdDFUiaT
RUZG8vn80tLSFvLJzc2lUqmzZ88uKCho3d1vkePHj0+bNq0DM0Qg2saOHTuWLFliaisMhWB6
YvHixbt37za1FQij0kRPaDSaTz75BL6w4jCZTNihvpW0tDR7e3udkRUKxaVLlzrM7rcRGRk5
b968JoFSqbRnz5729vZ//PFHXl5eXl5eWlraypUrYTXz8/PbUFB1dfXChQudnZ1JJBKPxwsK
Crpz504L4S2jUCjKysrwr69evTJEyf322295eXnaIWq1+uTJkzNnzoTLQSkUyuPHj9uQT2eQ
lJQUERHR2aUgEG9l586dX375pamtMBSC7T+hVqspFIqprUCYDI1GM2fOnFOnTmnPdJDJ5MmT
J+OLD1tm4sSJFRUVOv9EpVLff//9jjHUACwtLZv7hTCZzEuXLkVFRWnPrdBoNH9//7CwMCcn
pzYUZGtru2/fvn379hkY3jJUKhUuIoW4u7tr7w+hj+aTEWQy+aOPPvroo48AAOXl5Y2NjS4u
Lm3IpzNA8x0IM4FY8x0E0xONjY1IT3RZVCrVjBkzLly4oC0mAAAsFuuTTz4xlVVtxsbGpqqq
qnm4h4dHenp6Tk5OQUEBmUzu1auXt7e3gRtqmS0ajQbf+LI5KpVKpVIVFhay2WwymQyX0ZoQ
DO2PiTAPkJ7oRNRqtc7zIRHvPGKxOCws7MGDB03EBABArVbrO4XcnHFycrp8+bK+vwoEAoFA
YEx7DEckEtXU1NTU1AiFQqFQCC/gp0Qiqa+vl0gkSqVSLBY3NDTU19fX1dW1dhtyEonE5XIB
ANCzlcPhkMlkNptNoVC4XC6Px2v+iV+0X3uh8QmEmUCs/TEJ1jej+Y4uCIZhjY2NQ4YMKSkp
gbtYNiEkJISIKnPEiBErVqy4d++eIceMGRMMwyorK8vLy9+8eYN/lpSUVFRUlJSUVFZWqlSq
5qlsbW1tbGzYbLaVlZW1tTWHw6FSqdbW1gwGg0ajcblcEolEo9Hw/UJ0olar6+rq4GAGhmG1
tbUAAJFIBACora3FMEwsFpeVlYlEotraWn2HrsH1NVwu18bGplu3bvb29o6Ojk5OTvb29s7O
zvb29vb29i03I0hPIMwEND7RiSA90dUoLS29ePHiq1evyGSyzm6MzWZHRkYa37D2M3z4cD8/
v9evX5tET1RUVEB9oPOzya22t7d3cHBwdXXt27evi4sLlA7wE78w/gSBQqGora2F2kLnZ1VV
1f3790tLS+GxsThkMhmqCmdnZwcHB0dHR0dHR3t7e4FA4OXlBdB8B8JsQHqiE2lsbCTimyii
zfz666/r168H+s/tlMlkDx8+lMlkcMTbxsYGXmivJjVPyGRyTk5OJ2VeX19fVVVVUVFRVVVV
WVlZXFwMP/UpBj6f7+jo2K1bN29vbxcXF7gvJ/5JpVI7yc72QKPRHBwcHBwc3hqzvr6+oqKi
rKyssrKytLS0oqKivLwcfs3Nza2srITbYKxduxZu+I3GJxBmAtITnQgan+hqREZG1tbWwk1H
dEZQq9UbNmxoHs5gMHj/wuVyGQwGh8NhsVgMBoPFYnE4HAaDwWQymwdaWVl1cp3aTl1dXV1d
nVgsFovF+IVIJBKJRJWVlVVVVdXV1RUVFZWVlc29TOzs7BwdHV1cXLy8vJorBgNXxxAUKyur
Hj169OjRQ18EkUhUXl4OPTYA0hMIswH5T3QiSE90NTw9PT/99NO0tLSqqiqpVKozTrdu3W7e
vCkUCmHP2uRCKBSWlpbC6Xa5XN7CKgMI9ARkMpkMBsPa2hrfnJFOp0OpwWQy4fu6tbU1HC2D
zgG4C6EhNDY24jt/i8VieEi3SqWSy+XwsNOGhgalUimTyRobG+vq6mpra6EDgc7c6HQ6n8+H
Y/i9e/e2s7NzcHDg8/l8Pt/Ozs7JycnR0fHdVgztBOpO/Cua70CYCWh8ohNB8x1dEwaDce7c
ufHjx+uUFHV1dRUVFdrHebeMVCqVy+VSqVQsFkORUVtbK5PJ5HK5RCKpq6uDgSKRCPbu4F9n
QHzRI64GFAqFPq/AVgGlCVQqVlZWdDodui5CTQMHVyBwX3Aul6sd0rKTI6K1oPEJhJmA9EQn
gsYnuiDwZTEgIECfpJDJZLGxsYbrCRaLxWKx4E7SHQUcUYDGKJVKuKjBkIRwJWQHWoJoP0hP
IMwEpCc6EaQnujL6JIVGozl16lRtba3h0w0djpWVFZwNMeQkMISZg+Y7EP+PvfOOi+L4//9c
4Y5rVBGsUYoSK4KoKAqiUcAWxdjQSMRojImfGBuaxJqowWjEHokmYCwRiUTsBEXFGJoaJRZU
QBGxwQF3x3F1f3/ML/u9HAcecG259/MPHsfs7Ox7y8y85j3vnbUQqBU/QTENDnrCysGSgs/n
a6UzGIxDhw6ZxSSg5QH+CcBCoJZ/gmJ1BuIngMDAwNTUVK2IAYlEsm3bNnOZBLQwQE8AFgLo
CSMC/gkAIRQcHHzq1CktSfHgwQOlUmkuk4CWBMx3ABYCzHcYEdATAKaupODz+ZcuXTKjSUCL
AfwTgIUA/gkjAvMdAElwcPC5c+fIWAqRSPT999+b1ySgZQB6ArAQQE8YEfBPWCENOJ81wzMJ
gkhPT3/58qVprQNaIDDfAVgIoCeMCOgJQAtNSUGj0fbv329uiwDKA/4JwEKA+AkjAnoCqAsp
KaRSaVxcHIXkPGCZgJ4ALATwTxgRiJ8AdIJfhogzKwAAIABJREFUIuXxeC9evLh48aK5zQGo
TY8ePfRfbhUAjAfoCSMC/gmgPoKDg8+ePWtjY7N161Zz2wJQm1GjRo0bN87cVgAAzHcYE9AT
QAMEBgaeO3fuypUrr169MrctAAAAzQX8E0YE5juAhgkODk5NTf3tt9/MbQgAAEBzoZaeoFjf
DP4JK6SxL+8FBgZ26tTJaOYAAACYCGrpCYr5J0BPAPrQvn17c5sAAADQXCB+wogolUrQEwAA
WBqzZ88ePnx4amqqRCIxty1AywH8E0ZEpVJB/AQAAJbG77//np6ePnbsWIFAEBYWdvbsWXLT
uXPnWrVqtX79+ocPH76xHKFQWFxcXFxc/Pjx44qKCgqNTQFjAHrCiMB8BwAAloZEImnXrt2U
KVNWrFgxfvz4P//8MywsbPDgwY8fP0YI1dTUlJeXf/HFF15eXl26dFm6dOmjR480dy8oKPjx
xx/nzp07ZMgQNze3zp07d+7cuVOnTs7OzgwGg0aj0Wg0JpO5a9cu85weYD6oNd9BsbE+6AkA
AExDWVnZ+fPnZ86c+cacy5cvLy0tvXbtGofDQQiVl5d/++23cXFxISEhf/755/jx40ePHn32
7NnFixdnZ2dv3rz5u+++mzx58p49e9LS0r744ouCggKEUJcuXdzc3ORy+cSJE6dNm1Y3Brlb
t27GOE3AkqGWf4JiegLeF7VC4ONMgFERiUSnT5/Ozc3t1avXjBkzyPSsrKzZs2dHRka+sc2x
tbV9/fp1aWmpp6cnQsjZ2Tk2NnbcuHFDhgxZvXr17t27GQxGcHDwhg0bEELPnj07fvz4hg0b
Bg0a5O7u/uTJkzVr1kyZMqVLly4IIYFAMG3atPHjxxvzjAHKAHrCiIB/AgBaMOXl5Zs2bXr6
9KmPj090dLSjoyNOz8rKSk9Pd3Nzi4yMZLPZTS5fq5zCwsItW7YkJiaKRCKEUKdOnTT1BEJI
qVQKhUIXF5eGi+3YsSONRmvVqtWmTZvCwsJ69OghlUplMhmTyZRKpQih+/fvT5kyBWdu27bt
/PnzBwwY0Ldv39DQ0B9++KFNmzZkUXK53MbGpsknCLQwqKUnEEEp6HS6SqUytxWASbl582bv
3r3NbQVgdBQKheZXMzp06JCdnU0QxKJFixBCzs7OCKGgoCAyv1QqTU1NXbt27caNG3/++efK
ysrDhw87ODg8e/aMzLNz586ioiL8u2454eHhCCF/f/+cnBy5XK5pjEgkio2NRQgNHjzYy8sL
fx4sOTlZp+Xbt29v1arV1atXtVrXkSNHvnz5UiqV0un08ePHb9++PTY2dubMmX369GEwGM7O
zjk5OZrlyGQyhFBqaqohLifQEkhLSxs+fLi5rdAXKukJtVqNxRpgVYCesBJSU1MRQps3b1ap
VBUVFQsXLvTz89u2bRuTyUxISCAIYs+ePQihkpISgiB27dqlNQu2aNGiTz75hM/ni8ViskwX
F5fNmzcTBKGznKSkJBsbG2dn58TERHKgEhcX16ZNG/L7oq6urlOmTNm+ffu1a9e0NAfJpk2b
unTpolQqsXuDyWR+//33pFa4fv06LorJZPr7+0dFRa1bt+7XX3+tqqrSKkelUoGeADT5448/
hg0bZm4r9IVKekKhUDCZTHNbAZga0BNWwvLly93c3DQdkBUVFQKBgM/nT5w4cf78+a6uru3b
t5fL5Z9//jlCyN3dfe3atZcvXx45ciRCaM2aNZMnTx40aBC5+/HjxxFCt27dqq8cgiByc3OD
goIQQr169UpOTlar1VFRURwOZ8KECdHR0Qgh7CNpmK+++qpXr1749/fff89isfr16/fq1Suc
cujQIRaLlZ+fr89FYLPZv/zyi/4XDWjZpKenh4SEmNsKfaHS+6IQPAEALZiKigoej0c6BhBC
hw8fZrFYSUlJhYWF8fHxHTt2xJ+QvXDhQkBAQEFBwVdfffXo0aO0tDQej7dw4UJbW9vS0lI8
yheLxV9++eXkyZN79uxZXzkIIT8/v4yMjBs3bnTo0CEiIiIkJCQ2NvbVq1fJycnr169HCBF6
zF7zeLwnT57glaw+++yzjIyMoqKigQMHFhYWIoQeP37cqlWr7t2763MR2Gw2fM0OIKFW/ASV
9AS83AEALRixWKz1qn1+fn63bt1CQ0Pz8vJkMll2djbulbt27Xr//v2tW7fOmjVr1qxZAoGg
R48eAoHg/fffLy4unj59+g8//BAQEKBUKvHURn3lqNXqqVOn5uXl+fj4nDx58sKFC8XFxQsW
LODxeAghOzs7hNCdO3feaHm7du0qKysvXbqE/w0ICLhx4waPxxs6dGh5eblQKNS/S6DRaPj1
UQBAVFt/gkp6AvwT1gkB74taBwRBPH78uKamhkzx8vK6evVqbm6uVs6vv/66TZs2y5Ytu3Pn
zuXLl9977z0+n48QCgkJ2bNnz++//x4TEzNgwIArV644ODg0UA5C6MqVK4GBgdOnT4+JiUlO
TpZIJDdu3MCb6HQ6nU6/fPnyGy338vLi8/ldu3YlU9q1a3fy5Ekul1tSUiIUCp8/f45fIXkj
b7/9dp8+ffTJCVgD1PJPUGm4D3oCAFows2bNEovFXC6XTJkzZ8727dtHjRq1devWvn37IoTu
3buXmZl5+fJlGo324MGDzp07I4QuXryYnZ2Nd5k7d+7cuXO1Sm6gHLVaHRQUdPHixbKyMgcH
h969e2/cuBHvxWKx9u/fP3DgwDda3r9//7pyoV27dnfv3kUIBQQE3Lx5UyAQ6HMRrl27pk82
wEqglp6gUjzmy5cvXVxczG0FYGpu3Ljh4+NjbisA8/Dw4cPAwEDNJovNZgcEBKxbt04qleI8
f/31F0Lo8uXLzSyHZMOGDSdPnjTWKQGA3mRmZmqGGFs44J8AAMBy8fDwuHLlSl5eXnFxMZ1O
9/T09Pb21lrxqX///u+99x6OhHB1dW1yOSQPHz584xpWAGACqOWfAD0BAICl4+fn5+fn10CG
AwcOxMfHa8ZeNK0cDDQ1gIUAesJYQCUHAEAnbDb7k08+MVRparVa87VVADAX1NITVKoz8L6o
dULA+x2AaYGhC2AhUOt9USp1z1DJrRPQE4CJ2bJlC/kpMgAwI9TyT4CeACwdcD4DJqZ169bm
NgEAEKKanqBSMw3zHdYJ+CcAoD7i4uK+/fZbc1sBGAtqzXdQSU+Af8I6Af9ESyInJ2fChAkX
LlwwtyEthCdPnsTExPz+++/mNgTQAf6UTHMA/4SxAD1hnYB/osXw999/Dx8+3Nvbe8iQIea2
pYWwadOmkJCQFStWUKjXsR6ePn2akZHRnBJATxgLpVIJesIKAf9Ei2HBggV+fn7r16+Hicv6
mD9//o8//qh/fjqdvnHjxjt37qSmphrPKqBpvPXWWwkJCc3xxoGeMBYqlQqaISsE/BMtg7//
/vvy5ctbt241zeEiIiLGjx9vyh0NAkEQmZmZWolqtfrvv//Oz8/XuYu/v39QUNDevXuNbx3Q
aBYtWjR27NgmeykgfsJYwHyHdQJ6omXw66+/9u3bt1evXiY7YkpKypEjR0y5Y32UlZUlJCTo
k7N169bFxcXkv3K5fNeuXZ6env3791+2bFlJSYnOchYsWHDmzJnS0lJDGQwYih49egwdOnTE
iBFN81KAf8JYgJ6wTmC+o2Vw/vx5/G1P05CUlJSYmGhnZ4f/FYlEv/7665IlSw4cOKCZrW66
1o4GISsra/bs2UqlUp/MVVVV+EdeXp6vr+/ixYvHjh378OHDU6dO5eXl6Szn3Xffbdeu3eHD
hw1oM2Ao1q1bp1AoRo8e3QQvBbX0BJWmDxQKRX3f7wFaMOCfaBlUVVXp2aFisrKy0tPT3dzc
IiMj2Ww2Qqi8vHzTpk1Pnz718fGJjo5ueMkpOp0+Y8YMhFBhYeGWLVsSExPxJ8U7derUcDq5
o2FRKpVCoVDrM2P5+fkpKSl8Pn/OnDnkh9rVarVYLF67du33338fEBBw4sQJd3f3hsuh0+kj
Row4d+7c4sWLDW450Ex8fHw8PT0fPnw4atSo1NTUkJAQ/fel1nwHlb5XfubMmdDQUHNbAZia
CxcuDB061NxWAM0lICCgZ8+eWolXrlzx9fW1t7ePiYl5+vQpmb5o0SKEkLOzM0IoKCiIIAiF
QhEQEEA2XB06dMjOzsaZS0tLX758SRDEkydP4uPjcaJarb558yZBEOHh4Qghf3//nJwcuVxO
HqK+dHJHgiCSk5Pd3NwQQjQabeDAgRkZGQRB3L59++jRowRBfPfdd3Q6/dixYw2fuEgkio2N
RQgNHjzYy8sLO9uSk5NPnjyJdRJCKDg4GGdetWqVQCBo164di8X68ssvVSrVG8vBW7du3erh
4aHHfQDMwOrVq/G95nK56enp+u949+5db29v4xlmWKikJ06cODFmzBhzWwGYmvT09JCQEHNb
ATSXuLg4hNDp06fJlIqKCnt7e4SQj4+Pn5+fq6vro0ePCILYtm0bk8lMSEggCGLPnj0IoZKS
Evz+wubNm1UqVUVFxcKFCxFCX331lUQisbe3Hzp0qEKhwPMply5dIgji8ePHNjY2Uqk0KSnJ
xsbG2dk5MTFRs3uuL53c8csvv0QIsVis9evXHzhwIDQ0lMFgHDx4cOfOnV5eXjk5Odhd6unp
2cApt2nThpytc3V1nTJlyvbt269du3bt2jVbW9t+/fplZmZu2rQJIVRUVEQQxOrVq3FmUhg1
XA6phHbv3u3q6mqgewUYmH/++YfH4+Hbx+VyL168qOeO9+7d69q1qzFNMyRU0hO//fbb+PHj
zW0FYGrS0tKGDx9ubiuA5lJdXe3l5eXu7i4UCnHKTz/9hBBq1apVeXm5RCLx9fUdNmxYRUWF
QCDg8/kTJ06cP3++q6tr+/bt5XL58uXL3dzcNDv+AwcO+Pj4rFq1CiHUu3fvhQsXstlsHo+3
evVqgiAqKioQQlig5ObmBgUFIYR69eqVnJysVqtxCTrTyR3nzZvHZDKvXbtGHnHt2rWOjo74
6x6tW7cOCwvbv38/QujJkyc6TzkqKorD4UyYMCE6OhohRDpUCIKYNm2as7Pz69evCYJQKBRr
1qyRSqUEQXz//fdsNtvR0fGjjz7SpxySRYsWDR48uGm3BjABb731Fuld099LUVBQ4OXlZWzb
DAWVwtxgvW3rhID4iRaBQCA4dOjQs2fPwsLCcMhCYWEhQsjd3d3JyYnL5UZFReXm5h4+fJjF
YiUlJRUWFsbHx3fs2PHs2bM2NjYVFRU8Hk8rMvfWrVtff/3122+/fffu3W3btv3yyy+jRo0q
KSlBCDk4ODCZTPzupZ+fX0ZGxo0bNzp06BARERESEoJjHnWmkzuy2eyOHTsOGDCAPFxNTY1S
qXz9+rVQKOTz+ceOHZs8eTKDwXj58qXOU/7hhx9evXqVnJy8fv16hBChEVhXXFzs7++PJ3SY
TObKlSttbW0RQgUFBW5ubkuXLo2Pjz979mxtbW3D5WDu3r37008/TZ8+vbk3CTAaUVFR+BYj
hGpqasaMGaPPGx/Uav1ATwCWDrVqFNAAffv2jY+P/+uvvwIDAx88ePDs2TMHB4fs7OyYmJiM
jIwjR464uLjk5+d369YtNDQ0Ly9PJpNlZ2d3794dISQWi+sGpqnV6kmTJk2aNEkul//vf/+b
OHGih4fHgwcPEEI0Gs3FxeXFixdqtXrq1Kl5eXk+Pj4nT568cOFCcXHxRx99VF86uWNgYGBh
YeGKFSvS0tIOHz4cGhoaGxsbHx9fXl6OENqzZw+Xy+VyuR06dLhz547O82WxWNjLjd8W0czW
p0+f8+fP79ixAysGkr1793bt2nXx4sWBgYHh4eF2dnbFxcUNlCORSKZNm9arVy9nZ+eZM2ca
4CYBxmHatGma7Zj+koJCUElPwPsd1gm8L9qSmD59+p49e27fvh0aGiqVSseMGRMXF7dz586Q
kBA2m338+HEvL6+rV6/m5uZq7UgQxOPHj2tqasiU9u3bt23bdteuXe3bt+/Tpw8eu4eHh1+/
fh1nGDJkSKdOnRBCV65cCQwMnD59ekxMTHJyskQiuXHjRgPpeMcJEyasWLFi3759I0aMmD17
NovFunLlyuTJk3k83ogRI9555x18lKCgoLorUGlBp9PpdPrly5fJlA0bNgwePPjTTz91cXEZ
OXLkypUrz507p1are/ToMXfuXCaTefr06WnTpjk4OJAxmzrLefLkSXJy8pQpU9LS0jRzApZG
ly5d2rVrp5mCJUUzF+S2LMw52dJI9u3bN2vWLHNbAZia06dPh4WFmdsKwJCcOHGidevWEydO
rFujxWJx586dW7dufejQoYKCgoKCghMnTixduhS3V4WFhU043OvXrz/66KO2bdvSaDRHR8fg
4OC//vqrgfSYmBgc2aATmUxWVlZG/vvo0aM3vuJBEMTPP/9cUFCgmaJSqY4fPz516lT8OiiD
wcjPz29COQBV2LFjB5/P1+qCG46luH//fpcuXUxpZHOg0loZe/fuzcvL++GHH8xtCGBSTp06
tXv37pMnT5rbEMDAfPDBBwwGo+7nKh49ehQVFaU56Gez2b6+vuHh4YsXLyYnoY1H9+7dk5KS
unXrZuwDkTx//lypVLZv395kRwRMT1VVVZs2baRSqVY6l8utb12KgoKCMWPG3L9/3yQGNhcq
hSNA/IR1QkD8RAvFycnp1atXddM9PDyuXLmSl5dXXFxMp9M9PT29vb1NOddp+qV48SoXQNMQ
i8UKhaIJO6rVanI1UoQQk8kUCAT4d8OrpTUNe3v7sWPHHjt2TOs75njio7FLXVkgVOqeIX7C
OgE90VJp06bNH3/8Ud9WPz8/Pz8/U9pDAkv7N0BVVZVarSZ7YplMhoNaJBKJXC4nM6hUqurq
ap0ZKisrCYIgM6D/CgKpVErGqCoUCrFYjH9r9f34KCY4Xzs7O/ww8Hg8FouFEGKz2XgxU1J/
4IBZe3t7HKLr4ODA4/G4XK5AIHBycnJ2dnZ2dnZycuLxeAsWLDh16hR5UiT1SQpqtX5U0hPg
n7BOIB6zpTJw4MAlS5Zcv37d19fX3Lb8B4o+criLxd22XC6XSCRkH4w31dTUyGQyrU3V1dUq
lUpzE0EQlZWVWps0u/YmQ3bAHA4Hz1sJBAKyVedyuWw2m8PhcDgcss9GCDEYDM3PqWh6DjR3
x9jb2zfz3pG6p7a2Fs9NKJVK/IYzeWWQhqDBYkgikdTU1IhEInzRdJZsa2vr5OSEC69LC/BS
UKl7Bj1hhZSWlhYVFUml0urqasN+ogkwOwMGDPD19S0qKrI0PWFY/wQ5EBeJREqlkhyvC4VC
9G9vhBPJnHgEjzs2rU2aogFv0hq4NwoHBwcajYZH3rgLx523o6Mj7pjrbkII2dracjgchBCf
z8c+Y9zHk3KBzED298aYPrBY8H0RCoX4b3l5eUVFRfm/ZGVl/fPPPzqdKzU1NSNHjvz4449n
zZrVu3dv01veTKjUPYOesELi4+PXrFmD/h12ODo6Ojg4kH81/7Wzs+Pz+Twez8HBAS+wiD2Q
5j4DoF7odHpeXp5ZDk2OtnH3jEei5OhTLBafOXPGzs6ugTy4RydHrnhUqqUV8Mi+aRbinhh3
zGQ/jbt53ItrbcLKQHMT2f1rbtJSBoAxYLPZeJFTnVufPHni5eVVn5dCqVRu27bN0dER9IRx
USgUoCesjcjISKlUmp6ePm3atMrKSqFQKBQK8Y9nz57hf7VWBNLCzs6Ox+Px+Xw7Ozs8wcnh
cHDbildCtLOzw40sHorZ29szmUx7e3uyzcWZNWO1gOaDXevovz5k0ldMTqJrutlxJ400pttx
h63lACBLxqN8XBQ5iNczdm/evHl1E8lnAM+pkz55R0dHOzs77K4nHxssCMilqHCnjv38dDod
K12cBydqioamX1bA4vnrr79sbW116gkejzdw4MCNGzd27NjR9IY1Hyp1zyqVChZssTa8vLz6
9u1bVFT0+eef15entrZWKBRKJJKqqqrq6mqxWCyRSKqrq6uqqiQSiVgsFolEVVVVYrFYLBaX
lZXhkSX+fHYTHMW4LyH7CXK+FncnZDbS5YvRnA9GCNnY2Gi+ia4lVsj+xkjgjvaN6VrDa3Is
3oT85GRzc4bsOmmgw3ZwcMBakLza+GbhW0Oj0RwcHNC/cXaaWiEsLOy3337r0KED+rd317q5
ANBkfvnlFzIQVRMejzdlypS9e/dqxn9APKaxUCqV5CfaAOvhjTXK1ta2TZs2TS4fD2dxP1dd
Xa1UKisrK8m+EI+J8RiXHElrDYs1h7yao22MVqerFZeOh9RNNt4Y1PXEaMW4aXWuZH4c3K6V
n9RVmsXivh9pTMCTektTS9XVaqR6INWAMaDT6d27d2/VqpWRygesFoVCkZ6eXjedw+GEhITE
x8dTSD3UhUp6At4XtU6MrdBZLBaLxbIQJ7OWN15zNG+8OW8YfGsB74sCRuLChQt1Z+1tbGw8
PT2PHj1KaTGBqKUnIB7TOqHoy3tNQ2s5XgtROdaGVT1ygCn56aeftF67xZ62tLQ0Eyz8amyo
VGdAT1gn1JpBBFoA4J8AjIFUKj1x4oTWm6JcLvePP/5wdXU1l1UGBPQEYOnAYBEwMaAnAGNw
4sQJrS6My+UeOnSoV69e5jLJsFCpe4b4CesE/BOAiVGpVCBhAYOzceNGzTekeDzel19+OXbs
2AZ2oVbrR6U6A/4J6wT8E4CJUavV4J8ADEtmZuaDBw/If3k8XkRERExMjBlNMjhUaqZBT1gn
1FLoQAsA5jsAw6JUKqOjo/HaqQghDoczcODA/fv3m9cqgwN6ArB0QE8ApgQvFgKPHGBAdu/e
XVpaih8tW1vbt99++/fff295mpVKegLiJ6wTmO8ATAk4JwCDs379erwGvK2tbbdu3TIyMjQX
z20xUKmZBv+EdQL+CcCUgH4FDEtOTg4WExwOp3fv3pcvX26pXwKiUrUBPWGdQPsOmBK1Wh0Y
GGhuK4CWw+nTp6VSKY/HCwoKunjxYqO+GkGt0RSVmmnQE9YJtWoUQHVsbW11fmEBAJrGiRMn
VCrV559/fvr06RY5zUFCpe4Z4iesE/BPAABAUWpra58+fXry5Mnw8HBz22J0qKQnwD9hnYB/
AgAAivLy5cs///zTw8PD3IaYAioN+0BPWCegJwBTsmTJkr1795rbCqCF0LFjRysREwj0BGD5
wHwHYEqOHz9+5syZ5pSQlZUlEAg8PDyaWQ4AUGs0RaVmGuInrBNq1SiA0sjl8uLiYoVC0ZxC
1q1bx2KxOnToMGbMmCNHjhjKNgCwcKikJ8A/YZ001j9x69Yt4xkDtGzu3r2rUqnEYnEDeSIi
IsaPH99Ahnv37m3YsCEjI2Pbtm0zZ878/fffDW0mAFgioCcAS6dR/onTp0+HhYUZ1R6gBfPs
2TOEkJOTU8PZUlJSGnA8lJSUeHt7I4Q+/vjjHTt2TJ48+fr164a1EwAsENATgKWjv39iz549
Y8eOValUxjYJaKngdQxdXV0byJOUlJSYmGhnZ1dfBrlczmKx8O8PP/xw+PDhSUlJhrUTACwQ
KnXPED9hnejjnyAIYunSpbt37yYIIjQ01DSGAZZMVlZWenq6m5tbZGQkm81+YzqmtrYWITR0
6NAGSqbT6TNmzGggA5PJxF9+wqxdu9be3r4p5wAAlAL8E4Cl80Y9IZfL33vvvd27d0skEg6H
s2jRIpPZBpiR/Px8PO7fvHkzg8FITk4mNy1evHjAgAFbtmyJjo4eOXJkw+m7d++2sbHh8Xj7
9+/HeqLhpYcIgvj77791GnDu3DkajaZUKvft23f27Fkc2unr6+vh4fHbb7+1adOGRqPR6fRB
gwZdunTJCJcEaGlQLBqdoA6tW7d+8eKFua0ATM3GjRuXLVtW31axWDxgwAAul4sQYjAYYWFh
prQNMCM7d+708vLKycnBbktPT0+cvm3bNiaTmZCQQBDEnj17EEIlJSX1pe/btw8h1LVr14iI
iJiYmGnTpiGE5HJ5A8d9/PixjY2NVCqta8CrV6+ioqI0P09qa2s7duzYmTNnIoRYLNb69esP
HDgQGhrKYDAOHjxo/IsEUJvbt2/36NHD3FboC5WG++CfsE6I+hW6SCQKDg6+c+cOHlay2eyN
Gzea1jrAbCiVytevX48aNWr48OHvvfferFmzSkpK+Hz+F198YWtrm5qamp2dfezYsfbt27u6
ugqFQp3pO3bsCA8PP378OIvFunnzZt++fRFCGRkZ77zzTn3HFQgECoXi2bNndQ2QSqU//fTT
jRs3Ro4c+eWXX966dSszM/P169d37txhMpmXLl0aMGAAQmj69Onr1q375JNPJk+eDN9GB1oM
VJrvgPgJ66S+eMyqqqrAwEBSTNBotL59+/bq1cvkBgLmQSgUCoVCPp9/7Ngx3DG/fPny8OHD
LBYrKSmpsLAwPj6+Y8eOZ8+etbGxqS+9pKQkKiqKxWKVlZVFREQEBwePHTs2JSWlgeM6ODgw
mczMzEydBiCEuFwug8EQCASDBg1atmzZpk2bunTp0rFjRywmMDU1NUqlEmKHgZYElYb74J+w
TnT6J6RSaVBQ0P3792UyGU7h8XgrV640uXWA2SgrK0MI7dmzB892dejQ4c6dO/n5+d26dQsN
DdUKy60v3cnJ6dtvv/3rr78OHTrE4/EOHjyYk5Pz/vvvb9y4USAQ6DwujUZzcXF58eKFTgP8
/PxcXFweP36suUtgYODWrVtXrFgxdOjQ169fJyQkpKWlHTp0iHwNBABaAFTyT4CesE7q6gm1
Wj1x4sQHDx6QYgIh5OrqGhISYnLrALPB4/FGjBhBTkwEBQVlZmZ6eXldvXo1NzdXK3N96d98
801BQcG2bdsGDhx49epVV1fX0aNHjxs3rqSkpIFDDxkypFOnTjoNQAj169cvLy9PM/+ECRNW
rFixb9++ESNGzJ49m8ViXblyZfLkyc06W+y0AAAgAElEQVQ5fcAaaGC21wKhUvcMesI6qTvf
sXLlykuXLtXU1JApAoFgzZo1FKp4QPPZsGFDRUUF+e/KlStv3LgRGhq6ffv2UaNGbd26FQdD
3Lt3LzMz88yZM2q12t/f/9ChQ5rply9ffuutt06cONG5c2dczvXr1yUSSbdu3Ro4NF7Maty4
cXUNQAhFRUXxeDzN/DQa7Ztvvvnmm28MdvIAYHlQpntWqVR0Oh06DCtES6Hn5OR8//33mmIC
55k4caLJTQPMCYvFcnNzI/91d3d3d3dHCKWlpUVFReE3NTBsNtvX1zcqKio/P79u+uTJk9u0
aUMm1tbWlpaWNseAdu3affbZZ804MwCgJJTRExCMabVo6gmZTDZ16lSpVKqZgcFgRERE1F2b
CLBOPDw8rly5kpeXV1xcTKfTPT09vb29ydajvnQS+J4tADQNyugJmOywWtRqNW70CYL44IMP
ysrKCI3FBxFCXC73ww8/NJN1gIXi5+fn5+enfzoJNDVUpKqqSq1WN5BBrVZXVVUhhGg0moOD
A0KIw+HY2tqayD7rgDLVBiq51YL9EyqV6v333z9x4oTWTAdCiE6nDxw40Cy2AS0PaGpMiUQi
EYlEYrG4qqqqurpaLBbjf4VCIf4hFourq6ulUmltba1cLpdIJEqlUiQSkfpAKBQ20wYHBwca
jcZms/F7OnZ2dgwGw8bGhs/n4618Pp/P5/N4PEdHR/6/2Nvb29nZ4XQ7Ozt7e3twa1Gm2kAl
t1rUarVMJhs6dCgOlNPaSqPRwsLCILAGMBQqlQrWmGoaSqWyqqqqqqpKKBRWVlZW/Qv5m/xB
ZmhgBQ7sSBAIBHw+n8Ph4P6ey+UKBAI6nY4/ieLo6IgQIvtyPp+v57R4dXW1SqVSKBT42/Ri
sVihUKhUqurqaoRQTU2NTCYjCKKysvLFixdisbiyslIkEimVygbK5HK5WGo4Ojra2dk5OTk5
OTk5Ozs71cHZ2VlP1wi832EUIH7COikqKsrPz//jjz8UCoVCoaibQSAQwHt3gAGBoQtGJpNh
twH2E1RXV2uqAZ0qAffNOrG3t7e3t3dwcLC3t2/Tps3bb7+NU+zs7LADAOsGnIJ/Y/eARUFe
E+xKwd6UyspK8b+Qv4VC4b179yoqKioqKjRfayfhcrk6dQb+0bNnTy8vL9OfYDOhTLWBSm6d
JCQknDhxooEM1dXV06dPx+sC4cEKk8nEKxHZ2tpyOBykMWrBjk0Gg4E/Nk16OHk8Hi4BD3TI
0c8bMwAtj5bR1OCxNZ4gwKPt6upqhUJRVVVVU1Oj2flJJBLc/5G/cbpO+Y5hsVhYGWCJ0K5d
O/t/0Uwnf+CK2QJgs9lsNtvZ2blRe0kkkgoNysvLK/5LQUEB/oGX+kUIrVq1avXq1YY/ASND
mWrTMio50FhmzJiRmZl56dKl+jyNTCazX79+vXv3xnEVEolELpejf+Oz8CSrUCjEDSv615OJ
/nV4NtM8FouFVxrgcrn4BRM8+UrGfJE/EEKaKoQUPQghcqYWaSgYpKGHNMtHGuIGISQQCMh6
gQ+Nf2Pl1Myzs05MM9+Bn0/SwV5bW4vfWsJOdawGEELkc4sfbJ0qQalU1k3U59nGD6G9vT0Z
E9C+fXscEICd9vgHn8/H8w6kSiAfS0AfeDwej8fr0KHDG3NKpVKsNlq1amUCwwwOZXpo0BPW
iYeHh6+vb9euXRMTE3V6U5VKZUFBQXp6etO6T7LhJmdSceQX+ldwNJCBnE/FEWE4TAxp9A14
kFdRUUHGjiGEyC5Es0yjQo4ONQUN6aQh0SlB6mbDaOoeTTS1jiY6o9XM5eZpYPBdWVl59+7d
+/fvx8TEII17jdG8dxitnlsmk2nGC5MPD/lsaBXYBPAdwdcfX217e/tWrVrVTWQymfb29lqJ
NjY2OHiQx+PB2w2WBofDad++ffv27c1tSBOhTA8N8RNWi1qtdnd3P3PmTFhYmM7et7q6OiMj
Y+jQoU0onEajkd1t69atm2Vo8yBHokhDkaD/9kCk9wX9t1PU7NU0X5wjQ9/Jjg39t1Mk+zlN
NNUPQuj169f4R33qp74+8o3xaxYLjUbbu3evZoqm7wf913WENIQR9oej/wYGkr4lLKpIiUYW
gp1MpCuLdHqR4gxLPU0/FmAlQDymUQD/hNWCa1RgYGB9kkIsFm/evLlpesJyYLFYVvJ1KJ0v
+NVVNvW5OoyB5nTSgQMH0tLSEhMTTXNoAGgxUKaHBj1htZDrFQYGBqampo4aNaruYtvp6elC
obDFhH21bOq7TS4uLia2RCfQ1ABA06DM+htQya0WTY9fcHDwuXPn6np9mUxmcnKyyU0DWiCw
/gQANA3K6AmFQgF6wjrRmkHEEx9akkIsFv/4448mNw1ogcDQBQCaBmX0hFKphHhM66Tu95l0
Soq///77xYsXpjUNaIGAngCApkElPQGV3DrRGeGMYylwGDyGTqcnJSWZ1jSgBQLzHYDlQK33
O0BPAJZOfTUqODj45MmT5CoINTU1MOUBNB9oagCgaVBGT0D8hNXSwHhRKzzz/v37paWlJjQN
aIGAfwIAmgZl9ATET1gtdeMnNNGMpaDRaEePHjWhaUALBPwTANA0qKQnoJJbJ28cL5KxFFKp
dP/+/SYzDGiRQFMDAE0D9ARg6TTsn8DgWAoOh5Ofn3/x4kXTGAa0SGC+A7Ac9Gn9LAfKGArx
E1aLSqXSp0YFBwefP3+ezWZ/+umnzf9wKGC1gJ4ALAfQE0YB4iesFrVarWf7HhgYePbs2cLC
wp9++snYVgEtFXCFApYD6AmjAJXcamlUjcJeig0bNmh+IRMA9Af8E4DlQK2nEfSEBbFkyRKt
ryQDqPE1KjAwMCEhYceOHcYzCWjBWENTA1AF8E8YBWuInzh+/PiZM2fMbYXF0YQaFRgY+M47
7zx//txIJgEtGNATgOUAesIoNC1+4vbt22VlZcawx+DI5fLi4mKFQmFuQyyOptWofv36Wcj3
rwFqQS0PM9CyAT1hFJowaDh9+vTQoUNbtWplJJMMy927d1UqlVgsRghFRESMHz/e3BZZCk1u
36FXAJoA+CcAywH0hFFobCWPi4sbM2aMi4sLVd4KefbsGULIyckJ/5uSknLkyBFDFV5WVpaQ
kGCo0kwMtWoUQHWUSiUoUcBCoJa3jDLNtP7xEyqV6sMPP/ziiy8QQiEhIUa2y2BIJBKEkKur
K0IoKSkpMTHRzs7OUIVnZWXNnj1bqVQaqkBTQq0aBVAdlUoF/gnAQqDWaIoy1UalUunjaaip
qQkPD8/JyampqeHxeDNnzjSBbVqUl5dv2rTp6dOnPj4+0dHRjo6OOD0rKys9Pd3NzS0yMpLN
ZmvtVVtbixAaOnQoQohOp8+YMaMJpeXn56ekpPD5/Dlz5pAf3sQolUqhUEjFkAJq1SiA6sB8
B2A5UKz1IyjC8uXL169f33AekUjk7+/P4XAQQgwG45133jGNbZooFIqAgADy8nbo0CE7O5sg
iEWLFiGEnJ2dEUJBQUE4865du5hMJpfL3bdvX3x8PEJIJBIRBKFWq2/evNnY0k6ePEkKi+Dg
YNIkkUgUGxuLEBo8eLCXlxd+OpOTk016XZrBiBEjzp07Z24rAGth8uTJR44cMbcVAEAQBHHq
1Knw8HBzW6EvlBE+bxw0VFVVBQYG3r59WyqVIoRYLNbu3btNZd3/cfbs2WvXrm3evFmlUlVU
VEycOHHevHnbt2+Pi4tLSEh4/fr1nj17Ll269PTp0/3793/88cceHh5hYWEPHjzAX53AgqCk
pMTf37+2tlb/0vLy8iZOnNi7d+/MzMxNmzZlZGQUFxdv27atbdu29vb2S5cuRQgVFBT4+fnF
xcVdu3ZtzJgxpr84TQPmOwBTAv4JwHKgln+CMtVGoVA0MN8hkUgGDx5cUFAgk8kQQjY2NtOm
TfPw8DChgf+fP//8083N7bPPPqPT6Y6Ojlu2bBEKhW+99ZatrW1qamp2dvaxY8fat2/v6uq6
Y8eO8PDw48ePs1ismzdv9u3bFyGUkZHxzjvvCAQChULx7Nkz/UtbtmwZj8c7ffq0s7Nz//79
a2pq3Nzcbty4UVlZ+e677zo6Ou7bty81NdXf39/016SZUKtGAVQH9ARgOVBrNEWZZrqBSq5S
qd59990HDx5gMYEQYjKZy5cvN6F1/0dFRQWPx9Ps/w4fPsxisZKSkgoLC+Pj4zt27Hj27Fkb
G5uSkpKoqCgWi1VWVhYREREcHDx27NiUlBSEkIODA5PJzMzM1L+04uJif39/PAPCZDJXrlxp
a2v7ww8/vHr1Kjk5ef369QghgiBMfj0MALVqFEB14HkDLAdqjaYoY2gDemLWrFnXrl3D8YwY
f39/szgnEEJisVitVmum5Ofnd+vWLTQ0NC8vTyaTZWdnd+/eHSHk5OT07bffLlq0yNfXl0aj
HTx48MMPPzx8+LBIJKLRaC4uLi9evNC/tD59+pw/f37Hjh2a14HFYvF4PIQQflXkzp07JrgC
BodaNQqgOuCfACwHarV+lDG0vkq+b9++3377Db9sibGzs/vkk09MaNp/IAji8ePHNTU1ZIqX
l9fVq1dzc3O1cn7zzTcFBQXbtm0bOHDg1atXXV1dR48ePW7cuJKSEoTQkCFDOnXqpH9pGzZs
GDx48Keffuri4jJy5MiVK1eeO3eO1CJ0Op1Op1++fNko52xkqFWjAKoD/gnAcqBW60cZGa4z
fuLWrVv/+9//NMUEQkipVJox2HDWrFlisVjzXc05c+Zs37591KhRW7duxUES9+7dy8zMvHz5
8ltvvXXixInOnTuTmckPbePFrJycnPQvrbq6esuWLTk5OVlZWefPn2cwGH///Tf2XrBYrP37
9w8cONAk18DAQPsOmBLwTwCWA+gJo1C3kovF4tGjR2uO3RFCdDr93XfftbW1Na11/8ewYcOG
DRummcLj8dLS0qKioqZNm0YmstlsX1/fyZMnt2nTxlClTZ06dd68eQsXLkQIPX/+XKlUtm/f
nsxjlqU4DAK1ahRAdUBPAJYDtUZTlKk2WpWcIIiJEye+evVKK8ZQIBCQK0FZDh4eHleuXMnL
yysuLqbT6Z6ent7e3k1eCFyf0tzc3AxhuEVArRoFUB143gDLgVqjKUrqCbVaHR0dnZmZqRl7
iJHL5RayxrZQKJRIJDU1NV5eXjQaDSFUWlqqVqvVanV2dva1a9eio6NxsxUbG1tRUYEQUiqV
IpFox44dWBx88sknmp8bfWP6ggUL1Go1n8/H6WvXrmWxWAihLVu2KJVKBwcHnP7BBx/g/L/9
9ptKpbKzs2MwGDwer1+/ftieFy9esFgsNputtcKmuaBWjQKoDvgnAMuBWq0fZaoNGT9RU1MT
GRmZlpamFTaBGT58OO5EDU5tbW15eXl5eXnPnj2xPvjmm29evXqFE6urq9PT0/FqVM7Ozlgf
YCQSCe6Yp06dqjk7ExkZiV++WLNmDV4dHFseFxdH9ve2trb4WEhjxfGLFy9qCikyPSkpCb8x
q1AoxGLx6tWrcYYvvvhCM//777+P80dGRmqmS6VSrCc6d+6M1wRDCDGZTJFIhOePevbsiU8Q
r/lNLsf56aefslgsGxsbBwcHDofz8ccf4/IzMjIEAgGXy+VwOPb29g4ODuS5NApq1SiA6oB/
ArAcqNX6UUZPKJVKqVSak5MzadKkly9faoVNYOzs7CIjI5tzFJlM9ujRo6KiotLS0pkzZ+L+
sn///g8ePBAKhThPeXk5/gro1q1blUqli4uLg4ODvb29XC7H+RcsWECn07lcrkAgsLe3J8c6
V69epdFoAoEAIcRiscjRv05hhP794mhd/vnnH53pZWVlbyxHKBSSa3L/9ddf+AthIpFIqVSS
6XFxcTU1NbW1tXK5XCKRkPqse/fuSqWyqqoKIVRZWUmeV1JSklwux4UghMiXa9555x3NL5CR
X3Tz9PRkMpl8Pt/Ozo7D4Zw4cQI33ytWrMApHA7H0dExIiICVyRo3wFTAv4JwHIAPWEUlErl
yZMnDx482MCiTLW1tQMGDNCzwNra2ocPHz58+HDEiBG4a+/bt++NGzfIdyyHDx/u7u6OEPL1
9e3fv7+bm5urq6uzszOpA16+fKlzwL1q1SqdR/Tx8dHTNsNCfkJM63fv3r115v/www91ptf3
/fTnz5/jH9gvgvt+giDOnTsnlUpramoqKytlMhluo9VqdUhISGVlZU1NjVQqff36Nc6vVCo3
bdpE6g8Gg0H+plaNAqgO6AnAcqDWaIoy1UapVA4cOJDFYiUkJKhUKp15GAzG4cOHY2JiNBNV
KtWLFy+eP3/epUsXHFsQFRV14cKFp0+fYmmSm5vr5+eHEBo7duy4ceM8PT07d+7coUMHMqSx
vu+ANM1734KxsbEh9QqNRtMZyEKn0/fu3Vs3nclkKhQKrEiqq6vJpU4R1WoUQHXgeQMsB2qN
piijJxQKRY8ePebNm/fBBx+EhYWJxeK6eaRS6fLly99+++1x48YhhCIiIi5evFhVVYVdDn/8
8Qd+97J169bDhg3z/Be8QgNCaOXKlSY8IUAHWJFoOlEQ1WoUQHXAPwFYDtRq/ShTbchKHhgY
eObMmfokBZvNlsvl+HdQUFDr1q1dXV3d3Nzatm3bs2dPnI4/3g1QBWrVKIDqKJVK8E8AFgK1
Wj/q6QnUoKSQy+WHDh167733EEILFiwwtZWAEQD/M2BKVCoV+CcAC0GlUlFIT1DGUC0nZGBg
YGpqKn7fUhOCIM6ePVteXm5a6wAjQi2FDlAdmO8ALAe1Wk2h0RRlmum63+8IDg4+efJkXUnB
YDCOHj1qQtMA4wL+CcCUwPMGWA7UGk1RxlCdg4bg4OCzZ8+SK0JiJBJJfHy8CU0DjAu1ahRA
dcA/AVgO1Gr9KGNofZUcx1JoSYp79+6VlpaayjTAuFCrRgFUB/QEYDlQq/WjjKENVHKdkqK+
xZcAygH+Z8CUwPMGWA4Qj2kU6sZPaILDM8mVK6VS6b59+0xlGmBcqKXQAaoD/gnAcoB4TKPw
xkoeHBx87tw50ktRXFz8+PFjk5gGGBcYLwKmBJ43wHKg1miKMobqM2jQnPggCCIpKckkpgHG
hVo1CqA6oCcAy4FarR9lDNXTCUlKitra2p9++skEhgHGhlo1CqA0BEHs378fPs0DWAjUav0o
Y2jD8ROa4FgKW1vbO3fuZGVlGdswwNjAeBEwGTQaLSoqytxWAMD/B/SEUWhUkFRwcHBaWhqb
zZ4zZw75/XGAolCrRgEAABgKarV+lDG0sUHXgYGBZ8+effDgwYEDB4xnFWACwD8BAIB1AnrC
8GAfQ2Mva3Bw8Pnz59etW1dVVWUcuwBTYMYatXLlyk2bNpnl0AAAAKAnDE+T3wgPDAz8+eef
t23bZnCTANNg3upUXV19584dcx0dAAArh1reWWos26J/MGZdAgMDbWxsnj171rZtW8NaBZgA
s8tziURixqMDTWPJkiVeXl5z5swxtyEA0CzM3gA2CmoY2swV6/r379+6dWsD2gOYDPPKc6VS
qVQqzXV0oMkcP378zJkz5rYCAFBxcXFzdgc9YXiavwIuLKBLUcxbnWpqasx1aKDJyOXy4uJi
hUJhbkMAAKWkpFy4cKHJu4OeMDywor7VYt7P4UilUhaL9cZsERER48ePN/jRjVSskbAca+/e
vatSqcRicWN3tJxTAFoMU6ZMmTBhQkZGRtN2Bz1heJoTPwFQGvN+DqempsbJyUmfnCkpKcb4
pO0biy0rK0tISDD4cd+IzuMa6SI0lmfPniGE9LxxWljsBQcoipub26BBg0aMGNE0L4VSqaRQ
PCY19AT4J6wW88pzGo3WqlWrN2ZLSkpKTEy0s7PTp0yRSPTrr78uWbLkjSuj6FNsVlbW7Nmz
TR/kUfe4jboIRgWH0Lq6ujZ2R0u+4AB1+eyzz5RK5ZgxY5rgpVAoFPq4SC0EanTSoCesFpPF
Y+bn56ekpPD5/Dlz5pAfvheLxW3atHnjvnQ6fcaMGW/MVlhYuGXLlsTERJFIhBDq1KlTw3vp
WaxSqRQKhS4uLlrpWVlZ6enpbm5ukZGRbDYbIVReXr5p06anT5/6+PhER0c7Ojq+sXCdl0Xn
cfW0trHUPYs3UltbixAaOnRoY4/VzAsOADoZPny4m5tbWVnZqFGjUlNTQ0JC9N+XYr55ggrc
uXPH29vb3FYAZuDly5cuLi7GPsrJkyfJvio4OJhMHzRo0G+//YZ/19bWzps3D+vaHj16VFRU
kNnUavXNmzc1CywtLX358iVBEE+ePImPj8eJ4eHhCCF/f/+cnBy5XP5Gq8hib9++ffToUYIg
vvvuOzqdfuzYMZxBJBLFxsYihAYPHuzl5YUdOcnJyQRBLFq0CCHk7OyMEAoKCiIIQqFQBAQE
kBW/Q4cO2dnZDZxUA5dF53GPHTtGXoTk5GQ3NzeEEI1GGzhwYEZGRgNn0QB1z6K+Qnbt2sVk
Mrlc7r59++Lj4xFCIpEIb7py5Yqvr6+9vX1MTMzTp08bsLA5FxwAGmD9+vVYjnO53PT0dP13
nDp16qFDh4xnmGGhhp64detWz549zW0FYAaeP3/u6upq1EPk5uba2tr269cvMzMTr4ZZVFSE
N3Xt2vXMmTMEQSgUitGjR3t7eycnJz948GDkyJE+Pj5qtRpne/z4sY2NjVQq/eOPP7766iuJ
RGJvbz906FCFQtG3b1+E0KVLlwiCSEpKsrGxcXZ2TkxMVKlUbzSMLHbnzp1eXl45OTl4pOLp
6RkXF9emTRtyJsjV1XXKlCnbt2+/du2aXC7ftm0bk8lMSEggCGLPnj0IoZKSktTUVITQ5s2b
VSpVRUXFwoULe/fu3cBJ6bwsDRz34cOH2Novv/wSIcRisdavX3/gwIHQ0FAGg3Hw4MG6Z9Hw
6es8C52F7Nu3DyHUtWvXiIiImJiYadOmIYSwYquoqLC3t0cI+fj4+Pn5ubq6Pnr0qD4Lm3zB
m/LYAdbEq1evbG1t8cPTKEkxceLEpKQko9pmQKihJ65fv96nTx9zWwGYgdLS0rZt2xr1ENOm
TXN2dn79+jVBEAqFYs2aNVKpFG/y8PA4ceIEQRA7duywt7d/8uQJzoPXRvv9999xtoqKCoTQ
o0ePDhw44OPjs2rVKoRQ7969Fy5cyGazeTze6tWrcc7c3NygoCCEUK9evZKTk8nOWydksXFx
cY6Ojq1btw4LC9u/fz9CaNiwYRwOZ8KECdHR0Qih7Oxszb0EAgGfz584ceL8+fNdXV3bt28v
l8uXL1/u5uamqWMaPimdlyUqKqqB42JrscPj2rVr5Ka1a9c6Ojpu2bJF6yzwoes7d51nUfdS
PHnypE+fPuHh4TKZjCCIGzdu4Amy8+fPEwTx008/IYRatWpVXl4ukUh8fX2HDRtWn4WvXr1q
wgUHAH0YNWoUjUZrrKQYN25cSkqKsW0zFNTQE9nZ2f7+/ua2AjADJSUl7du3N+ohBg4cGBoa
qnOTp6fnzz//TBDEpEmToqOjceKyZctsbW09PDy8vb1xH6ZWq/FI+sCBA3Q6ncFgvP322ywW
i8FgJCUlae6LuXHjxqhRo/AkQmVlZX2GkcWuXr0aIeTu7i6RSCQSCYPB+PPPP8ViMUEQL168
QAhlZWWRe+3cudPZ2fnMmTO+vr4sFsvf3z8/P58giLlz53p4eGiW3/BJ6bwsMpmsvuOS1n72
2Wfu7u6ae8XExAgEghUrVmidRW5ubn3nXt9Z1L0Uubm5rVq1wtMTz549c3d3HzZs2NixYz/+
+GOCIL766iuEUL9+/XCx27Zts7e3r8/C2traJlxwANCH8+fPa4b6crncixcvvnGv8PDwU6dO
Gd86w0CN9zsoFpMCGA4TxGP26dPn/PnzO3bswHF8mtjZ2T18+BAh5OHh8euvvy5cuHDw4MGx
sbE//vhjSkrK48ePR48eLRKJaDSai4sL7mnUavWkSZMmTZokl8v/97//TZw40cPD48GDB3jT
1KlT8/LyfHx8Tp48eeHCheLi4o8++qg+w8hiy8rKEEJ79uzhcrlcLrdDhw4PHz7k8XjYQoSQ
5kdG8vPzu3XrFhoampeXJ5PJsrOzu3fvjhASi8X4u3okDZ+UzsvCYrHqOy5pbWBgYGFh4YoV
K9LS0g4fPhwaGhobGxsfH19eXq51Fg18G6W+s6h7Ke7cuePk5PTtt98uWrTI19eXRqMdPHjw
ww8/PHz4sEgkevbsmYODQ3Z2dkxMTEZGxpEjR1xcXOqzkM1mN+GCA4A+hISEEARB/ltTUzNq
1Kg3vkRKsb7P3IJGLy5dujRkyBBzWwGYgcLCws6dOxv1ENXV1XgOgs/njxgx4quvvjp79iye
F1i9ejV2jFVUVAQFBdFotM6dO2NHOkEQqampXC53+vTpBEFMnjz56NGjFy9ebNu2rVAojI+P
79OnT21tLUEQV65c4fP5BEGoVKp27drZ2tpGRkYuW7Zs/vz5Li4uXbt2bcA2XOznn38+YsQI
MnHmzJlz5szBv2UyGZ1O/+CDD8itW7ZsodPpOTk5WkVNmzaNTqdLJBIypeGTauCy6Dwuaa1a
rV6xYgVe4Z7L5Y4ZM+bq1asEQTRwFnWp7yx0FpKUlCQQCJhM5oQJE54/f443RUVF/fPPP9On
T58xY0ZcXByfz6fRaEOHDr19+3Z9FjbtggOAnrz//vtab7+/ceJj6NChFy5cMJmFzYQaeiI9
PR2LO8DaePjwoZaX3hioVKrjx49PnTrV3d0dIcRgMLB33eC8fv36o48+atu2LY1Gc3R0DA4O
/uuvv964l0wmKysrI/999OiR5ssRP//8c0FBAfmvWCzu3Llz69atDx06VFBQUFBQcOLEiaVL
l+L2q7CwUH9rG74sWsdt5lloUd9Z+Pr6tmrVijyLhgshCCIyMnLWrFn6G6mPqY09cQDAaE15
kJKigYmPwMDAK1eumNDGZkENPTXNPWsAACAASURBVHHu3DnN4QJgPdy/f79Lly6mPGJZWVlJ
SYkpj2hwHj58GBgYqNlmsdnsgICAdevWkaGmjcX0l8UgZxEVFaUVvNIw586dGz16dJPsBYA3
IJfLtRZxeaOXon///voMOSwEaiwSRbE5JMBwmH59TLwsAaXx8PC4cuVKXl5ecXExnU739PT0
9vZuZg0y/WUxyFk4OTnhtzb0RCqVNjNeRywWG/VTZDiAt246l8utu96XjY0Nn883njFAo7Cx
sRkxYkRKSopWek1NzZgxY06dOhUcHKy1iVp9HzX0BKyPabWY93vllMbPz8/Pz8/cVjQX8izk
cjn+xFdNTY1MJkMIVVdXq1QqhJBQKEQIKZVKvPBobW2tVCpFCInF4nv37t24cWPFihVqtVqt
VldVVeGi8JrcWr8RQi9fviwpKcGrhmC09IFWfoIgKisrjXf6xoBGozk4ONRNxzEoWokcDodc
OIFEp0zRFDT29vZ4GMBgMEgPv62tLYfD0TqWpjFktC9CiMfjketMOzg44DctmUymQCBowDDL
Z/bs2enp6fhB1QSHZ9aVFAqFgkJ9HzUMBT1htVDr83oAQqi6uloul1dXV+N+XSqV4h9af7Es
qO+vRCLBPTf5tzkmbdiwgezM+Hw+HvCRvRQGd2AEQbBYLEdHR82+DaO1PDlZDqZufgydTscL
apkSnT4MnY4TfMG1ElUqVXV1tZ7FkncHqzqRSIQ/bqKptLREmMGxs7PDow7Nq81ms/HkAilZ
yBScn9Q6pBLCjwR5K/EtJsskHyGsljTFjf6Eh4fz+fy6egL9Kym0FuRWKpXgnzAwWE8UFRW9
evWKwWCQ6hiLXE0JDLQwQE+YADxwx12LSCRSKBSVlZW4D8CdkFAoVCgUYrEYdx6VlZUKhUIk
EuG+v6qqSqFQVFdXY6Gg/3HxEFPrL5fLbdWqFW76tf6if1t8ssqTTT+ZAXcVZBdCp9NDQkJW
rFgRERGhj0mHDh06derUwYMHm3AZAX3QVIekQCF9SwghzaeIdEGRviX0Xw2kKZKwoEEI4WcV
/ya9WSKRSCgUklKJPEp980f6Q7pSsOIkVYtW90Q6VLp06fL69Wudk2I1NTXh4eFff/31+PHj
PTw8EMx3GAN8TRMSEtasWdNANnxfyaaEvH9atxmrS7IlwnedFJu4EFKTku0ULoSUqFqDG8BI
wHyHTjSH+LiBxg0rHh3W7e/lcrlIJMJ7afkPyAHlG8E1iM/ns1gsBwcHXINcXFzc3d0dHR2x
ysfVx8HBwcbGRiAQ1JUL+K8pndV5eXn6Z4bnzdjweDzSkaPPF+lMAylBcD0inSvk3BlWNqTu
IWUKFjGkAwbXJlL94Br3+vXrqqoqtVqNj4J/1GeJTCZbsmSJWCzGi6qBnjA82D8xY8aMwMBA
fCPJ+60lM0npim8/+ZRoiVPcBGtq3qahubyPpuOkrk9V0x1Kzh1qelY0Zx/JakZqIKTh09P0
s5HSuL45UapDLf9E3Sl8srfG7Q75QJLPLX5Q8ZOJ/+JCcE7cTuGnWnO+QH+T8KOo2d/b2dmR
/T1+6uzt7W1sbOzs7HA3b2dnx2Kx7OzscN8vEAhYLJbpnfZmAaZWrRNcR5BJJM6RI0fmzp2r
c0aJTqfzeLxt27bhpV8Q6AljgCu5h4cHdgEZHLJxx40+KUqwqNTSnmSfgZUsKUq0FCtu9zVF
jGYepOGdMziacU9kYJRWCJXOAaKmfCHRGXulc46pPk3THF9OUVFReXn53r179cxfX3er6VBF
usLotNyepKMVozWFTz4wpLu1+V5T7BLDFxZLRnzlyUE/j8fDN0hziK85HYCzafkPmmOSFQJ6
AjA2Bw4c0CkmWCyWi4tLRkaGp6cnmQjxmIbH2NcUt87ITP43zelAshvT7P/IzkyzF9TsOLHu
Qf+dOCS7Ok03jM4Zbp3KhixTE52+8eaHy72RuXPnGqoozbhx9F/thepE1ZGyCTtptQQTflpI
vUVKNK0p/Lpz/FjkkXNqOmUcYBZgvgMwKjKZ7OLFi3XTORxO9+7dz58/r9UHQTym4aHWNW0s
bDa77kwH1dEpXLSCyfUJkM7Kylq9evWZM2eabInOt+AAQCfgnwCMSlpaGovF0vKh8ni8ESNG
HD58uO4KIjDfYXigklMO0uXTTLA7ocXILMDCUSqV4J8AjEfdyQ4ejzdhwoSff/5ZZ6AYtfQE
NSLdQE9YLXDrAVOiUqngeQOMRE1NTWpqqmagFY/Hi4yMTEhIqC/qHPSE4aHWNQUMCMxnA6YE
9CtgPE6cOKG1BlpAQMCePXvqC1fHEWwUesGNGoZCJbda4NYDpgT0K2A8vv/+e83JDiaTuXPn
zgbefaNc60cNPQGV3GqBWw+YEsq14ABVyMrKys/PJ//lcrnjxo3r0qVLA7tQzjFPDT1BucsK
GArQE4ApgecNMAZVVVXjxo0jX+uwtbX18vLav39/w3tRruOjhp6AQYPVArceMCXwvAHGIC4u
rrq6GkdicjicHj16ZGZmvnHJedATRgEqudUC40XAlMDzBhiD+Ph47Jzgcrm+vr6XLl2qu+hw
XUBPGAXQE1YLtO+AKYGmBjA4d+/exWsQ83i8sLCwCxcu6LkeLuWeRmrYSjmZBhgKytUogNJE
RUXVXaMQAJrDmTNnFAoFl8udN29ebGys/h8zolzHR42WGjoVqwX8E4Ap6dGjh7lNAFoaR48e
VSgUW7ZsmT9/fqN2BD1hFEBPWC1w6wEAoC41NTUPHz48depUWFhYY/cFPWEUqPXNVsCAgH8C
AADq8uDBgz/++MPHx6cJ+1Ku46NMPCa1ZBpgKEBPtFQuXbrk7Oz81ltvPXr0yNy2AICx6N27
d9PEBKJgx0cZPUEtmQYYCrj19ZGVlSUQCDw8PJrzMXcz8vHHH1dUVDx58uSXX34xty0AYIlQ
br4D9ARg0YB/oj7WrVvHYrE6dOgwZsyYI0eOmNucxiEWi+/cuRMYGIgQcnV1Nbc5AGCJyOVy
FotlbisaATU66SZPIxUUFCgUiu7duxvcJMA0gJ7QJCIiQq1WHz9+HCF07969DRs2zJkzZ9eu
XTNnzuRwOImJieRWIx3UUJSXlyOEioqK7OzsZsyYYcCSAaDFUFtb+8Y1NC0KyvgnmuD2OXXq
VGBgYKdOnYxgEWAiwDWlRUpKCvZGlJSUeHt7I4Q+/vjjHTt2TJ48+fr16+TWJlNWVpaQkFDf
QQ0FXni4tLT0008/5fF4BizZZOi8UABgQEBPGIXGdioEQXz99ddjxox5++23KdpaARhz+SdE
ItGvv/66ZMmSAwcOGKrMO3funD59ujklJCUlJSYm2tnZof/6Qj/88MPhw4dPmjSJ3NpksrKy
Zs+erVQqdR7UUDg4OCCEWrdu/fnnnxuwWD0xyM2te6EAwLBQTk9QY+TXKD0hlUqnTJly4cIF
NpsdGRlpVMMAY2N6/0RhYeGWLVsSExNFIhFCqFOnTloO+aysrPT0dDc3t8jISLyWYnl5+aZN
m54+ferj4xMdHe3o6Kiz5EWLFt28ebOsrIxMSU1N/eCDD8rKyrD7TZ+SSWOYTCYe5WPWrl1r
b2/v4eFBpuTn56ekpPD5/Dlz5ui5vi9GqVQKhUIXFxf8L51ON/iUxK1btxBCo0aNcnJyatSO
TT4pTBNubgNoXSgAMCyU0xOIoAIBAQF//vmnPjlFIpG/vz+Hw0EI2draPnv2zNi2AUZl5cqV
a9asMUbJhw8fdnBw0HxCdu7cWVRUFB4ejhDy9/fPycmRy+Vaey1atAgh5OzsjBAKCgoiCEKh
UAQEBJAVqkOHDtnZ2TqPuGDBAjqdLpPJyJQhQ4YMHjxY/5KzsrJu3rx59uxZnBIdHX3mzJmi
oiJsp1qtvnnzJi7t5MmTZHcYHBxMHrG2tnbevHlYovXo0aOiokLTQpFIFBsbixAaPHiwl5cX
nU5HCB07dowsNjk52c3NDSFEo9EGDhyYkZFBEMTt27ePHj1KEMR3331Hp9OPHTvW8JVXq9X9
+/dHCHl6eiqVyoYza1LfSelvVWNvbn2npvNCJScn638uAPBGdu3aNW/ePHNb0QiooSf8/f3r
a6M1qaqq8vHxIQWdt7e3CWwDjMoXX3zx9ddfG6PkTz75hM/ni8ViMsXFxWXz5s1JSUk2NjbO
zs6JiYkqlUpzl23btjGZzISEBIIg9uzZgxAqKSlJTU1FCG3evFmlUlVUVCxcuNDPz0/nEUtK
ShBCeXl5+N8LFy4ghDIzM/Uv2cXFxcbGpqSkJCoqSnMayNbWduzYsZmZmTY2NlKpNDc319bW
tl+/fpmZmZs2bUIIFRUVEQShUChGjx7t7e2dnJz84MGDkSNH+vj4qNVqgiDi4uLatGmD+0WE
kKur65QpU7Zv337t2rWHDx/iYr/88kuEEIvFWr9+/YEDB0JDQxkMxsGDB3fu3Onl5ZWTk4O9
LJ6eng1fefyC6yeffIIQ2r59u573q76TapRVjb25dQtp4ELVFSgA0By2bNny2WefmduKRkAN
PdGnT5/r1683nEckEnXv3p0cvnA4nNjYWNOYBxiPmJiYDRs2GKPkyZMnDxo0iPwXv79w69Yt
giByc3ODgoIQQr169UpOTsY9bkVFhUAg4PP5EydOnD9/vqura/v27eVy+fLly93c3LQ6p/ro
2rXrli1bCIKQSCTdu3efPn16o0quqKhACD169IggiN69ey9durS6ujozM3Pjxo2LFy++ceMG
3jpt2jRnZ+fXr18TBKFQKNasWSOVSgmC2LFjh729/ZMnT3B627ZtEUK///47QRBRUVEcDmfC
hAnR0dEIIU35Th4UOzauXbtGblq7dq2jo+OWLVscHR1bt24dFha2f/9+hBA+RH1MmzbN29tb
rVaPHTvWwcGhpKREn0tX30k11qpG3dy4uDitQoYNG1bfhQIAw7Jhw4aYmBhzW9EIqKEnevbs
iRv6+pDJZIGBgXiagxyxlZaWmsxCwEgsXrx406ZNxih55syZnTp1wv52LEYnT56smeHGjRuj
Ro3CrvXKysqdO3c6OzufOXPG19eXxWL5+/vn5+cTBDF37lwPDw89D7p06dKuXbvW1tbOnDnT
zc3t5cuXBEHoX7JarSbH0AEBAcuXL9e5deDAgaGhoXWPPmnSpOjoaPx72bJltra2Hh4e3t7e
MplMJpNhV82LFy8QQllZWXWL/eyzz9zd3TULjImJEQgEK1asQAi5u7tLJBKJRMJgMHJzcxu4
CJ07d16wYAFBEEVFRTwez9/fXygUvvHS1XdSTbNKz5u7evVqrUL+/PPP+i4UABiWVatWrVq1
ytxWNAJqvN/R8DJhBEFMnTr1+vXrUqkUp9Dp9EGDBuHhF0BpjPd+x/vvv19cXDx9+vQffvgh
ICBAqVRiL7darZ46dWpeXp6Pj8/JkycvXLhQXFz80Ucf5efnd+vWLTQ0NC8vTyaTZWdn43VN
xGKxWq3W86AfffRRcXGxq6trYmLizz//jEP59C+ZRqO5uLjgnszFxeXx48c6t/bp0+f8+fM7
duyora3VzODh4fHrr78uXLhw8ODBsbGxP/74Y0pKyuPHj0ePHi2TyfCbUPg9jjt37tQtNjAw
sLCwcMWKFWlpaYcPHw4NDY2NjY2Pj8eLSezZs4fL5XL/H3vnHRbV0f792V3KsruUBRFQUBBQ
jA1FoigKdhQ1FiKKvTy2FDX2Ho0l1ghGxahRMbEhQcUCVlQsgESNPPqIiiAKFmCBbcCW8/4x
V+bd38KuS9ly5P78wXWYnTPnPufMmfnOPY3DcXNzUz29KmVlZVKpVKlU2tnZDRs2LD093dvb
28fHZ/ny5VrO0nRTNbKqpi8XD55VTeTFixeaHhQA1C8VFRUwHrP+8fLyev78uaZfly1bpjYp
1MHB4cWLF4a0ENAT33//fWRkpJ4Sj46OtrKysrOzmzZtGnYVUBSlUCiaNm3KZrPHjh27ePHi
b775xtHREfdTMJnM9PR0tUQiIiKYTKZYLNbxolFRUebm5tHR0SSkRimHh4fjEYLr1q1r1aqV
2in417KyMuzS5/F4/fv3X7lyZWJiIh6EERQUxGAwPDw8Ll26hE9JSEjgcDi454WiqIqKCiaT
OXny5KrJKpXKZcuWNW7cGCHE4XCGDBly+/ZtiqJ++OGH/v37k8gTJ06cPn26lifQqVOnqgXR
0KFDtfeSaLqpGllV05er5daqfVAAUI/MnTv3l19+MbYVNYAeesLd3R2PvarKqVOn1KaNWVtb
//HHH4Y1ENAXs2fP3rVrl4EvWlhYOHPmzCZNmjAYDD6fHxwcfO/ePZFI5OHh0bhx46NHj2Zl
ZWVlZZ09e3bRokU412VnZ9f6crVL+c2bN1rKGoVCER8fP2bMmBYtWiCEWCwWduDrwqFDh7Ky
snS3v6KioqCggPz78uVL7VM8CgoKVqxYMWfOnFWrVl26dEkikeh4oRrdlCaravRyO3Xq1KhR
I/IK1G6tpg8KAGrEzJkz9+zZY2wragA99ISrq2u1g7YePnxYdbkqLpdbXl5ueCMBfTBjxgzV
prxxefHiBd5ygmBpaRkQEPDTTz/hsYEmmDJFUQUFBTqOeaQR9X5Ten0FAFALJk2adPDgQWNb
UQPosZ5VteMnPnz40L9/f4lEohrIZDKHDx/+yYVoALpgUvt3eHp63rp1KyMjIycnh8lkenl5
+fj41MsGgPpLGSGE12b4zKj3m9LrKwCAWkC79azooSeqViqVlZUhISF4WLhqOI/HmzRpkkGN
A/SJCe7f4efn5+fnR6+UGywSiaSiokL3+CkpKaGhoXhJK5FIVI+WlJWVKRQK7XE0rayKEOLx
eCBuGhrl5eX0ahubVkmtCTX/BEVREydOxHuHqsWUy+U9e/Y0rHWAHjEp/wQtKC0tJbNC5HI5
XlgaI5VKVSdH1C6mQqEoKyvTFLNqrVlRUaHmRMRQFFVSUlLtLYjF4srKyqrhMplMUx1fUlKi
1rSoNXPnzq2XdAyGhYWFpl2KGAwG3iqlWqytrTWJdUtLS03LmdvZ2TEYDHysqnLYbDaZsW9m
ZmZtbU1OUdVJqhetxSlWVlb0arLXBdrN76CHnpDL5aRSUSgUEyZMSEhIEIvFatEYDEb//v1B
xX9OmKB/AiMUCvFeULiuVa0dSXWoWkmT+JWVlSTrknq6vLyczHYWCAT4gLStlUplaWkpDhSJ
RFhGqyauS9u33rGxsSFfJYvFUt0wTLWeUEU1Gh4OWW1qqmhKislk2traVmuYlmqSoFZ7EZYt
WzZ//nzsnzAuqvlEDS1SDKnkkKpo0nbo/+axqpDci/7Nn6pZTtUJpMXsesfc3JzH4+FjNeWk
mp1wNiMRyAHJQuSA5E+SPcgBuRY5IJJLVWDVL9DfoRcUCoWZmZlAIMCTxf/73/9Wm2Wtra0j
IiIMbx6gP7T4J3C5ScpWUiWrVfCk3iWFKWlSk5KXFI64rCRlK2kQk3Nr6j//JKpVLGntqRaU
uGTk8/mqTUZShJHmmlp5qtaMs7W1JUtEq9X9ajG1qISG0DRct27duHHj3NzcjG3I54CaRlH1
cqm6oFRVjpr3S9XtpKqTVPW3mmut2lPwJ19cXEy+X2KAJmdYTcFfB5Em+FsmHzL+rMgnjCUO
h8OxtLSs9hQPDw9PT0/QE3oBN1IjIyPXrFmjJVp5eXnnzp0NZhVAwN8tKT5IhY1LEFIr1yJa
dnb23bt3ly5dWjVaXSC1L2l/EKcxLhf4fD6Xy8UbgpMqFpcC5Puv2lJR9TyTKp+0sFWrfFyU
1PEugHrHZP1hdITJZKq6oLSMDjEFiPggB8QrQ9ob5ACXRUTK4HDim8GaBpdvuBwTCARYuKid
osmY1atX//jjj6An9AJupA4dOvT9+/f79+8nnreq0SZPnjxq1CgXF5dGjRo5ODhYW1vb2Nho
8ot+TpDmOKmtidInOZjUxCTfV22y4y+BRNCkANSi1RrSAiZtX1wN44qZz+ez2exmzZq5urri
l1htNPSvtCc1PanCSbVNfOD6c04CnwGgJxosxCNoSN1DSmDsGSUSpFGjRoiG/R2M+hrEpD8U
CoWlpSXREMnJyaGhoZp6ATVha2trbW1tbW3N4XBIu5O4l0llQ1qixD9cx+qn6jAxTR481XFt
qk1wTT5Dkg7pbq8jpGondTD+rkjjGz8lTdFI1a4pmpoC0KWTGyE0ZMiQGTNmDB48uF7uEQC0
4+Dg8Pz5c3t7e2MbAgCoRYsWV65cwau30QIaKHG1FkNwcHBSUtLAgQOrdXrb2NgcPHjQy8vr
/fv3JSUlAoGgrKxM+C+lpaWqfiqBQFC1yW6Y8USqvdSqrm/VPnJcJROfIVHNpEomkUlznDTf
SZpEPOlPM+kVmN8BGBLwTwCmA+38EzT4cqrWKIGBgRcvXqxWUojF4qSkpBEjRtT9usQTRcb+
1HE8mol3H5omUL4DhgT0K2A6wHzR+qfaGiUwMDAhIaFqx4dCoTh16tSePXvIaPZaY2lpCSPm
jA6U74AhAf0KmA6080/QYL9yTV847vggg2gIMpns9u3bBjEN0DtQvgOGBPIbYDpUVFTQq01L
Az2hpYWKOz7UJIVEIjl8+LBBTAP0DvgnAEOiVCrr7toEgLpTWVnJYrHoVfrR4MvR3mKoKikU
CsXJkyc1zSkF6AXoCcBg4HV4TXZsMtCgoN3mHegz0BPo37EUqqvNMxiMGzdu6N80QO+A/xkw
GCBeAdOBdoMnEC30hC4fudpYCqFQGBUVpX/TAL0DRTxgMEC8AqaDRCLRtM2byUIDPaHjR67a
8UFR1KVLlz58+KB/6wD9AnoCMBiq+w4CgHERi8Watng1WT4fPYH+r6RgMBgHDhzQs2mA3oEm
I2Aw8L6DxrYCABAC/4SeqFGjgUgKqVQaFRVFtrMDaAr4JwCDQVEU3jcBAIyORCIB/0T9U9NG
Ax6eyeVy379/f/nyZf0ZBhgAcEEDBsPBweHZs2fGtgIAEIL+Dj1RC493cHBwYmKiubn5jh07
9GQVYBjABQ0AQAME+jv0Qu160AMDA5OSku7cuZOfn68PqwDDAP0dQB1ZtWrVli1bjG0FANQM
6O/QC7WuUYKDg8+fP3/ixIl6NwkwGDAeE6gjZWVlT548MbYVAFAz6NjfQYOSui41SmBgoIuL
S/3aAxgS8E8ACKGFCxd6e3tPnz69dqeLxeL6tQcA9A30d+iFOrZQPT0969EYwMCAngAQQvHx
8RcvXqzduXK5HFbfB4yCTCbLyMio3bnQ36EXoEZpyEB/B1BZWZmTkyOTyWp3ukQiqV97AEBH
zM3NT548ee3atVqcC3pCL0CN0pABNUl3Ro4cOXz48Lqk8PTpU4VCIRKJane6VCq1sLD4ZLS6
2wkAVZk6derQoUOTk5NreiLoCb0AeqIhA3pCFwoKCg4fPmxsKzRy+vTp48eP1/p0PEXL3t6+
dqdLJBIdz62jnQBQlZYtW3bp0qV///419VLQcTwmDfQE1CgNGeOqSaFQeOLEiYULFx45csRY
NuhCamrqtGnTqo4SMAX7Y2NjY2JibGxsap0CHk3p5ORUu9MZDIYuq17WyE5TeLAAXViwYIFc
Lh88eHCNvBR0HI9Jg3Y/+CcaMsZSk9nZ2du3b4+JiREKhQghd3f38ePHq0ZITU29evWqs7Pz
2LFjLS0tEUJFRUVbtmx58+aNr6/v1KlT+Xx+XQyomr72cLlcLhAIHB0ddbS/Kprs13RFHWEy
meTStbtEeXk5QqhXr16fvFZmZubp06d5PN706dNJ204kEukyyUvVTi3U4sECDZyQkBBXV9e8
vLzQ0NCEhITevXvrchYd+zsQZfIcO3Zs9OjRxrYCMAJKpZLBYOj1EseOHbOzs8vPzychu3bt
evXq1aBBgxBC/v7+6enplZWVamfNnz8fIeTg4IAQCgoKoihKJpMFBASQz8rNzS0tLU37pd++
ffvhwweKol6/fr1v3z7t6WsJFwqFmzdvRgj16NHD29ubyfz/TkdN9ldFk/2aLJFKpQkJCWvX
rv35558PHTpUUlKi6UkqlcqHDx/W9BK7d+82MzPjcDgHDhzYt28fQkgoFGq/hXPnzhEtEhwc
TMK7d+/+119/4ePy8vJZs2bh9knbtm2Li4tJNGInodoXpD1jAEC1REZG4o0qORzO9evXdTml
b9++ly5d0rNd9QwN9MSRI0fGjh1rbCsAIyCTyczMzPR6iW+//ZbH44lEIhLi6Oi4bdu22NhY
c3NzBweHmJgYhUKhekpUVJSZmdnhw4cpioqOjkYI5eXlJSQkIIS2bdumUCiKi4vnzZvn5+dX
7RWvXLmycuVKsVhsa2vbq1cvmUzWuXNnhNCNGze0pF9t+MKFC11cXIiAcHJyGj169M6dO+/e
vXv06FFN9ldLtfZrsmT37t0MBkO1WTJ//nxNTzI3N9fc3BzrDx0vgXcGbtWq1ciRI5csWRIR
EYEQ0l55379/n81mf/nllykpKXg1zFevXuGfWrVqdfHiRYqiZDLZ4MGDfXx84uLinj9/PmDA
AF9fX6VSiaMRO7W/IC0ZAwA0UVpaymaz8ceio6To1q3b7du39W9afUIDPXHo0KGJEyca2wrA
CEilUjabrddLhIeHd+/enfwbHx+PEPrnn38oirp//35QUBBCqH379nFxcbjiKS4utra25vF4
YWFh33zzjZOTk6ura2Vl5dKlS52dnXWpYI4cOeLr67t69WqEUIcOHebNm2dpacnlcn/88Uct
6VcbPnbsWCsrqxEjRkydOhUhpOYRqdZ+TVS1X5MlP/zwA0KoRYsWa9euvXnz5oABAxBCa9as
0fQki4uLEUIvX77U/RIdO3YcNGhQRUUFRVEPHjzAHV7a22oREREODg6FhYUURclksjVr1kil
UvyTp6fn2bNnKYr69ddfbW1tX79+jeM0adIEIXTmzBliDLZT+wuq6YMFAEy/fv2I/uZwOFev
XtUe39fX98GDB4axrb6gpR+NgwAAIABJREFUgZ7Yv3//1KlTjW0FYAREIhGXy9XrJSZOnOju
7i6XyymKEgqFbdq0CQ8PV43w4MGD0NBQ7EIvKSnZtWuXg4PDxYsXO3XqZGFh4e/vn5mZSVHU
jBkzPD09dbnikSNHmEwmi8Vq3bq1hYUFi8WKjY0dNWoUzuSa0q82vKKiAvsD3r9/jxBKTU2t
ejk1+zVZVdV+TZb4+voGBATgJ3bw4EEmk8nlcsvKyjQ9SaVSiT0Qul+iUaNGJ0+epCgqPz+/
RYsWffr0GTp06OzZs7U81W7duoWEhFT7k5eX16FDhyiKIg+ZoqjFixez2WxPT08fHx8sXIid
2l9QTR8sAGBOnDihOtr3k5LC29v72bNnBjOvXqCBnoiOjp4xY4axrQCMQGlpqY2NjV4vcfXq
VYTQ6NGjo6Oj27Zt26pVK4FAQFGUQqEYPXr0/fv3cbRr1665u7uPHj161qxZPXr0qJrO2LFj
PTw8dLkinhEwZswY3AL+4YcfKIpaunRpz549KYrSlL6mcIxUKkUIHTx4kIRosl9TClXt13TF
8PBwe3v7rVu3Tp48mcFg2NradunShdL8JCmKcnFx2bx5s+6XaNmypZ+f3w8//ODs7Ozp6fnu
3buEhAQ+n19WVqbJ/m+++YbJZO7cuZO4JQidOnVasWIFRVFLly7l8Xhz584NDAxkMBh//PHH
48ePrays+vXrh1PGdmp/QTV9sACAEYvFVlZWqr2E2iVF06ZN37x5Y0gL6w4N9MSuXbu0N02A
z5WioiJ7e3t9XyU6OtrKysrOzm7atGl4/B1FUQqFomnTpmw2e+zYsYsXL/7mm28cHR1btWq1
fft2JpOZnp6ulkhERASTyRSLxZ+83PXr15s0aSIQCPbt29exY8fy8nKKom7dusXj8SiK0pS+
pnBMRUUFk8mcPHkyCdFkvyarqtqv6YrPnz9v06YNi8Xq0qXLrVu3pk2b1qdPH/xTtU+Soqjw
8PCTJ0/qfonY2Fhra2szM7MRI0a8e/cOB06aNOm///2vJvvLyspwHwSPx+vfv//KlSsTExNx
38qPP/7o7+9PUVRxcXFQUBCDwfDw8CC9JwkJCRwOZ9y4ccRO7S+opg8WAAhDhw5VG3ikZSwF
n89XHS9MC2igJyIjI7///ntjWwEYgQ8fPjg6Ohrr6oWFhTNnzmzSpAmDweDz+cHBwffu3ROJ
RB4eHo0bNz569GhWVlZWVtbZs2cXLVqES4fs7Ow6XlRT+u3atcOXUAvv2rVr27Zts7OzDx06
lJWV9Un7NV33ypUrQ4cO1cUSckUcbe3ate3bt9fl1mp9CR1RKBTx8fFjxoxp0aIFQojFYuHe
k3qnRg8WAAjx8fFVFzjR5KWwsLDAWpZG0EBPbNu2DbscgYZGfn6+i4uLsa1Q58WLF4GBgaol
gqWlZUBAwE8//VTV2V6P6U+aNAlPNNDTdXW3RPWK9+7dQwjdvHlTf5eoBQUFBXgqCgCYDuXl
5WpdHpokhUwmY7FYxrKz1jAoiqp6eybFli1bPn78iGfYAw2KN2/eBAQE5OXlGduQasjIyMjJ
yWEymV5eXj4+Pubm5oZJX9/X1d0SwqhRo+7cuZORkVHrJSwNf1PVkpiYePv27Z9++qleUquo
qDDKVmQKhaKsrExLBBsbm2rXiKvjCmyALoSFheHVUNTCORyO6lJXZWVlbm5upaWlBjewTtBA
T2zcuFEoFG7YsMHYhgCGJjc3NygoKCcnx9iGANqoqKjYt29faGioh4eH2k8SiaSiogIfK5VK
1fJRJBKRLUPlcjlebhJTVlamUCjwcWVlJV5vG4NnUuDj8vJyPBAVIURRVElJSbXXxYjF4srK
yqrGCwQCclxYWCgWi5s3b6520WptJqhd+jODxWJVuwa5ubk5XqBJDTabXW0TnMvlVt2VzcrK
Cq/KwGQybW1tcSCPx8OCUvUStra2eJ0Vkj6DwbCzs1NLXNVaPAQHIWRhYWE6C1efP38+IiKi
WsHH4XDOnz8fHByMECooKPDz88M719AIGqxjDettN1jg1esIqdJIna1aQ5eWliqVSqRSAatW
gaSiVT2F1OiqjWxS9ZLaWvWUNWvWVD3FAJiZmVlbW5N/VRvfmioSUtMglUY5PovFYuHhFwRS
56lBajgtxlSLSbkBVPUZQZNCUpN9BE1vvKqqwwiFQrzXDM5R2jNb/WJnZ4dHRFaVMkSg4OyB
hQsRKDhf4bPIW8Z5gMPhWFpaEvXD5/M1iTCEUEhIiKbdbiUSCVmQWywWm44G0h0aFNZkB4d3
796Vlpa6ubnRb1VzoFbQZSs4UiDiQpBU6jKZDO+yTdq7pMSUSqV4WwpS5pJ6nTSCSbFL0ifK
gFQD9V7s6tJk5HA4HA5HxyYjqlKvq9bEas1Z1boWF9P4WNUYVXvqlz179jx+/Hj37t31njJQ
a8gHotqPQz4NVU8S+SjIx6XqEiOfFfkqUXVSu6SkRCAQ4I8RJ15r/xPO9jiH488BKxUnJyeB
QEA8cGo3O2jQoLVr137xxRegJ/SCQqHAxUp0dPSaNWsQQra2tk2bNnV1dXVxcWnWrJmTk5OT
k5ODg4ODg0OjRo3s7e2rbU8AtENHPUFqYlLKkPWFcEFA2lWk9CElDjmX1Nn43KoN/apSoFrv
dy0g1TCpNUn7BreEbGxsSOvH0tIS62lSExMFQCpgUpfr7k8m7baGDPjDTBAsXvGxLvvE6g/8
veNygJQPuNzAcgQrHvwTVi04HEsiXDqVlJQwGAwsYqqloqJi8eLFU6ZMoWOzmQYfj1wux0ot
PDzc09MzPz8/Pz//zZs3BQUFT548ef/+fdUyncvlNmrUCCsMOzs7GxsbHo9nbW1tbW1tZ2dn
/S88Hg83lbR7qICqVOs5r7YlUW2zgFTeJB1yLtEEpaWlZWVleXl5eFIDSZNoAtXu87pAXj1p
RpOqGlfMfD6feMhxvUsUAPF8knNJFU4qdeKBJ+1yUnmblOsbAD0BaKHa8SK1IDExcfTo0dWO
tcQSPyoqCiH0+vXrermcIaHBx0M+8tatW7du3VrtV6VS+eHDh8LCwqKioqKiosLCQnKM/337
9q1QKBSJRLp4hvHrxNUJae2pNt1Ue2dVPbqqbltV764+ZIqmepT47jBqrWe1s1Rrd1RdjylJ
rVqPYv2Cq1XShibtZrlcjqf4k3dB2takbsbnkudMziVvhJxLNAE+V9U5DwCIPv1rAK1JTExU
LXsJXC63Y8eOZ86csbe3P336NPR36AXtHzmTyXR2dnZ2dtYlKSwshEKhUCgsKSkRCoUymUwg
EKh6qLA7CzeXVatkXJViUULa0Oj/jjky1gwxVdTGXVetNdXGkWFVhKtt9H+Fke4jqFUvSiQX
8cyj6oZB6VKd379/f+bMmZcvX67NgwCAGgL+CcAAnDx5surgCS6X+9VXX8XExODCE8Zj6ot6
/MhxN4eLi0u9pKYdVQeA6rCgevdYaJqg9RmgUCigfAcMBugJQN/cvHmz6hwZLpcbERGxd+9e
4giXSCSgJ/QCTT9yc3Nz1d5xBwcHIxpDU8D/DBgSyG+AXqEoavbs2WpLm1hZWfXt21dVTCDa
+ifU50+bIDTVE0DdgVcPGBLQE4BeOXr0aG5uruoQNLzeyfHjx9VmV4Ge0BfwkTdY4NUDhgT0
K6A/5HL5Dz/8oDYSEy+zXXWBA7FYTMf5ojTQE/CRN1hATwCGBIoaQH/ExcXhdWsIHA7n4MGD
VVepR7T1T9Dg44GPvMECrx4wJKBfAf2xdetW1W07uFzulClTRo4cWW1kmuoJGvgn4CNvsMCr
BwwJ6FdAT7x58yYzM5P8y2azu3Xr9ssvv2iKT9P5HTTQE/CRN1hATwCGRC6XQ34D9MEff/xB
Rlyy2exWrVqdPn1aS2YD/4S+AD3RYIFXDxgSWO8E0BOHDh3CyxNbWVm1bdv21q1b2odbgp7Q
F9BIbbDAqwcMCehXQB/k5+fn5uYihDgcTseOHW/cuPHJTe1BT+gL+MgbLPDqAUMC+hXQB+fO
nUMIcbncoUOHXr9+XZeJoKAn9AVUKg0WKN8BQwJFDaAPjhw5UlFRsWTJkmPHjpEtJLVD0/Un
aPDxQKXSYIFXDxgS0BNAvSORSJ49e3bu3LlBgwbpfhZN/RM0+HjgI2+wwKsHDAnoV6Deefny
5Y0bN1q3bl2js6RSKfgn9AJ85A0WePWAIQH9CtQ77dq1q8VZUqmUjrtG02D8BFQqDRZ49YZk
4cKFv/32m7GtMCagJwBTQKFQKJVKc3NzYxtSY0BPAKYLlO+GJD4+/uLFi8a2wphAUQOYAjR1
TiC66Akms5Z2VlRUyGSy+rUHMBhQvhuMysrKnJycBv6xgH4FTAHQE3pEqVTWolKRSqWzZs1q
1qyZPkwCDAOU7wbj6dOnCoUCb6Y8cuTI4cOHG9siIwD5DTAFpFJp1R3MaQEN9EQtGqlCobBn
z5779+93c3OjYy8UgAH/hMHIz89HCNnb2+N/T58+ffz48fpKvKCg4PDhw/WVmv6A/AaYAuXl
5eCf0Bc1/cglEkn37t0zMzMZDEaNpvwCpgaU7wZDLBYjhJycnBBCsbGxMTExNjY29ZV4amrq
tGnT5HJ5fSWoJ8A/AZgC9O3voMHHU6NKRalUhoWFvXz5sry8nMfjDRs2TK+2AXoFyvdaUFRU
tGXLljdv3vj6+k6dOpXP5+Pw1NTUq1evOjs7jx071tLSUu2s8vJyhFCvXr0QQkwmc/z48bVI
LTMz8/Tp0zweb/r06Wqz5+VyuUAgcHR01Nt91wOgXwFTgL56AlEmj6en54sXL3SMPGfOHLKs
mKurq14NA/TNqlWr1qxZY2wr6IRMJgsICCBft5ubW1paGkVR8+fPRwg5ODgghIKCgnDk3bt3
m5mZcTicAwcO7Nu3DyEkFAopilIqlQ8fPqxpaufOnSPCIjg4mJgkFAo3b96MEOrRo4e3tzce
Wx0XF2fQ56IbnTt3Tk9PN7YVQEPn2rVrvXr1MrYVtYEG/R1KpVLH+R179+7dv38/9txyOJzZ
s2fr2TRAv0B7saYkJibevXt327ZtCoWiuLg4LCxs1qxZO3fujIyMPHz4cGFhYXR09I0bN968
efP777/Pnj3b09Nz4MCBz58/v379OkIIC4K8vDx/f//y8nLdU8vIyAgLC+vQoUNKSsqWLVuS
k5NzcnKioqKaNGlia2u7aNEihFBWVpafn19kZOTdu3eHDBli5CdVHeAPA0wB+o7HpMHHo2Ol
cuXKlR9++EEikZCQmTNn6tMuQO+Anqgpd+7ccXZ2njt3LpPJ5PP527dvFwgEzZs3Z7PZCQkJ
aWlpp06dcnV1dXJy+vXXXwcNGhQfH29hYfHw4cPOnTsjhJKTk/v162dtbS2TyfLz83VPbfHi
xVwu98KFCw4ODl26dJFIJM7Ozg8ePCgpKRk2bBifzz9w4EBCQoK/v7+xn5A2IL8BpgCMx9Qj
unzkT58+HT58OBETFhYW48ePJ329AE2B9mJNKS4u5nK5qv48vKVhbGxsdnb2vn37mjVrlpiY
aG5unpeXN2nSJAsLi4KCgpEjRwYHBw8dOvT06dMIITs7OzMzs5SUFN1Ty8nJ8ff3xz0gZmZm
q1atYrPZe/fu/fjxY1xc3IYNGxBCFEUZ/HnUDMhvgClA3/ETn4OeKCoq6tu3r6pngsViLVy4
UP+mAfoF2os1RSQSKZVK1ZDMzMwvvvgiJCQkIyOjoqIiLS2tTZs2CCF7e/tNmzbNnz+/U6dO
DAbjzz///M9//nPs2DGhUMhgMBwdHd+/f697ah07drx06dKvv/6Kx3ViLCws8GAmPFXkyZMn
BngCdQH0BGAKgJ7QI9orFalU2rdv38LCQlLwMZnMXr16eXp6GspAQF/I5XLQEzWCoqjc3FxV
be3t7X379u379++rxVy/fn1WVlZUVFS3bt1u377t5OQ0ePDgr776Ki8vDyHUs2dPd3d33VPb
uHFjjx49vvvuO0dHxwEDBqxatSopKUn1k2QymTdv3tTLPdcfoF8BU4C+eoIGYlzLeEyFQjF8
+PBnz55VVlaSQCsrq1WrVhnKOkCPKBQKaC/WiClTpohEItW5mtOnT9+5c2doaOiOHTvwIIn/
/e9/KSkpN2/ebN68+dmzZz08PEjkgwcP4gO8mJW9vb3uqZWVlW3fvj09PT01NfXSpUssFuvR
o0fYe2FhYfH7779369bNIM+g9oB/AjAFYDymHtHUaKAoauLEiSkpKVKpVDW8devWXbp0MZR1
gB6B9mJN6dOnT58+fVRDuFzu5cuXJ02aFBERQQItLS07deoUHh7u4uJSX6mNGTNm1qxZ8+bN
Qwi9e/dOLpe7urqSOBMnTqzjrRkA0BOAKUDf8Zg0+HiqrVSUSuXkyZNPnz6NZ4cSeDzeTz/9
ZEDrAD0C5Xu94OnpeevWrYyMjJycHCaT6eXl5ePjU+t16HVJzdnZuT4M//9IpVIWi2VhYYEQ
EovFqv5ILpdbX+G4qCHh+KBx48Y8Hg8h9OHDB7y/CYaEa0ofAGqHVCq1tbU1thW1gQaFdVU9
oVAoIiIizp8/ryYmEEJ8Pn/AgAEGtA7QI+CfqEf8/Pz8/PwQQmVlZXiQhFKpLC0t9fDwwNt2
ZGZm5ufnl5aWIoQUCoWfn5+3tzdCKCEh4cmTJwqFoqysDCEUHh7esWNHPz+/Bw8eXLp0iaT/
7bff9uzZEyG0adOmK1euIIQqKyvFYvHatWvxsverVq06d+4cTh8htG3bNrx87cyZM0+ePEnS
iY6OHjVqFEJo/Pjxf/zxBwk/cuTIuHHjEEKzZs06cuQICY+JicGredY9HOtXTfEXLFhQo/Qn
TJigKf6JEydI+J49e8LDw3H4qVOnyDLnW7duxbuyLViwID4+nsFg2NnZIYTI81y9evX58+dx
ZFtb26VLl/bt21f1+SOEzM3NFy9eHBQUhBDatWtXamoqafhOmjQJL1Z28uTJv//+GyHE4/HM
zc1DQ0Pbtm2LELp+/frz589xZBaL1bdv3+bNmyOE0tLS3rx5Q+xs06YN9nLl5OQUFRUhhNhs
tpWVlaOjo7W1NUJIKBSqLrVubW0NjQTtSKXSelfkhoEG71WtUikpKRk5cmRqampVMcFms2fM
mMFgMAxrIKAvGqaekMvlQqFQJBKVl5eXlZW5u7vjeZhpaWkvXrwQiUS4nibl/sGDB5OTk6VS
aXl5uVQqXbRoUb9+/RBCCxYs+PPPPysqKiQSSUVFxeHDhydMmIAQ+u6772JiYsjlSPjWrVtV
d+06dOgQ1hNxcXEknMPhdOjQoWPHjgihrKysjIwMKysr3NeL1QZCSKFQ4AMLCwsLCwviunBy
cvLy8sLHDAaDlJhdunTBU0ltbGxYLBaJM2TIEC8vL9KR7Ovriw9GjRqFh2XY2dkxGIyuXbvi
8MmTJwcGBhL7axGOx//WLh388BFCnTp1UrNTJpOJRCL8shBCwcHBpPWpUCjc3d3xsb+/v+ps
miZNmuCD5s2bYyGIwZU0QojD4WiaEi8QCMgxGU778uXL27dvkwhYfCCELl26dODAARLf1dUV
m3rgwIE///yThP/xxx9YT0RFRamGE523cuXKavXf7NmzVcPV9BZ+6UhFR86fPx/PW2axWDY2
NkQ/EZ2E5w0R/Xrw4MF79+6RyUSjRo3Cr+DcuXPPnz8nyyX37du3RYsWCKFHjx59/PgRB/L5
fPJ9Ef8TzldG9DPRd/wEw/QnhVtYWIjFYnNz81evXqWmpn7//felpaWqDkaCra1tcnIyKXcA
uhMRETFkyJAxY8YY25AaIJVKJRJJaWmpg4MDrjbS09OfP38uEomEQmF5efmAAQPwSMY9e/ac
PXu2vLxcKBQKhcL169eHhYUhhKZMmULGRSKEDhw4MGXKFITQtGnTVMv9ffv2TZs2DSG0cOHC
v/76y9LSksPhsNns5cuXDxw4ECF0+PDhO3fu4Preyspq+PDh7du3RwjduHHj2bNnpLjs3Lkz
HpJJ2pf4J9K+lEgkZmZmDcGHb21tXVBQgHsxANyPg3UqUunfefXqVXFxMY5TVlbWunVrLA0z
MzOfPXtGJFGXLl2aNWuGELp27dqLFy+If2vIkCFffPEFQuj48eMPHz7EkcvLy8eOHYuXO9u/
f//169dlMhn+ac6cOd27d0cIbdiw4erVq8S/tX79euyK/v7774lekUgkBw8exCVGRETEsWPH
yO0cPXq02vA///wTDwYaO3bs0aNHNYVjkYEQ+u233/B3Om/evBs3buC5Amw2e+3atb1790YI
RUVFpaSkIITwpzd16tQvv/yS3C/R3+Q5XLt2LT8/n6xV36NHj8WLF/fp0werfHpBAz3BYrFk
MhmTyfzxxx/XrFmjPXLz5s3nzZs3Z84chNCRI0diYmI4HI6lpaWlpeWoUaPwKr9Xr17FE95s
bW2ZTOaXX36JJUh2dnZeXh6Px2Mymba2tnw+H1bEMi7h4eEjR47ErRaDQQZtvH79+vXr11gc
iESirl27tm7dGiF0/Pjx69evCwQCiUQikUi+/fbbESNGIITmzZsXGRlJPqg9e/bgFVpnzZoV
HR1N0t+1axdeCX79+vXx8fF2dnZsNhsvDx8cHIwQunTp0pMnTzgcjq2trYWFhb+/Px7Y+Pbt
24qKCnNzcx6PR1pjQD1iZWUlEAho2jQE1FAbB+Pk5IQ/mezsbIFAIBKJsGRp164d3lb33r17
T58+xYEymaxPnz4+Pj4IoaNHj/7zzz/oX8fhf/7zH9we2LFjx507d3AgQmj58uX4+126dKlq
X/yOHTtwvTNu3DhVv87x48dxP9fo0aNV+7+OHz8eFxf39ddff/311wZ4SvWLqesJiqJYLBbW
vC9evDh37tzSpUtV18xRxczMrHPnzosWLcL9jgcPHvztt99kMhmW2PPnz8fl+PLly/GCfZif
fvppxYoVCKEVK1asX7+ehK9du3blypUIoZUrV65btw432ths9rJly7799luE0G+//RYbG4v+
7RHElR9C6MyZMykpKdiJZ2trGxQUhGfKpaenP3r0CLdZWSxWx44dcbswPz+/oKDAzMwMNwft
7e1xRylFUQ287yYsLGzMmDH4qWoBjwPAwhEhlJeX9+7du9LSUhzu6+uL/fZXrlxJS0srKysT
CoUSiSQ8PDwkJAQhtHnz5r1794rFYolEIhQKo6KivvvuO4TQnDlzoqKiyFV27NiBdery5cux
TrW2traxsSF6IiEh4d69ezY2NtbW1hwOp3v37vi6eXl5MpkMOwlIKwcwQYgr1NiGAJ85ZWVl
bDYb+/zev3+PxUdZWZlCoWjRosWECRNmzJgxePBgY5tZY0x9/ITq4hNeXl5z587t3LnzwIED
VQdaE+RyeV5eHtmjfPLkyZMnT64abf369evXry8pKaEoqqysjPRlTp48OTg4GOtNiqJatmyJ
w/v06UNRlFwux/3QpH+XyWRSFFVSUiIQCCorK0mf3KNHjw4cOID7rRFCP//8M9YTf/31188/
/0zM2Lhx45IlSxBCv/7668aNG6uGL1++HIfjqmjlypV4Mt6WLVtiYmKIf2z+/PnYj3fgwIHj
x48TXRIREYEfRXx8fGJiIkl/+PDhuB5NTExMTk5G//rlgoKCcJfwjRs3njx5QgYudOnSpUOH
Dgih1NTUR48ekXRqGt65c2fcr3n9+nW8TWVJSQlCaNCgQbgf9NSpU5cvX8YPGSE0fvx47CrA
uo10Cc+ZMwf3v65cuXLnzp3E/7l161a872VkZOS2bdvIdbds2bJgwQKEUFJS0tatW3G/AJ/P
JztnNmnSpGvXrjwez9bWlsPhYOckQmj69OlDhgzB4oDL5ZKplTj/oCoMGTKk2m2u3NzcqgYC
JgjMJwIMAxnNihDC3hFVYD0rfVF1RF5gYODFixc1SYqysrIbN25gv5N2sA9AtUfD09Oz2lU1
g4ODq01w2rRpuANbjVWrVlW7oNbChQv/85//oH/9b2R2/uTJk7/88kvsZxMKhWTsVf/+/W1t
bXE9SlEUHtuFEHJ2dm7dujXpjyTPRywW48hY2ZDxcVlZWXgcEx5o3aZNG6wnbty4sWnTJmLe
pk2bsJ64cOEC3mAa8/PPP2N9EB8frxq/FuFYTyQlJZFwBoPh4uKC9cSLFy/IuHQej1dcXIzf
PhaUfD4f90ORT9HPz2/mzJl43DuTySQrJUyaNCkkJASHMxgMPAgLIbRu3botW7ZUfS/jxo3D
A8fUaNOmDXnmwGePUqlkMBjgPQKMTkVFBWku0gtT7++QSqUODg6qK/5iUlJSqpUUDAZj8ODB
Z8+eNZSBnyFkBBb239jZ2WHtRcIxZGBRLcLZbLYuBffAgQPnzJmD1Q8A6JXKykpra2vsGwMA
I9KlS5edO3cSRymNMHX/hKbFtgMDAxMSEkJDQ9WkBkVRly5dEgqFZFYVUFOsrKyItw2vTFA1
XFN8HcN1tKRhzhcFjAJ0dgAmQmVlJU2nU5n6fmBaapTg4ODz58+rbi6AYbPZeLoOQHdATwAG
AzIbYCLIZDKaDgqmsZ5ACAUHByclJanNFxcKhXFxcfo3DdA70GQEDAZkNsBEAP+EvvhkowF3
fKh6KZRKZXx8vOpKcwBNgSYjYDDw4pjGtgIAUGVlJfgn9IIuNUpVL4VMJiMzBQD6AnoCMBgK
hQL8E4ApIJPJwD+hFxQKRbXjMdXAk0iJpBCJRL/88oueTQP0DrigAYMBmQ0wEaC/Q18olUod
W6iqkoKiqOTk5IKCAj1bB+gX8E8ABgMyG2AiQH+HvqjRR64qKRgMxu+//65P0wC9A01GwGBA
ZgNMBOjv0Bc1bTQQSSGVSnfu3AmjMmkNNBkBgwF6AjARoL9DX9SiRsEzPrhc7ocPH65du6Yn
wwADAHoCMBiQ2QBTQKlU4l0wjW1IbfgM9QRCKDg4ODEx0dzcPDIyUh9WAYYBmoyAwYDMBpgC
9HVOINPXE5rW2/4TxwsBAAAgAElEQVQkgYGBSUlJKSkpHz58qHer6MWqVauq3QfL9IEmI2Aw
QE8ApgB9F8dEpq8n6lKjBAcHJyQk/PXXX/VrEu0oKyt78uSJsa2oDaAnAIMBmQ0wBWjtnzB1
PV7HjzwwMLB58+b1aA9NEYvFxjahNkCTETAYkNkAU4DWeuJz9k9g3Nzc6ssYmiKXy+VyubGt
qA3QZAQMBugJwBSA/g49AjVK3VHb0p1GwJYKgMGAogYwBcA/oUdqPR4TIEilUl0y6MiRI4cP
H24Ae3QHtlQADAb4JwBTgL6LYyLT1xMNvNFQUFBw+PDhOiYikUjs7e11iXn69Onjx4/X8XL1
SAN/+4AhgcwGmAL0XRwTgZ5QQygUnjhxYuHChUeOHDHYRbWQmpo6bdq0Oo5+YDAYjRo1+mS0
2NjYmJgYGxubWl+o3p8eNBkBgwGZDTAFaN3fYerfj8H0RHZ29vbt22NiYoRCIULI3d19/Pjx
qhFSU1OvXr3q7Ow8duxYS0tLhFBRUdGWLVvevHnj6+s7depUPp9fFwOqpo+Ry+UCgcDR0VGX
RDIzM0+fPs3j8aZPn87hcHCgSCRycXH55LlMJlPtlnXnk0+vdkCTETAYoCcAU4DW4zERZdpc
vny5b9++9ZjgsWPH7Ozs8vPzSciuXbtevXo1aNAghJC/v396enplZaXaWfPnz0cIOTg4IISC
goIoipLJZAEBAeQxurm5paWlab/027dvP3z4QFHU69ev9+3bpz19iqKEQuHmzZsRQj169PD2
9sbjSOLi4jSlf+7cOSJEgoODSXj37t3/+usvfFxeXj5r1ixcbrZt27a4uJhEUyqVDx8+/KTB
jx8/PnnyJEVRW7duZTKZp06doihK+9OrNUwmU6FQ1FdqAKCFuLi4ESNGGNsKoKFz/fp11dKb
Xpi6nkhKSurfv389Jvjtt9/yeDyRSERCHB0dt23bFhsba25u7uDgEBMTo1aHRUVFmZmZHT58
mKKo6OhohFBeXl5CQgJCaNu2bQqFori4eN68eX5+ftVe8cqVKytXrhSLxba2tr169ZLJZJ07
d0YI3bhxQ1P6CxcudHFxIQNRnZycRo8evXPnzrt372qqre/fv89ms7/88suUlBS8GuarV6/w
T61atbp48SJFUTKZbPDgwT4+PnFxcc+fPx8wYICvry9eLp6iqNzcXHNzc6lUqt3gXbt2eXt7
p6enYxHt5eVFUZSWp1drlEolg8Gol6QA4JOcOHFi1KhRxrYCaOjUe5VnSEzdv1fvHu+PHz92
6NCBy+Xif0+fPv3x48d+/fq1a9fOw8Nj/vz5EyZM2Lp16+rVq4cPH85gMAQCwfLly9lsdkJC
Qlpa2qlTp1xdXZ2cnO7cuePs7Dx37lwmk8nn87dv367pigUFBQkJCUwms7S0tLi4eNGiRY8f
P+ZyudevX+/Zs2e16efn55eUlAwbNozP5x84cCAhIcHf31/7fW3fvp3L5V64cMHBwaFLly4S
icTZ2Rn/JJfLZTIZQmjv3r23bt16/Pixm5ubXC5//Phxfn5+QkLC0KFDEULW1tYymSw/P1+7
wXK5vLCwMDQ0tG/fvl9//fWUKVPy8vLCwsKqfXp1eVPgfwYMCeQ3wBSgdX9HgxuPyWaz3759
q1AoEEIikWjFihXh4eHt2rVDCPn5+SUnJz948MDNzW3kyJG9e/cuLS09duyYhYVFbGxsdnb2
vn37mjVrhncaKy4u5nK5Os5l/eeff9atW9e6deunT59GRUX98ccfoaGheXl5CKFq0//9998/
fvwYFxe3YcMGhBBFUZ+8RE5Ojr+/P+4xMTMzW7VqFZvNxj8xGIzi4mKE0M2bN8PCwvACXytW
rCguLvb09Fy8eHFlZSVCyM7OzszMLCUlRbvBAoFAIBDweLxTp06Fh4ezWCy8Q0q1T6/m7+f/
A+U7YEhgsA5gCtB6PGaD0xMTJkzIyckZN27c3r17AwIC5HI57mJQKpVjxozJyMjw9fU9d+7c
tWvXcnJyZs6cmZmZ+cUXX4SEhGRkZFRUVKSlpbVp0wYhJBKJlEqljhdVKpWjRo0aNWpUZWXl
nDlzwsLCPD09nz9/jhCqNn0LCwvsQcGzLXTZfaNjx46XLl369ddfy8vL1X6ysbF58eIFQsjT
0/PEiRPz5s3r0aPH5s2b9+/ff/r06dzc3MGDBwuFQgaD4ejo+P79e+0GFxQUIISio6M5HA6H
w3Fzc3vy5Immp6frW6kO0BOAIYH8BpgCoCf0SL3rid69e0dHR585c2bJkiVdu3a9deuWnZ0d
/unWrVuBgYHjxo1bsmRJXFycWCx+8OCBt7f37du379+/r5YORVG5ubm6LD3p6urapEmT3bt3
u7q6duzYEbscBg0a9PfffyOENKWPYTKZTCbz5s2bn7zKxo0be/To8d133zk6Og4YMGDVqlVJ
SUlY8QwdOjQpKQkhtHDhQj8/v8jIyLdv3yYlJY0dO7Zt27YnT568ffv27NmzEUI9e/Z0d3fX
bjCXy+3fv3+/fv3wdYOCgrBLo9qn90mztQDtRcCQgJ4ATAFa93eY+njM2NjYsLAww1yrsLBw
5syZTZo0YTAYfD4/ODj43r17IpHIw8OjcePGR48ezcrKysrKOnv27KJFi/DTy87OruNFNaXf
tWvXtm3bZmdnHzp0KCsrS5ekFApFfHz8mDFjWrRogRBisViZmZl1NK8qFRUVBQUF5N+XL1/i
KR7VPr26XOjjx4+NGjWqq7kAoBt79uyZOXOmsa0AGjoHDhyYMmWKsa2oJaauxw3ZSHVwcNiz
Z8+ePXvUwi9fvjxp0qSIiAgSYmlpGRAQMGjQIF3WddAOl8utNv1OnTqFh4e7uLhMnDhRx6SY
TOawYcOGDRuGEHr37p1cLnd1da2jeVWxsLAgIz0RQi1atMDyRdPTqzXQXgQMCeQ3wBSg9Xrb
pv79mILT29PT89atWxkZGTk5OUwm08vLy8fHpx5fuT7SV63yaYopvHqg4QCbzwGmAK03LTJ1
u02nUvHz8/Pz86Nv+rQD2ouAIaF1OQ58NtC63Gtw4zEBukDr7wqgHZDfAFOA1ltqm7rdCoWC
vg8XqAtQvgOGBJougClA63xo6lW1Uqmk78MF6gKtvyuAdoB+BUwB8E/oEahUGixQvgOGBIoa
wBSgdT40dT1Ba7HWoIiMjNy0aVM9Jgh6AjAkkN8AU4DWXfymbrf+xFp6evqIESOuXbumj8Qb
IK9fv16yZMmZM2fqK0GYvwcYElq3C4HPBlp38Zu6nqAoqo7bVFbLo0eP+vbt6+Pj07Nnz3pP
vGGyZcuW3r17L1u2jNJh9zJdgPl7gCEB/wRgCtDaJW/qduvp4X7//fd+fn4bNmyAEkQT33zz
zf79+3WPz2Qyf/755ydPniQkJKj9JJPJMjIyamoAlO+AIYH8BpgCtPaTNUQ98ejRo5s3b+7Y
saN+k9XEyJEjhw8fbsgT6wWKovBGX6oolcpHjx5lZmZWe4q/v39QUNBvv/2mFm5ubn7q1Kma
di1B+Q4YElqX48BnA/gn9Ig++jtOnDjRuXPn9u3b12+yWjh9+vTx48cNeaImCgoKDh8+rEvM
xo0b5+TkkH8rKyt3797t5eXVpUuXxYsX5+XlVZvO999/f/Hixbdv36qFT5kyZejQocnJybqb
CuU7YEhAvwKmAK3LPVPXE/oQa5cuXercuXP9pqmF2NjYmJgYGxsb/K9QKDxx4sTChQuPHDmi
Gq1quNqJ9UJqauq0adPkcrkukUtLS/FBRkZGp06dFixYMHTo0BcvXpw/fz4jI6PadIYNG9a0
adNjx46phXt7ewcEBPTv3193LwWU74AhgfwGmAK01hOm/v3owz9RWlqqY4WKSU1NvXr1qrOz
89ixYy0tLRFCRUVFW7ZsefPmja+v79SpU/l8vpbTmUzm+PHjEULZ2dnbt2+PiYkRCoUIIXd3
d+3h5MT6RS6XCwQCR0dH1cDMzMzTp0/zeLzp06dzOBwcqFQqRSLR2rVrf/nll4CAgLNnz+Kt
RLWkw2Qy+/fvn5SUtGDBArXrLlq06OrVq4MHD75w4UJwcLAudkL5DhgMWpfjwGcD9HfoEX08
XEdHx9TUVLXAlJQUPz8/Ozu7pUuXqrrrFyxY0LVr1+3bt0+dOnXAgAEIIblcPmTIkE2bNv35
558LFy7s0KFDeno6jpyfn//x40eEUF5eHhnMSFHUo0ePEELffffdrl27fHx80tPTKysrX716
hSNoCicnIoT++usvFxcXBoPBZDK7d+9+48YNhFBmZmZsbCxCaNu2bSwWKy4uTvuNi0Si58+f
I4RGjhzZsmVLFovFYDD++uuv8+fPd+7ceeXKlfPmzQsNDSXxX7165ePjExkZuWTJkuTkZCIm
NKWDf23Xrh25BVX69evn7u4ulUpDQ0N18VKAngAMCeQ3wBSgt66lTJv169fjKYj1SGRkJELo
woULJKS4uNjW1hYh5Ovr6+fn5+Tk9PLlS4qioqKizMzMDh8+TFFUdHQ0QigvLw/PX9i2bZtC
oSguLp43bx5CaOXKlWKx2NbWtlevXjKZDPen3Lhxg6Ko3Nxcc3NzqVQaGxtrbm7u4OAQExOj
UCjI1TWFkxNXrFiBELKwsNiwYcORI0dCQkJYLNaff/65a9cub2/v9PR0vLm5l5eXllt2cXEh
yszJyWn06NE7d+68e/fu3bt32Wz2l19+mZKSsmXLFoTQq1evKIr68ccfceR9+/bpkk5lZSWO
s2fPHicnp2rN2L17N4/HQwhxOJzr169rf02nTp0aOXKk9jgAUF9ERET8+eefxrYCaOh89913
UVFRxrailpi6nli3bt3y5cvrN82ysjJvb+8WLVoIBAIccvDgQYRQo0aNioqKxGJxp06d+vTp
U1xcbG1tzePxwsLCvvnmGycnJ1dX18rKyqVLlzo7O6tW/EeOHPH19V29ejVCqEOHDvPmzbO0
tORyuT/++CNFUcXFxQghLFDu378fFBSEEGrfvn1cXJxSqcQpVBtOTpw1a5aZmdndu3fJFdeu
Xcvn87dv387n8xs3bjxw4MDff/8dIfT69etqb3nSpElWVlYjRoyYOnUqQigtLY38FBER4eDg
UFhYSFGUTCZbs2aNVCqlKOqXX36xtLTk8/kzZ87UJR3C/Pnze/ToUa0ZpaWlbDYbaxEOh3P1
6lUtr+n48ePh4eFaIgBAPTJq1KgTJ04Y2wqgoTN79uxdu3YZ24pa0hD7O6ytrY8ePZqfnz9w
4EA8ZCE7Oxsh1KJFC3t7ew6HM2nSpPv37x87dszCwiI2NjY7O3vfvn3NmjVLTEw0NzcvLi7m
crlqVv3zzz/r1q1r3br106dPo6Ki/vjjj9DQ0Ly8PISQnZ2dmZkZnnvp5+eXnJz84MEDNze3
kSNH9u7dG495rDacnGhpadmsWbOuXbuSy0kkErlcXlhYKBAIeDzeqVOnwsPDWSzWhw8fqr3l
vXv3fvz4MS4ubsOGDQghSmXJqZycHH9/fwcHB4SQmZnZqlWrcJWflZXl7Oy8aNGiffv2JSYm
lpeXa08H8/Tp04MHD44bN65aM2xsbLp160ZuYciQIVo6PsD/DBgSyG+AKQDjJ/QIpZ/1MTt3
7rxv37579+4FBgY+f/48Pz/fzs4uLS0NDxQ4fvy4o6NjZmbmF198ERISkpGRUVFRkZaW1qZN
G4SQSCRSKpVqCSqVylGjRo0aNaqysnLOnDlhYWGenp54kAGDwXB0dHz//r1SqRwzZkxGRoav
r++5c+euXbuWk5Mzc+ZMTeHkxMDAwOzs7GXLll2+fPnYsWMhISGbN2/et29fUVERQig6OprD
4XA4HDc3tydPnlR7vxYWFlwuFyGEZ4uoRuvYseOlS5d+/fVXrBgIv/32W6tWrRYsWBAYGDho
0CAbG5ucnBwt6YjF4oiIiPbt2zs4OEycOFHTk588ebK1tTU+1i4pYL1twJDQu98a+FygdT40
dT2hVCr1oScQQuPGjYuOjn78+HFISIhUKh0yZEhkZOSuXbt69+5taWkZHx/v7e19+/bt+/fv
q51IUVRubq5EIiEhrq6uTZo02b17t6ura8eOHXHbfdCgQX///TeO0LNnT3d3d4TQrVu3AgMD
x40bt2TJkri4OLFY/ODBAy3h+MQRI0YsW7bswIED/fv3nzZtmoWFxa1bt8LDw7lcbv/+/fv1
64evEhQUVHUFKjWYTCaTybx58yYJ2bhxY48ePb777jtHR8cBAwasWrUqKSlJqVS2bdt2xowZ
ZmZmFy5ciIiIsLOzw3NbNKXz+vXruLi40aNHX758WTWmGkOHDpXJZORfLCmqXZcC1tsGDAn4
JwBTgNZ6wtTHT6xatWrNmjX6S//s2bONGzcOCwubMmWK2k8ikcjDw6Nx48ZHjx7NysrKyso6
e/bsokWL8HPLzs6uxeUKCwtnzpzZpEkTBoPB5/ODg4Pv3bunJVw7FRUVBQUF5N+XL1+eOnXq
k2cdOnQoKytLNUShUMTHx48ZMwbP4GCxWJmZmbVIR0eIACJUO5Zi796906dPr0X6AFALBgwY
kJiYaGwrgIbOpEmTDh48aGwraomp63GlUoknL+iJIUOGvH//fvLkyVW9IFwu9/Lly5MmTYqI
iCCBlpaWAQEBgwYNcnFxqcXlHBwc9uzZs2fPHh3DtWNhYeHs7Ez+bdGiher6EJqo2hnBZDKH
DRs2bNgwhNC7d+/kcrmrq2st0tGRyZMnp6amlpWVkRDspUhISOjduzcJhPYiYEjo3S4EPhdo
nQ9Nvbym9DN+Qg17e3u8boQanp6et27dysjIyMnJYTKZXl5ePj4+etU3RkdVoOiJoUOHTpky
RS2wqqSg9XcF0A7Qr4ApAOMx9YhhHq6LiwtZOaoqfn5+eGuudu3afd5iwjBwudygoKCqMlFt
LAWU74AhAf0KmAK0zoemXl4bxj/RrVu3hQsX/v333506ddL3tXRBKpUW/Ut5eblYLK6srBSL
xTKZTCQS4b9yuRxPdtUdDoeDR0qam5vjdaUQQnZ2dvgJq/1qZWXFZrN5PJ65ubmdnR2LxcJL
ftULc+bMuX37tkgkUguXSCShoaHYSwF6AjAktC7Hgc8GhUJBX/+EqZfXhvFPdO3atVOnTq9e
vTKYnigvL8/Nzc3NzX39+jU+ePPmTXFxMdYQUqlU++lmZmZk1iVCiMViad82DEsQfFxSUkJV
WTdCR/B8USw1rK2tzczM+Hw+vrqlpSWetspms+3s7PBSYFwu19bW1sbGBh/b2NjY2toymcyQ
kBBra+uqegKpdHyAngAMCegJwBRQKpX0zYemXl6r6on8/Pzi4uJGjRo5ODjUb78Dk8nMyMio
xwTVUCgUWVlZ//zzz+PHj//73/8+fvz41atXZBELc3NzV1fXpk2buru7+/n52dvb43t0cHCw
t7fHHgLyV01J1AXs9kD/V20IBAKEUHl5uVQqxRFKS0sVCkVJSQmOJpVKy8vLsZukpKREoVAI
BIL8/HyxWCyRSCoqKsrKyhQKhZbrcjgcLpeLZXjVlTwQQhKJZNCgQYGBga1ataqXOwWATwJ6
AjAFaJ0PTV1PqPZ3/Pbbb2vWrMHHtra2jRs3xvUu/ov/VQ1p1KiRscyWSCSPHz9++PDhgwcP
Hj58+PjxY7xehbm5ecuWLf38/CZOnOju7u7h4dG8efMmTZoYJQNxuVy8OBVCqHHjxvWYMhYc
ZWVlpaWlYrFYJBIJhcKSkhJ8LBKJBALBx48fz5w5oymFioqKq1ev1mgbWACoC7Qux4HPBlqP
xzR1PaH6cCMiItq2bfvx48fCwsLCwsKioqLCwsK3b98+evSoqKhIdYEpDJPJtLW15fP5dnZ2
tv9CjskBn8/HbnzVv7rYJhQKS/8lPz8fd1vk5OQ8f/78+fPnuI1ub2/v6+s7a9YsX1/f9u3b
+/j4WFhY1O8jMkHYbDabzdau51JSUq5du4aXG1eDw+H07t2bz+c7OTnpzUYA+D+AngBMAVrn
Q1PXE6r+iZYtW7Zs2VJTTIlEgnXGhw8fsNQoKioSCAQlJSW4yn/16hU+Likp+eR11bRF1cGP
1Y5CsLOza968eevWrUePHu3r6+vr69u8efMa33PDICkpqdphIhwOZ+TIkYcPH162bFk9jgAF
AO3Qul0IfDbQOh+aup7Q/eFyOJxmzZo1a9ZMl8hEWJSWlgqFQtzxX+3fak+3tLRUdXjY2dk5
OTk1b94c6j/d+f333/HoDVUsLCx8fHz279/PYDBordMB2gH5DTAFaJ0PPx89USOwCADngbG4
fv266vqYGAaDYW9vf+nSJdwlBPM7AENC63Ic+GygdT40db+KYdafAAzM6tWrxWKxWiCXy71y
5QreOR2BngAMC63LceCzgdb9HaZuN60fLlAt//zzT0ZGhtroEy6Xe/ToUbwjPAb0BGBIQE8A
pgCt86GpV9WgJz4/1qxZU1FRoRrC5XJXr149ZMgQ1UBaf1cA7YCiBjAFaJ0PTd1u6O/4zHj9
+vXFixdVF7zicrlhYWELFy5Uiwn+CcCQgH4FTAFa50NT1xO0FmtAVTZt2qS6JiaHwwkICNi/
f3/VmKAnAENC63Ic+GygdZVn6naDf+JzQiAQHDp0iHR2WFpatmnTJiEhoVrdIJfLoXwHDAbo
CcAUoHU+NHU9QWuxBqixa9cucmxpaenj43PlyhU2m11tZIVCAf4JwGDQuhwHPhtonQ9NvaoG
PfE5sXv3brxEmJWVVfv27VNSUrRsiwr9HYAhgaIGMAVo7ZI39e+H1g8XUCUtLQ3vYsrhcDp2
7JicnMzj8bTEBz0BGBJatwuBzwZaV3mmrieg0fDZcObMGYlEwuVyv/rqq+vXr3M4HO3xoXwH
DAnkNwCoI6ZeVdNarAGqJCYmUhS1cuXKo0eP6rLJKvgnAEMCegIA6oipl9fgn/g8kMvlBQUF
58+fDwkJ0f0U0BOAwbh7964uMhcA9Aqtm9CmXl6Dnvg8KCoqun79eqtWrXQ/BfQEYEg6duxo
bBMAgN6YenlNa7EGEJycnJycnGp0CvifAQAAaISpN/3BP9FgAf8EQCOmTZvWt2/fhISEqhvn
AkADwdSravBPNFhATwA04syZM1evXh06dKi1tfXAgQMTExPJT0lJSY0aNdqwYcOLFy8+mY5A
IMjJycnJycnNzS0uLlZdnB5oCNC6yjN1PQH+iQYLrLcN0AWxWNy0adPRo0cvW7Zs+PDhd+7c
GThwYI8ePXJzcxFCEomkqKho+fLl3t7eLVu2XLRo0cuXL1VPz8rK2r9//4wZM3r27Ons7Ozh
4eHh4eHu7u7g4MBisRgMBoPBMDMz2717t3FuDwB0w9Tbf6AnGiyw3jZgXAoKCi5dujRx4sRP
xly6dOnbt2/v3r1rZWWFECoqKtq0aVNkZGTv3r3v3LkzfPjwwYMHJyYmLliwIC0tbdu2bVu3
bg0PD4+Ojr58+fLy5cuzsrIQQi1btnR2dq6srAwLC4uIiKjaSP3iiy/0cZsAUF+YenlNa+cP
UBegvwMwDEKh8MKFC/fv32/fvv348eNJeGpq6rRp08aOHfvJfMhmswsLC9++fevl5YUQcnBw
2Lx581dffdWzZ88ff/xxz549LBYrODh448aNCKH8/Pz4+PiNGzd27969RYsWr1+/XrNmzejR
o1u2bIkQsra2joiIGD58uD7vGAD0gqmX1+CfaLCAnmiAFBUVbdmy5c2bN76+vlOnTuXz+Tg8
NTX16tWrzs7OY8eOtbS0rHX6aulkZ2dv3749JiZGKBQihNzd3VX1BEJILpcLBAJHR0ftyTZr
1ozBYDRq1GjLli0DBw5s27atVCqtqKgwMzOTSqUIoWfPno0ePRpHbtKkyTfffNO1a9fOnTuH
hITs3bvXxcWFJFVZWWlubl7rGwQAY0KZNqGhoefOnTO2FYAR8PT0fPHihbGtAAyHTCYLCAgg
RZObm1taWhpFUfPnz0cIOTg4IISCgoJIfKlUmpCQsHbt2p9//vnQoUMlJSXHjh2zs7PLz88n
cXbt2vXq1St8XDWdQYMGIYT8/f3T09MrKytVjREKhZs3b0YI9ejRw9vbG7dq4uLiqrV8586d
jRo1un37tlrpOmDAgA8fPkilUiaTOXz48J07d27evHnixIkdO3ZksVgODg7p6emq6VRUVCCE
EhIS6uNxArSkbdu2jx8/NrYVtcTU9cTAgQMvXLhgbCsAI9C8efOcnBxjWwEYjoSEBITQtm3b
FApFcXHxvHnz/Pz8oqKizMzMDh8+TFFUdHQ0QigvL4+iqN27d6v1hM6fP//bb7/l8XgikYik
6ejouG3bNoqiqk0nNjbW3NzcwcEhJiZGoVDgUyIjI11cXIhb1MnJafTo0Tt37rx7966a5iBs
2bKlZcuWcrkcuzfMzMx++eUXohX+/vtvnJSZmZm/v/+kSZN++umnEydOlJaWqqWjUChATzRw
aK0nTN2fDP0dDRbo72ho3Llzx9nZee7cuUwmk8/nb9++XSAQNG/enM1mJyQkpKWlnTp1ytXV
1cnJaf78+du3b2/RosWkSZOCg4PXr1+flJRkY2Pz5MmTDh06cLlcnODp06c/fvzYr18/gUCw
fPnyqumEhYV5eHjMnz9/woQJW7duXb169fDhwx88eFBSUjJs2DA+n3/gwIGEhAR/f3/tlpeV
lbHZbBaLFRMT06lTp8WLFx87dmzcuHH41//9738WFhZ///13mzZttKfDZDItLS1LS0vr/jAB
wPCYelVNwXjMhgroiYZGcXExl8tVbT8cO3bMwsIiNjY2Ozt73759zZo1S0xMNDc3v3btWkBA
QFZW1sqVK1++fHn58mUulztv3jw2m/327VvcyheJRCtWrAgPD2/Xrp2mdBBCfn5+ycnJDx48
cHNzGzlyZO/evTdv3vzx48e4uLgNGzYghCiK+qTlXC739evXeCWruXPnJicnv3r1qlu3btnZ
2Qih3NzcRs2J85EAACAASURBVI0afVJMYCwtLT9+/Fir5wcARsbU9QT4JxossN52Q0MkEqkt
35SZmfnFF1+EhIRkZGRUVFSkpaXhWrlVq1bPnj3bsWPHlClTpkyZYm1t3bZtW2tr6wkTJuTk
5IwbN27v3r0BAQFyuRx3bWhKR6lUjhkzJiMjw9fX99y5c9euXcvJyfn++++xh8PGxgYh9OTJ
k09a3rRp05KSkhs3buB/AwICHjx4wOVye/XqVVRUJBAIdBElGAaDgaePAg0TWjehTb2qpvXD
BeoC+CcaGhRF5ebmSiQSEuLt7X379u379++rxVy3bp2Li8vixYufPHly8+bNr7/+msfjIYR6
9+4dHR195syZJUuWdO3a9datW3Z2dlrSQQjdunUrMDBwxIgRzZo1i4uLE4vFDx48wD8xmUwm
k3nz5s1PWu7t7c3j8VS3u2vatOm5c+c4HE5eXp5AIHj37h2eQvJJWrduDTuTATTF1Mtr8E80
WEBPNDSmTJkiEok4HA4JmT59+s6dO0NDQ3fs2NG5c2eE0P/+97+UlJSbN28yGIznz597eHgg
hK5fv56WloZPmTFjxowZM9RS1pKOUqkMCgq6ffv2hw8fjh492qFDh59//hmfZWFh8fvvv3fr
1u2Tlnfp0qWqXGjatOnTp08RQgEBAQ8fPrS2ttblIdy9e1eXaABgihhzMKgOBAUFJScnG9sK
wAhYWVlJJBJjWwEYmRcvXgQGBqoWWZaWlgEBAT/99JNUKsVx7t27hxC6efNmrdP53//+16pV
K4PcEABoo02b/8fenYc1ce7/w7+zkIQskBAQZLEsCqgVEbAqIiBuIHVBqCLVU7e2tra2/qp+
UavVnlOsUrXWqlRcKlaxhyLuolSLQl1YqigFRdkVREjCkgQIIXn+mKdz5bCJkSQz5PP6gytM
JpM7Q5h5z+e+Z2Z4fn6+oVuhJaIf/6mhv8NYQX0CIIRcXFwyMjJyc3PLysqoVOrgwYPd3d07
XPFpzJgx77zzDjYSwtraWovlwGAdQBCk3uURfXsN/R1GC/IEwHl7e3t7e/cww7Fjx+Lj4zXH
XrzSciBPAPD6iL69JnVYA1pTqVTYbRUN3RBADkwm85NPPtH65ZAnAHh9RD/0h/qEcYLiBNAn
yBMAvD6i76ohTxgnyBNAn2A7A8DrI/q/EPR3GCelUgnHi0BvXF1dDxw4YOhWAEDuXR7R8wQc
Nxin9vZ2qE8AvTE3N/f09DR0K7Sxe/fubdu2GboVACBE/DxB6rAGtAb9Hf1Vdnb2nDlzrl27
ZuiG9BMVFRXR0dFnzpwxdEMAIHyegPqEcYI80S/l5eVNnjzZ3d3d39/f0G3pJ2JjY4OCgtav
X6/u9S1CgD6VlpYaugn6Q/RdNdQnjBOMt++XVq5c6e3tHRMTA2GxOytWrDh48GDv56dSqd9+
+21BQcG5c+d01yqgtdOnT79SNY7UuzzIE4CIoD7R/+Tl5d24ceP777/Xz9uFh4eHhYXp84V9
Qq1WZ2ZmdpioUqny8vLy8/O7fMno0aMDAgJgPCkxzZ8/PywsLD093dAN0Qei5wlgnCBP9D+/
/vqrj4+Ph4eH3t7x9OnTJ0+e1OcLu1NdXX306NHezDlgwICysjL8V4VCsW/fvsGDB48ZM+b/
/u//Kisru1zOypUrL1269OzZs75qMOgrNjY2fn5+U6dONYYxQ5AnABFBnuh/rly5gt3bUz+S
kpISEhLMzMywX5uamn799dc1a9YcO3ZMc7bO0zu8sE/cuXNn2bJlSqWyNzM3NDRgD3Jzc728
vFavXj1z5swnT55cuHAhNze3y+XMnj3bzs4uMTGxD9sM+srnn3+uVCpnzJjR76sUsMkGRATj
J/qfhoaGXu5QMXfu3Ll69aqNjc27777LZDIRQiKRKDY29unTp56enkuXLhUIBD28nEqlLly4
ECFUUlKyc+fOhIQE7Jbijo6OPU/HX9i3lEqlRCKxsrLSnJifn3/69Gkul/vBBx/gN2pXqVRS
qfTrr7/etWvXuHHjzp496+zs3PNyqFTq1KlTL1++vHr16j5vOXhNkydPHjhwYFVVVWho6Llz
54KCgnqYmdxd/Ia5rWmvjRw58t69e4ZuBdC3e/fujRw50tCtAH1p3LhxI0aM6DAxIyPDy8vL
3Nw8Ojr66dOn+PQvvvgCISQUChFCAQEBarW6ra1t3Lhx+IbLwcEhKysLm/nZs2cvXrxQq9UV
FRXx8fHYRJVKhW06pk+fjhAaPXp0dna2QqHA36K76fgL1Wp1cnKyjY0NQohCofj6+qanp6vV
6gcPHvz3v/9Vq9XfffcdlUr97bffev7gTU1N27dvRwhNmDBhyJAh2AlrycnJ58+fx3ISQigw
MBCb+auvvuLxeHZ2dgwG48svv2xvb3/pcrBnv//+excXl178HYABxMTEYHmRzWZfvXq1hznd
3NwePnyot4b1LaLnCQ8Pj7y8PEO3AuhbTk6Ot7e3oVsB+tLu3bsRQhcvXsSniMVic3NzhJCn
p6e3t7e1tXVxcbFarf7hhx/odPrRo0fVanVcXBxCqLKyEjt/YceOHe3t7WKxeNWqVQihjRs3
ymQyc3PziRMntrW1Yf0p169fV6vV5eXlJiYmzc3NSUlJJiYmQqEwISFBc/fc3XT8hV9++SVC
iMFgxMTEHDt2LDg4mEajHT9+fO/evUOGDMnOzsZudz548OAePvLAgQPxM96tra0jIyP37Nlz
69atW7dusVist956KzMzMzY2FiFUWlqqVqs3b96MzYwHo56Xgyeh/fv3W1tb99HfCvSx2tpa
FouF/fl6jhSQJ3QI8oRxun379ltvvWXoVoC+1NjYOGTIEGdnZ4lEgk05cuQIQsjS0lIkEslk
Mi8vr0mTJonFYh6Px+VyIyIiVqxYYW1tbW9vr1Ao1q1bZ2Njo7njP3bsmKen51dffYUQGjly
5KpVq5hMJofD2bx5s1qtFovFCCEsoOTk5AQEBCCEPDw8kpOTVSoVtoQup+Mv/Oijj+h0+q1b
t/B3/PrrrwUCwc6dOwUCwYABA0JCQg4fPowQqqio6PIjL1q0yNTUdM6cOUuXLkUI4QUVtVod
FRUlFArr6urUanVbW9uWLVuam5vVavWuXbuYTKZAIFi+fHlvloP74osvJkyYoN2fBujBzJkz
8UTIZrP/+OOPLmeDPKFDkCeM059//unr62voVoA+lp2dzWKxxo4d29jYqFarN27ciBDCg+MP
P/xgbm6+d+9eoVB46dIlLy8vBoMxevTo/Px8tVr94YcfdqjnHzt2jEql0mi0oUOHMhgMGo2W
lJQ0d+7cpUuXqtVqlUqFFzkwd+/eDQ0NxToX6uvru5uOv/Dzzz93dnbWfMfo6Ggej7d+/XqE
kLOzs0wmk8lkNBotJyeny8/b2toqlUrVanVNTQ1C6M6dO/hTvr6+wcHBnV/y0UcfvfHGG1u3
bqXRaJcuXcJCRg/LwRQUFFhYWPz0008v+QMAw0lNTcWqcT1HClLnCTi/AxARnN/RL/n4+MTH
x9++fdvPz+/x48dVVVV8Pj8rKys6Ojo9Pf3kyZNWVlb5+fnDhg0LDg7Ozc1tbW3NysoaPnw4
QkgqlapUqg4LVKlUc+fOnTt3rkKh+OyzzyIiIlxcXB4/fowQolAoVlZWNTU1KpVq/vz5ubm5
np6e58+fv3btWllZ2fLly7ubjr/Qz8+vpKRk/fr1aWlpiYmJwcHB27dvj4+PF4lECKG4uDg2
m81msx0cHAoKCrr8vAwGg8PhIISws0U0Zxs1atSVK1d+/PHHlpYWzZccOHDAzc1t9erVfn5+
06dPNzMzKysr62E5MpksKirKw8NDKBS+9957ffBHAroRFBSkOR5ZLpeHhoZ2PolUTebxmJAn
ABFBnuivFixYEBcX9+DBg+Dg4Obm5hkzZuzevXvv3r1BQUFMJjMlJWXIkCF//vlnTk5Ohxeq
1ery8nK5XI5Psbe3t7W13bdvn729/ahRo2JiYhBC06dP/+uvv7AZ/P39HR0dEUIZGRl+fn4L
FiyIjo5OTk6WyWR3797tYTr2wjlz5qxfv/7QoUNTp05dtmwZg8HIyMiYN28eh8OZOnXqlClT
sHcJCAjofAWqDqhUKpVKvXHjBj5l69atEyZM+PTTT62srKZNm7Zp06bLly+rVKo333zzww8/
pNPpFy9ejIqK4vP5+JjNLpdTUVGRnJwcGRmZlpamOScgGhMTk9DQUM2sIJfLZ8yY0a+uS2Ho
AslLjBgx4v79+4ZuBdC3K1euTJkyxdCtALpy9uzZAQMGRERELFmypMNTUqnUyclpwIABJ06c
KCoqKioqOnv27Nq1a7HtVUlJiRZvV1dXt3z5cltbWwqFIhAIAgMDb9++3WE6m83Gp/estbW1
uroa/7W4uPilp3io1eqff/65qKhIc0p7e3tKSsr8+fOx00FpNBrWs/OqywFkcfbs2c7XNenQ
8eHq6vro0SPDtfG1UNTEvouMh4fH8ePHR4wYYeiGAL26dOnSnj17Ll68aOiGAB1avHgxjUbr
fLuK4uLiRYsWaR70M5lMLy+v6dOnr169Gh8n34fi4+Ozs7MNeMnq58+fK5VKe3t7QzUA6EFz
c7OFhUWHHi6EEJvNxq9L4ebmdu7cOVdXV0M08HVBSRkQEfR3GAMLC4va2trO011cXDIyMnJz
c8vKyqhU6uDBg93d3bGTM3tDpVLhl5jspaamJuw6Ua/0Kpxara6vr+9hBj6f32WnOJVKxcbo
YVe5AP2bqalpQEDAlStXOhzGYx0fFy5cwC5DQt7xE7DJBkQEecLgWltbscEKvXnQ0tLS3Nzc
yweY+vr6srKy6upqfCBCY2Nje3u7ZhtkMplCodCc0mEhCKG2tjapVNonHxk7f5Ug6HQ6j8fr
8il8eGZnpqam3dVvOBwOg8F46Us0rzrKYrFMTU3xXzVTEZPJxC/oiRAyNzfHT4bs0DwzMzP8
WrcmJiZcLhd/isfj4f/mPXze/mTVqlU3b97ELsmqCRueSfabxMImGxARXG/7lbS3tzc2NjY2
NspksubmZmw3LJVK29rasJ00dnqkRCLBjt2VSmVTU5NCoZDJZFgmaG5ubmlp0XxhnzQM3wN1
foAQolKpUqm0oaEBO0bHu5a5XG6HakTn3WTnfWrPO6QedrQIoT/++KOmpiYyMvKVPp12sFXd
5VOd8xOuc9jCYX/cztN7qNNgXwDsMVaV0ZyCENL8DnR4Sj80vwM0Gk1z2IFmMGKz2dgoVDzf
4F8DCoXC5/Ox2fBvHZ5gevlCPCd1/k5qZ+rUqTwer8v1iVUper6KPMFBngBEhNcnampq5HK5
vb19n/wzE1xLS0v9P6RSqUQiwa5wIJVK6+vrscdNTU0NDQ3YYyxDSKXS7vZPnQkEAqzGjm09
sb2ymZkZm83G9rjYxhrfeuLb09486DI09EClUo0ePfr//u//wsPDtVxlfaSlpaW4uPiDDz4w
bDNIQTNqYEEWf0ozD3VIM3K5vLW1FXvcoXuoQ8DS7HXqXNPCkxNeG9NcWkNDA3ZSMd7IHtKb
dvBg+qpBBH/h0KFDa2tru4zsWLI/dOjQ+++/7+Li0ofN1g+i5wlSdyYBreF5Yv/+/Vu2bKHR
aLa2tm+88YaTk9Mb/4vg58g1NTWJxWKRSFRXVyeRSOp71MOGDztEMzMz43A4XC7XzMzM2tqa
w+FwOBxzc3Mej4c95vP52GYLO/zCtmVYwbmX+3h9olKpubm5hm4FQgipVCq8XA96ptlhgRCy
tLQ0VEteCVaNQ/+bgfDsgpd/OgeRXr4Qz1JYBpJIJD2/sDtqtXrbtm0sFgu/8jqJED1PAOOE
93fMnTvX0dGxrKysrKysvLw8MzPz5MmTmtF+4MCBjo6OdnZ2AwcOtLKysrW1tba2HjBggK2t
7YABA7rsMH59jY2NYrFYIpGI/5dIJMJ/Yg+6PAphMBh8DQ4ODgKBgP+/zM3NORwOj8fDHuji
pAaAgzzR7zEYDHxrYNgMdOPGjZCQEM0rqeBoNJparY6JiZk7d67+G/b6IE8AIsLrE8OGDRs2
bJjmU+3t7VVVVWX/KC8vLy8vLygouHbtGnbnBU0WFhY2NjYWFhampqZ8Pp/D4bDZbB6Ph1X4
NQeU4bDjEmwUQmNjY1NTE9a5gPVBYDGiy/tuczgcCwsLoVBoYWExbNgwS0tLi39gEy0sLLCs
0OX7AgOCPAH0Q61Wv//++12GCSaTaWtrq1arw8PDnZyc9N+21wd5AhBRD+d30Gg0BwcHBweH
CRMmdHiqtbW1tra2qqqqpqampqamurr6xYsX1dXVDQ0N9fX1VVVVWB1Ssyu3B5qdCBwOZ8CA
AYMHD7b4XwKBAH9M8J4X0APoVwX6cf78+aqqqs7T2Wy2p6fnxYsXsXvkkhTkCUBE2p0vymQy
7e3te3NRIKxHUyqVmpiYdM4B+FUBgJGA+gTQj40bN3Y+vZnD4YSGhv7yyy9kH3VO9DwBxw3G
Sdfni9JoNIFAQOpTs0AfgjwB9CAvLw+7WZ0mLpc7e/bso0eP9oNvIOk/AOiX4HpWQJ/guAXo
wc6dOztcX4TD4cydOzchIQEPExQK0W+C0QPIE4CIIE8AfYL6BNA1uVyelJSkOZQbCxMHDx7U
zLJUKhW7hAYZwb8QICLIE0CfIE8AXTtz5ozmNs3U1NTf3z8+Pr5DYQzqEwD0MbjeNtAnlUoF
/R1Ap/bt24dfZtvExMTd3f3UqVOdt3JQnwCgj0GeAPqkVquhPgF05/nz5zk5OfivXC734sWL
XV6kDuoTOgTjpIwT9HcAfYLtDNCp5ORkPLCy2eyzZ892d4d6qE8A0McgTwB9gvETQKd+/vln
7JqYHA5ny5Ytfn5+3c0J9QkA+hj0dwB9gjwBdEcsFufn5yOEWCzWxIkTV69e3cPMpK5PwCEg
ICKoTwB9gv4OoDvnz5+n0+mmpqZDhw5NTEzseWaoTwDQxyBPAH2C+gTQnaNHj8rl8oCAgIyM
jA53e+8M6hM6BMcNxgnyBNAnFxeXAQMGGLoVoB+SyWT5+fmHDh1atGhRb+YndX0CNtmAiGD8
BNCnDz74wNBNAP1TXV1dbm5ub25SiIH6BAB9DOoTAIB+4I033nil+Uldn4AuQ0BEkCeAMVuz
Zs2BAwcM3QpgAKSuT0CeAESkVCqhvwMghJYtWzZ58uRz587JZDJDt0V/UlJSLl26ZOhWAAOA
+gQAfay9vV3r+kRFRUVZWVmfNgcYzJkzZ65evTpz5kwejxcSEpKamoo/dfnyZUtLy5iYmCdP
nrx0ORKJpKysrKysrLy8XCwWE/kQUKFQlJWVtbW1GbohwACgPqFDcH6HcdK6v+PQoUPe3t5W
VlZ93iSgfzKZzM7OLjIycv369WFhYTdv3gwJCZkwYUJ5eTlCSC6Xi0SiDRs2DBkyxNXVde3a
tcXFxZovLyoqOnjw4Icffujv729jY+Pk5OTk5OTo6CgUCmk0GoVCoVAodDp93759Xb57eHh4
WFiYHj5mB4WFhe3t7VKpVP9vDQyO1PUJ6KIGRKRFnpDJZGFhYVevXvXz8+NwODpqGNCndevW
PXv27NatW6ampgghkUi0bdu23bt3BwUF3bx5Myws7O23305NTV29enVWVtaOHTu+++67efPm
xcXFpaWlbdiwoaioCCHk6upqY2OjUCgiIiKioqI6H58MGzasuwacPn365MmTkZGROv2YHVRV
VSGELCws9PmmgCBIXZ+APAGI6FXPF5VKpePHj3/8+LGpqenChQt11zCgTywWq66u7tmzZ4MH
D0YICYXC7du3z5o1y9/ff/Pmzfv376fRaIGBgVu3bkUIVVVVpaSkbN26dfz48c7OzhUVFVu2
bImMjHR1dUUI8Xi8qKioV6o3JCUlHT9+3MzMDPu1qanp4sWLOTk5Hh4emt+x7qZrDRspYm1t
/fqLAqQD9QkA+tir1ieWLFny+PHj5uZmFos1Y8YM3TUM6NOgQYMoFIqlpWVsbGxISMibb77Z
3Nzc2tpKp9Obm5sRQo8ePcKLB7a2titWrBg7dqyPj09wcPBPP/00cOBAfFEKhcLExOSV3p1K
pWL5oKSkZOfOnQkJCU1NTQghR0fHnqe/1J07d65evWpjY/Puu+8ymcwOz7a0tCCEJk6c+Eqt
Bf0DqesTRB8/AYzTK+WJw4cPX7p0CdvBDB48GA7s+hOhUFhQULB27doRI0ZQKBQ2mz1p0qSJ
EyfGxsa2tLQUFRXl5eX9+OOPsbGxixYt8vLyGjNmjFAojIyM7BAmFArFq761Wq3Oy8tDCH36
6ad79+51d3fPzs5WKBSlpaXYDN1NP3nypEAgqK6uxhe1b98+fIzw6tWrx44du3PnzqVLl06b
Ng2buH//fhMTEw6Hc/jwYSxPTJ8+XYvVBcgO8oQOwXhM49T7PJGfn79y5Ups8Jqpqel7772n
46YB/WlpabGwsBgzZgx23E+n03ft2pWdnZ2ammplZVVYWKhSqVJSUlatWpWUlEShUObMmXPi
xImSkhIfHx/N5Wg3treysnL06NEtLS2LFy82MTEpKSkpLCzU7Ibrbvqff/6pVCrxjhKE0ObN
m0+dOoUQ2rNnz+7du48ePVpXVxcXF3f9+vWnT58ePnz4448/dnFxCQkJefz48R9//IEQ6ly3
AMaA1P0dSE1sbm5uDx8+NHQrgL75+fllZGS8dLaGhgZ7e3v8Tk4sFuvZs2d6aB7Qj40bN3p4
eGCPd+3axWAw3nrrrdraWmzKiRMnGAxGfn5+bxbFZDJ/+eWXV3p3sViMECouLlar1Tk5OQEB
AQghDw+P5ORklUqFzdPl9Hnz5o0fPx5fTkpKCkLo/v37YrGYx+NxudyIiIgVK1ZYW1vb29sr
FIpRo0ZNnz69tbVVrVbfvXsXiyZXrlx5pdaC/mHatGmpqamGboWWiF6fAMapN+MxFQpFcHBw
XV0dXh4cNWqUra2t7lsH9ITD4VRUVGDjEz///PP09PTS0lJfX9+SkhKEUHl5uaWl5fDhw3uz
KCaTWVtb+0rvzufz6XR6ZmYmQsjb2zs9Pf3u3bsODg7h4eFBQUENDQ3dTcdybXt7O0JIKpV+
+eWX8+bNGzFiRGJiIoPBSEpKKikpiY+PHzRoUGpqqomJSWVl5aJFixgMRnV1dXh4eGBg4MyZ
M0+fPv2qqwv0A6SuT0CeAET00v4OtVo9f/78vLw8rLMZIcTlcr/++mu9tA7oiZ2dXX19/fXr
17Ffx40bd/fuXQ6HM3HiRJFIJJFIer/lpVAo2OmjvUehUKysrGpqalQq1fz583Nzcz09Pc+f
P3/t2rWysrLly5d3N/1f//pXWVnZggULfvrpp3HjximVyri4OIRQfn7+sGHDgoODc3NzW1tb
s7KysDBkYWGxbdu2L774wsvLi0KhHD9+/P33309MTMSGeQKjAuMnAOhjPdcn1Gr10qVLL1++
LJfLsSkcDmfhwoWTJ0/WVwOBPgwZMoTL5bq5ueFT7Ozszp8/z2azKysrJRLJ8+fPe7nTHTp0
6KhRo161Af7+/o6OjgihjIwMPz+/BQsWREdHJycny2Syu3fvdjc9KCgoLi7uzJkz0dHRY8eO
zcjI4PP52Mf5888/c3JyOrzLN998U1RU9MMPP/j6+v7555/W1tZvv/32rFmzKisrX7XBgOxI
XZ+A8ROAiEaOHHnv3r0un2pvb4+KiupwxSoulyuTyfTcSGBYhw8fHj16dJ8sqqqqqrm5uYcZ
6urqli9fbmtrS6FQBAJBYGDg7du3e5jeJalU6uTkNGDAgBMnThQVFRUVFZ09e3bt2rVjx459
8803S0pK+uSzAFKbMWPG2bNnDd0KLRH9+hNqOL/DKHVXn8DCxIULFzTvDkWlUiMiIthsth4b
CAxv8eLFixcv7pNFrVq1KiwsbN68ed3NIBQK9+/fv3///l5O7xKHw0lLS1u0aFFUVBQ+kclk
enl5zZs3T/MEV2C0SF2fIHqeAMapyzzR3NwcFhaWmZnZ4VaTXC53yZIlemwd6G9UKhV+lpBO
ubi4ZGRk5ObmlpWVUanUwYMHu7u79/5CW3K5vLW1Vbu3ViqVHfqGOBwOg8HAf6VQKFi/DDAg
Uo+fgDwBiKhznhCLxVOmTCksLMSuW6VJrVb7+vrqsXWgv9FpHVQqldZ348KFC42NjW1tbdgF
VJqbm7HxxY2Nje3t7Wq1ur6+HiGEz6BnTCazQ9mPx+NpDpSm0Wial9lACJmamrJYLPxXExMT
LpeLPRYIBB0WwmKxsDuzaC6Hz+djfws87jAYDKx/UzPxmJmZYZuIDu9IdlCfAKCPdcgTpaWl
AQEBNTU1na9ySKFQgoODX+lmHwB00Cf1iefPnz958gS7JXpFRQX2s6ysrHMCxnC5XD6fb25u
ju0Ozc3NTU1NORyOubk50tiX47tVfEeLEKLT6Twe7zUbjGtoaNA8Ju5cyehcF5FIJJq/KhSK
DlXDpqYmpVKJEHrx4oVUKsVuv97a2oqNoVapVNgJt31Ic53g2YXL5WLlH2w1UqlUbPXiKQSb
E1/b5ubmVCoVj0FY9MHjDrYQPNboIspAfQKAPobnidLS0vT09M8++0wmk3X5b8bj8fR8+0fQ
/2iRJ6RS6cOHD+/fv//gwYMHDx7cv39f8/oWNjY2gwYNevPNN0NDQ62trbHcIBAI+Bq0u2pn
/4OnGTy14PUYvEKDNAJKS0sLFtHa29sbGxuxZ+vr67HDeplMhh114BEHzy5YmhGJRNg74u+C
L1lrfRJKsLxYXV2dl5fn6enp4uLyOk0yCKJ/oWE8pnHC88TRo0e3bNnSw5yNjY0LFizA/iHx
Eij2740fr3Q+1MPmxP+l8TnxAiw+J7ZpwOfEtxH4nKAf6DlPNDc3V1ZWVldXY5fW/vvvvwsK
CsrLy7EdGIfDGT58+KxZs0aMGOHu7v7GG2+88cYb/akCr2tYwQBpFBUMAk8nWCLBowzeCYVF
FrzEtXcc8AAAIABJREFUgvVJ4aEEq8HgC8GyEbYQiUTS3UK6dPPmTSqVunnzZn187D5F9DwB
jBN+PauFCxfy+fx169bh163qgE6njx071svLC6vQ4scu+GEKdizSuSsan/M14QVVLHngBVU8
eeC9v0ij51izw5jNZuM3a8Br2q/0KnxD3LnDG3QH+yZIJJKmpiaRSPTXX3+1trZivzY2NlZU
VFRXVz99+rSqqkqzts9isYYOHerr6/v+++8PHTp0xIgRzs7O+hnLCXSKRqNh/0f6jDWdQ8ma
NWv8/f01zwAiEcgTgIjw+oSLi8vnn3/u4+MTEhLS5ZA0pVL58OHDq1eval3Hwjt3seSBV0c7
j5LD58QOMvA58coqPideQcXLsJo90Pj+qefDlNeEV2s0+5U1UwgefTR1GHCHusooWr/w9XUe
mYj/UfA1jCdF/O+CDwjA/mRNTU1NTU0dEuqff/6JP6bT6TY2Ng4ODm5ubpMmTbK1tbW1tXVw
cLC3t3dycoLBOqCv4IcHAwYMwB4IhUJnZ2cnJyfDNUp7kCcAEXUYj+nn53fp0qXuIoVMJvvj
jz+CgoK0e6/O488NAo8gmr3CL00h2PEN+t8xdHhtRrP7uctX4fDcg79L5yF4XZ5lgL/QgDTL
NvgfESsXoX+CjkAgwPqwGAwGj8czNzc3Nzfn8XjYDbq2b98eFRU1bdo0bEqHcxYA0Bs4vwOA
Ptb5fNEeIkVTU9OOHTu0zhMEoTlc39LS0oAteU09BxHNEwhfUx8u6uDBg25ubu7u7n2yNAC0
Bud3ANDHuryelZ+f37lz50JDQzv0EajV6qtXr9bX18PVeIiAzWZ37ubAy7nEpLfrWQHQM1LX
J4j+LwTndxin7q63HRgYePny5c5HpSYmJnB/Z6A1yBOAIEhdn4B/IUBEPdxfFOv46BAppFLp
oUOH9NI00A+pVCo4bgFEAPUJAPpYz/crxzo+OtxiNDs7WywW675poB9Sq9VQnwBEAPUJAPpY
z3kCIRQYGHj+/HnNfnro8gBag/4OQBBQnwCgL2HF55fWnzuMpYAuD6A1yBOAIKA+AUBfemlx
AtdhLMVff/0FXR5ACzDuGxAE1CcA6Eu9zxPon7EUWMcHnU7/7bffdNk00D9BfQIQBNQndIjU
Kxdo55XyBNLo+JBKpd9++y150z0wFMgTgCCgPqFDpF65QDuvmieQRpWitLT0jz/+0FHDQH8F
/R2AIEh9CE30PEHqlQu0o0WeQP9UKZhM5rZt23TRKtCPQX0CEASpD6GJ/i9E6pULtKNdnkAI
+fn5paam3rx588mTJ33eKtCPQZ4ABEHqQ2ii/wuReuUC7SiVyg53vu69wMDAS5cuHTlypG+b
BPo3yBOAIEh9CE30+4GReuUC7Whdn8D4+fmZmpq2tbWZmJj0Yav6mTVr1gwZMuSDDz4wdEMI
AcZPAIIg9SE00SM5qVcu0M5r5gmEkLe3N4SJnqWkpFy6dMnQrSAKyBOAIEh9CE30PEHqlQu0
8/p5AvRMoVCUlZW1tbUZuiEAgP9B6kNooucJUq9coB3IEwih8PDwsLAwHS28sLCwvb1dKpXq
aPkAAO2Q+hCa6HmC1CsXaAfyBOb06dMnT57UxZKrqqoQQhYWFrpYOABAa6Q+hCb6eExSr1yg
HSPME01NTRcvXszJyfHw8Fi4cCFCKCkp6fjx42ZmZrp4O5lMhhCytrbWxcLJCMZPAIIg9SE0
0fMEqVcu0I5R5YmSkpKdO3cmJCQ0NTUhhBwdHbE8QaVSsQe60NLSghCaOHHiS+fMz88/ffo0
l8v94IMPNO8ODwDQBVIfQhO9v4PUKxdox6jyxKeffrp37153d/fs7GyFQlFaWopNV6vVeXl5
+Gy3bt1av379lStX8Cn5+flJSUkIoR07dtBotOTk5J7faP/+/SYmJhwO5/Dhw1iemD59OvbU
qVOnBg4cSKFQqFTq+PHjr1+/jk2/cOGCj4/Pxo0bV61aFRoa2ncfGgDQNVIfQhM9T5B65QLt
vM71rEhn8eLFJiYmJSUlhYWFmimqsrJy9OjR2I7/iy++GD9+/NatW6dNm1ZZWdnc3IwQunHj
xoYNG3JyctatW6dSqaKjo3t4l8OHD3/88ccuLi4hISGPHz/GbnHCZDIRQhs3bgwPDxeLxTEx
MQkJCWZmZpMmTTpx4kRubm5ERMTIkSMzMzNjY2PT09PLysp0uioAAKQ+hCb6VpvUKxdox6jq
ExEREU5OTl988cW//vWv77777quvvgoLC6NQKDwer62traqq6uzZszt37ly1atU333wjFosb
GhqGDBly9uxZpVJZV1cXGho6efLkd955Z8mSJZWVlQ4ODl2+y48//jh9+vSUlBQGg3Hv3j0f
Hx+EUHp6+pQpU0QiEZ1Ov379+tixYxFCCxYs+Pe///3JJ59MnTqVw+FcvHhRKBSOGTNGLpfb
2NjoddUAYHxIfQgN9QlAOEaVJxBC3t7e6enpd+/edXBwCA8PDwoKamho4PP5dDo9MzMzJSXF
1tZ2x44dpqamdnZ2hw4dam1ttbKykkgkEomEy+X+9ttv8+bNo9FoL1686O4tKisrFy1axGAw
qqurw8PDAwMDZ86cefr0aYQQk8kcNGgQFiYwcrlcqVQWFxePHj1aKBQihOh0+qZNm1gslh7W
hkHAeExAEBQKhbyH0JAnAOEYVZ5QqVTz58/Pzc319PQ8f/78tWvXysrKli9fTqFQrKysampq
pk6dWlVVNXv27G+++WbatGk7d+4MCgoaNWpUdXU1QiguLo7NZrPZbAcHh4KCgu7excLCYtu2
bV988YWXlxeFQjl+/Pj777+fmJjY1NTk5+dXUlKyfv36tLS0xMTE4ODg7du3x8fHjxkz5sqV
Kz/++CPW5wIA0AMqlUreXR70dwDCMao8gRDKyMg4ffp0eHi4vb29VCqVyWR3795FCPn7+zs6
OoaFhVVUVJw6derKlSv29vYIoQULFiCEOBzO1KlTp0yZgi0kICAgMzOzu1NCvvnmmyVLluTl
5c2cOXPfvn3W1tZvv/32rFmzKisr58yZs379+oMHD27dupXNZk+aNCkjI8PX13f69On5+fmf
fvrpunXrfH19x4wZM378+ClTpsB9swDQHXIfQquJLTAw8I8//jB0K4Be/f7775MmTTJ0K/Sn
rq5u+fLltra2FApFIBAEBgbevn27yzkfPnyIEHry5IlarW5tba2ursafKi4u/u233/q2Ye3t
7SkpKfPnz3d2dkYI0Wi0/Pz8vn0LghgxYsT9+/cN3QoA1P/5z382bNhg6FZoCeoTgHCMrT4h
FAr379+/f//+l8755MkTe3t7FxcXhBCDwdAcIOns7Izt9fsQlUqdPXv27NmzEULPnz9XKpVY
gaT/UcP4CUAMpK5PED1PkHrlAu0YW57ovcrKymHDhhnkreHkDgD0gNSH0ETvCiX1ygXaUSqV
kCc0/fDDD/fu3UMIPXz40M3NzdDNAQDoCql3eUTPE1CfMELt7e3Gcz2rl6qurv7ss89mzZpV
VFR08+bNN954w9AtAgDoCuQJHSL1ygXagf4OTQMHDty8eXNVVZWbm1t2dva4ceMM3SIAgK6Q
epdH9DwB9QkjBHmig6+++iotLc3BwWH+/Pm+vr6Gbk4/BOMxAUHQaLT29nZDt0JLRK8qkzqs
Ae1AnugsMDCwuLjYxMTE0A0BAOgQqfME1CcA4UCe6JIewsTu3bu3bdum63cBAHQH8oQOQX3C
CEGewGRnZ8+ZM+fatWt6e8eKioro6OgzZ87o7R0BAJpIvcsjep6A+oQRgjyBEMrLy5s8ebK7
u7u/vz82ZdmyZZMnTz537pxMJtPRm8bGxgYFBa1fvx7+6QAwCKhP6BCpwxrQDuQJhNDKlSu9
vb1jYmLwU2fPnDlz9erVmTNn8ni8kJCQ1NRUfObLly9bWlrGxMQ8efLkpUuWSCRlZWVlZWXl
5eVisVjz/4tKpX777bcFBQXnzp3r80+kNy0tLVlZWa/0EhiPCQiC1HmC6OMxoT5hhJRKpZFf
fyIvL+/GjRt5eXn4FJlMZmdnN3nyZGdn54cPH/7++++pqal+fn6//PLLG2+8IZfLRSLRhg0b
NmzYMGTIkNmzZ3/44YfYZbkxRUVFN27cyM7OLiwsvHPnjkKh6PymNBrthx9++PjjjwMCAg4c
ODBz5kx9fFQdYLFY//3vf6VSaVBQkKHbAsCrIfUhNNG32pAnjJBKpTLym1j++uuvPj4+Hh4e
+JR169Y9e/bs1q1bpqamCCGRSLRt27bdu3cHBQXdvHkzLCzs7bffTk1NXb16dVZW1o4dO777
7rt58+bFxcWlpaVt2LChqKgIIeTq6mpjY6NQKCIiIqKiojofkWMX8165cuU777zz7NkzOzs7
PX7ovvTBBx94eXmdP38+MDDQ0G0B4BVAfUKHSB3WgHagv+PKlSujR4/WnMJiserq6p49ezZ4
8GCEkFAo3L59+6xZs/z9/Tdv3rx//34ajRYYGLh161aEUFVVVUpKytatW8ePH+/s7FxRUbFl
y5bIyEhXV1eEEI/Hi4qKCgsL6+7dZ8+ebWdnl5iYuHr1ah1/UF1xdXX19fWdOnVqamoqVCkA
iZA6TxD9KBDqE0YI6hMNDQ1KpVJzyqBBgygUiqWlZWxsbH5+PkKoubm5tbWVTqc3NzcjhB49
euTn54fNbGtru2LFijNnzvz999+urq4lJSWbNm3CwgRCSKFQ9HzqKZVKnTp16uXLl3Xy2fQl
Ojq6ra3t7bffTk9PN3RbAOgtKpVK3jwB9QlAOJAnrKys7ty502GiUCgsKChYu3bt2rVr8YnT
pk2LjY1taWkpKirKy8v78ccfm5ub//777/v379+/f18oFEZGRg4cOBCfX6FQdDl4ooMRI0aQ
fTccFBTk4uJSXFwcGhp64cKFnjs+YDwmIAgajUbeXR7Rt9pQnzBCkCciIyMfPHhw6dIlfEpL
S4uFhcWYMWMWLlyIEKLT6bt27crOzk5NTbWysiosLFSpVCkpKatWrUpKSqJQKHPmzDlx4kRJ
SYmPj4/mkns50JXJZEql0r79UPq3Zs0aLpcrl8tDQ0PJHo+AkYD+Dh2C+oQRgjyxePHiIUOG
fPLJJ/X19diUxsZGFotFo9ESEhJ27dpFpVITExMdHR2xZx8+fMhgMPLz89va2rKyso4cOfLl
l1/OnTvXzMysw5KpVCqTyWxoaOi5AU+ePMH7R8grPDy8ra0NIYRFCn1eGQwA7UCe0CGoTxgh
yBM8Hu/EiRNVVVUhISFNTU0IIQ6HU1FRgV3J6vPPP09PTy8tLfX19S0pKUEIlZeXW1paDh8+
vDcLZzKZtbW1PcxQWFh45MiRBQsW9MVHMSRLS0tPT0/ssVwunzFjBkQKQHCkPoQm+lab1CsX
aAfyBELIx8cnPj7+9u3bfn5+jx8/trOzq6+vv379OvbsuHHj7t69y+FwJk6cKBKJJBJJ72M3
hULBTh/tTCaTRUVFeXh4CIXC9957r28+iUEtXbqUy+Vij7FI0WXHB4yfAAQB9QkdgvqEEYI8
gVmwYEFcXNyDBw+Cg4NdXFy4XK6bmxv+rJ2d3fnz59lsdmVlpUQief78OVbJeKmhQ4eOGjWq
y6cqKiqSk5MjIyPT0tKYTGbffAyDmjNnDtblgYGOD0BwpM4TcH4HIBzIE7gPP/zQ1tZ22bJl
Xl5eneOCnZ1dYWEhQmjcuHH37t3j8Xi9WeatW7e6e2ro0KGtra2v02CiEQqFXl5emh8Zq1Kc
O3cOrksBCIjUuzyib7WhPmGEVCoVFJ9xM2bMqKmp6blasHjx4le9Y4XxWLZsGd7lgYGxFICw
SF2fIHqeIHVYA9pRq9VQnwB9Zfbs2R0uDoZ6HEsBgAFBntAhqE8YIejvMCpyuVzyv8RicUlJ
CTYupDdX3+qZhYVFUFBQ54qX5lgKGI8JCILUeQLGTwDCgTzRnyiVysrKSvwO6aWlpbW1tfX1
9RKJBPv50hEbFAqFz+czmUw2m83j8ZhMppmZGYfDEQqFQqHQ0tISe2BhYYE/YDAYmkv4f//v
/2VkZHQegIKPpejjzwyAtki9yyN6noD6hBGC+4GRl0KhePToUUFBwd9//11YWPj3338/efIE
P8OCRqPZ2dlZW1sLBAIHBweBQMDn8wUCAZYVOi+tubm5paWloaGhtbVVKpXKZLLW1tb6+vrW
1tYXL17k5OSIxWLs9iUd8Hg8oVBoZWVlbW1tbW1tZ2fXXULFIoVQKOzDlQCA1qA+oUOQJ4yQ
Zn2ioqKitraWy+WampryeDwzMzOIGsTR2NhYXFz86NGj/Px8LD0UFxdjgxXodLqzs/Pw4cPD
wsJcXFwcHR0dHR0dHBx6vhWZFuRyuUgkEovFIpGorq5OJBLhv4rF4urq6r/++uvFixedh1Bo
LqG5uXnXrl2rVq3SPCMXAP2DPKFDpC7+AO1o5onDhw9v2bJF81nsWFYgELDZbDabbWZmxuVy
2Ww2l8s1NzfHJvL5fA6HY2pqamZmxuPx2Gw2h8Ph8/lsNpvFYhniM5FbU1PTs2fPampqKioq
iouLnzx5UlxcXFxcjF9nk06nDx48+M0333znnXeGDx8+dOhQd3d3/VzBAvuLOzg49DCPSqW6
d+/e2LFjNa9FoUmtVv/00082NjabN2/WSSsB6B1S7/KIniegPmGENPPEggULfHx85HJ5fX29
TCaTy+VNTU1NTU1yuVwmk9XX12OHpw0NDfizPS+cSqWam5tzOBysM97MzIzFYnG5XAaDweFw
sLDCYrFMTU2xn9gDNpvNZDI5HA6DweByuSYmJjwej06nk71e0tTU1NDQ0NDQUF9f3/CP+vr6
mpqa58+fYxni6dOncrkcfwmNRnNwcHBxccEKDy4uLq6urm5ubh2GLBAKlUqtra1ls9ld3riE
w+FQKJT4+PiAgAD9tw0ATVCf0CFShzWgHc08MXjw4MGDB7/SyxsbG+VyOXbWQHNzs1wub2ho
kEqlcrlcKpU2NDRg9W2JRILN9uLFi6dPn2J983K5vKWlpcsu+R5gqcLc3JxKpfL5fAqFojkg
AMsf2GPsWYQQnU7HLz+FRRbsMRZTXundEUJSqRQ/8m5qalIqldinUKlU2B60sbGxvb1dc6JE
ImloaOjun4vH42EDHUaPHh0aGmpvb4+NQhg4cKCTkxORo0N3UlNTu7xjqqmp6ZQpUwoKCry8
vDRv7A6AQUCe0CGoTxih1zy/w8zMrPN9NV8VNhJQLpe3trbKZDKFQoH9xPbc2D4b20lje+X6
+nq1Wo39lEgk2EKwl2O/YjNjnw4/SsYSzGs2tTOsmoJHFizEYHUXLpfL4/FYLJa5uTmfzzc3
N8ceCAQC839gJ1P0easM69dff+28maZQKFZWVseOHfP29jZIqwDoAPKEDkF9wggR4XxRrKdD
IBDo7R2xvII9xnJJd2c99ACvfwBN169f77IjjM1mX7p0qcPVMwEwIFLv8oieJ6A+YYSIkCf0
j8PhcDgc7LE+c0y/p1arP/roI+xW75o4HM6hQ4eGDRtmkFYB0CVS1yeIvtUmdVgD2jHOPAF0
5NixY5WVlR0OSzgczieffDJv3jzsV7g+JiAIyBM6BPUJIwR5AvQVpVK5evXqDiMx2Wx2cHDw
1q1bDdUqALpD6kNoom+1Sb1ygXYgT4C+kpKS0tLSojmFxWL5+PgkJiZCQQIQENQndAjqE0YI
8gToK7GxsZojMVkslpub28WLF/v8Mp0A9AnIEzoE9QkjBHkC9ImqqqoHDx7gv7JYrKFDh2Zk
ZODjXgEgGsgTOgT1CSMEeQL0iV9++QXv1GCxWCNHjszIyMAvI6YJxmMCgiD1ITTRt9qkXrlA
O5AnQJ84cuQIdqlTNpvt4+Pzxx9/QGUCEBzUJ3QI6hNGCPIEeH01NTVlZWUIIQ6HM2nSpLS0
NFNTU0M3CoCXgDyhQ5AnjBDkCfD6zp07p1ar2Wz2J598cubMGbivLCAFUpfk4fqYgHAgT4DX
l5CQ0NbWtnPnzo8//tjQbQGgt0hdnyB6nqBSqfiNE4GRgDwBXpNcLn/06FFqauqUKVN6Mz8c
twCCgDyhQ/B/boQgT4DX9PDhw99//33EiBG9nJ/URWbQn1CpVMgTugL/50YI8gR4TV5eXq80
Pxy3AIKg0Wjk3eURfasN/+dGCPIE0DM4bgHEQd5vI9G32uRds0BrkCeAnsF2BhAHeYdQEH2r
Td41C7TW3t5Oo9EM3QpgRIwhT4SHh4eFhRm6FeDlyLvXI3qeMIb/c9AB1CeAnhnJdub06dMn
T57sYYbq6uqjR4/qrT2viuDN6yvk/TYSfatN3qQGtAZ5AugZebfgvZeUlJSQkGBmZtbDPHfu
3Fm2bJlSqdT6XZqamn799dc1a9YcO3ZM64V05/WbRwrk3esR/fwOOp3e7789oAPIE0DPjCFP
UKnUhQsXvnQ2pVIpkUisrKzwKSKRKDY29unTp56enkuXLhUIBF2+sKSkZOfOnQkJCdgN4h0d
HXvzdnfu3Ll69aqNjc27777LZDKxifn5+adPn+ZyuR988AGbze65ef0PefME0bfa5F2zQGuQ
J4CeGUOeUKvVeXl5CKH8/PykpCSE0I4dO2g0WnJyMjaDVCp9/PgxQig8PNzV1ZVGo1EolP/+
978zZszYtm3b8ePH16xZM3LkyOzs7FOnTg0cOJBCoVCp1PHjx1+/fh0h9Omnn+7du9fd3T07
O1uhUJSWluJvnZmZ6e3tzefz161b9+zZM3z66tWrx44du3PnzqVLl06bNg2beOHCBR8fn40b
N65atSo0NBSfucvmnTp1StfrTf9I/G1UE9uBAwfef/99Q7cC6JW/v//169cN3QpgRMaMGXP7
9m1Dt0K3ysvLTUxMmpub9+7dO2TIkOzsbBMTE4TQ4MGDd+/ePXDgQDzEW1tbR0ZG7tmz59at
W9gOe8eOHe3t7WKxeNWqVdg8DAYjJibm2LFjwcHBNBrt+PHjSUlJJiYmQqEwISGhvb0df1+x
WGxubo4Q8vT09Pb2tra2Li4uVqvVP/zwA51OP3r0qFqtjouLQwhVVlbm5OSwWKy33norMzMz
NjYWIVRaWtpD8xQKhcFWqM5YWVm9ePHC0K3QBtHzxKFDh5YsWWLoVgC98vPzy8jIMHQrgBEZ
N27czZs3Dd0K3RKLxQih4uLi3bt3CwSCAQMGhISEHD58GCE0adIkU1PTOXPmLF26FCGUlZWF
v2rdunU2Njaa+eCjjz6i0+m3bt3Cp3z99dcCgUCpVObk5AQEBCCEPDw8kpOTVSqVWq0+cuQI
QsjS0lIkEslkMi8vr0mTJonFYh6Px+VyIyIiVqxYYW1tbW9vr1AooqKihEJhXV2dWq1ua2vb
smVLc3PzokWLumtev2RjY1NdXW3oVmiD6FVlGo0G4yeMDfR3AD0jcYW51/h8Pp1Oz8zMlEgk
EomEy+X+9ttv8+bNo9Fo//73v2tra5OTk2NiYhBCao1LCIrFYg6Ho/n/yGQyBw0aNHbsWHyK
XC5XKpXt7e3e3t7p6el37951cHAIDw8PCgpqaGgoKSlBCDk7O1tYWLDZ7EWLFuXk5CQmJjIY
jKSkpJKSkvj4+EGDBqWmppqYmJSVlY0ePVooFCKE6HT6pk2bWCzWTz/91F3z+iXy9vITfatN
p9NJumaB1iBPAD0zhjxBoVCsrKxqamqqq6sRQnFxcWw2m81mOzg4PHnyhMPhIISwsz8KCgrw
V0ml0g5rxs/Pr6SkZP369WlpaYmJicHBwdu3b4+Pj6fT6fPnz8/NzfX09Dx//vy1a9fKysqW
L19eVVXF5/OzsrKio6PT09NPnjxpZWWVn58/bNiw4ODg3Nzc1tbWrKys4cOHI4RGjRp15cqV
H3/8saWlBX9HBoPRXfP6JfJ+G4m+1SZvUgNagzwB9Iy8W/BX4u/v7+joyOFwpk6dit95NSAg
IDMzE3tMpVKpVOqNGzfwl6jV6vLycrlcjk+ZM2fO+vXrDx06NHXq1GXLljEYjIyMjHnz5iGE
MjIy/Pz8FixYEB0dnZycLJPJ7t6929raOmPGjN27d+/duzcoKIjJZKakpAwZMuTPP//Mycnp
0MKtW7dOmDDh008/tbKymjZt2qZNmy5fvoz/aTo3r18i716P6OeLknfNAq1BngB6ZiR5AruY
1axZs7CxFJhNmzbdvXsXe8xgMA4fPuzr64s/u2TJEqlUqnnSJoVC+eabb7755psOC6dSqXl5
eV9++eXZs2erq6v5fP7IkSO//fbbPXv2MBiMlStXrly5Ep/Zyclpz549oaGh33//vY+PD0Lo
4cOHmZmZN27caGxs3LlzZ3Z29p07d65cuUKj0fLy8rDqRefm9Uvk3etBngCEA3kC6JmR5AkM
g8GwsbHBf3V2dnZ2dsZ/fe+99zRnnjRp0qRJk3q5ZKFQuH///v3792tOjIuLo1AoHebkcDhp
aWmLFi2KiorCJzKZTC8vr/nz53/00UfYiSTPnz9XKpX29vbdNa9fIu+3keh5Aq5nZYQgTwA9
g/sY646FhUVtbW3n6S4uLhkZGbm5uWVlZVQqdfDgwe7u7tgprDjN3GM8yHsUTfQ8Qd41C7Sm
Vqs7H9AAoDvkPSIkvoEDB/7+++/dPevt7e3t7a3P9hAfefd6RD8KJO+aBQCQBeQJ3fH19b1/
//5ff/1l6IaQBnn3epAnAADGDvKE7owdO9bLy0vz8tugZ+T9NkJ/ByAc6O8AekbeLTjxUanU
3NxcQ7eCTMi71yN6fQLGYwIAdA3yBCAOyBO6Qt41CwAgC8gTBrd79+5t27YZuhWEQN5vI+QJ
AICxg/NFO8jOzp4zZ861a9f09o4VFRXR0dFnzpzR2zvqgUKh0OJV5N3rQZ4AhAPjJ4CekfeI
UBfy8vImT57s7u7u7++PTVm2bNnkyZPPnTsnk8l09KaxsbFBQUHr16/vT8GutLRUi0xG3r0R
TU+jAAAgAElEQVQe0fMEjJ8AAOga5AlNK1eu9Pb2jomJodP//wH7Z86cuXr16syZM3k8XkhI
SGpqKj7z5cuXLS0tY2Jinjx58tIlSySSsrKysrKy8vJysVisuc6pVOq3335bUFBw7ty5Pv9E
huLm5nbgwIFXjRRUKhXyhE6QN6kBAMgC8gQuLy/vxo0b33//PT5FJpPZ2dlFRkauX78+LCzs
5s2bISEhEyZMKC8vRwjJ5XKRSLRhw4YhQ4a4urquXbu2uLhYc4FFRUUHDx788MMP/f39bWxs
nJycnJycHB0dhUIhjUajUCgUCoVOp+/bt2/06NEBAQEHDhzQ80fWqTVr1syYMSM9Pb33L6HR
aCT9NsL5ooBwoL8D6BnkCdyvv/7q4+Pj4eGBT1m3bt2zZ89u3bplamqKEBKJRNu2bdu9e3dQ
UNDNmzfDwsLefvvt1NTU1atXZ2Vl7dix47vvvps3b15cXFxaWtqGDRuKiooQQq6urjY2NgqF
IiIiIioqqvM/+LBhwxBCK1eufOedd549e2ZnZ6fHD61D3t7e48ePnzp1ampqalBQUG9eQt69
HuQJAICxgzyBu3LlyujRozWnsFisurq6Z8+eDR48GCEkFAq3b98+a9Ysf3//zZs379+/n0aj
BQYGbt26FSFUVVWVkpKydevW8ePHOzs7V1RUbNmyJTIy0tXVFSHE4/GioqLCwsK6e/fZs2fb
2dklJiauXr1axx9Uf2JiYkaPHh0aGnrp0qXAwMCXzk/evR70dwAAjB3kCVxDQ0OHIWuDBg2i
UCiWlpaxsbH5+fkIoebm5tbWVjqd3tzcjBB69OiRn58fNrOtre2KFSvOnDnz999/u7q6lpSU
bNq0CQsTCCGFQtHhjl8dUKnUqVOnXr58WSefzUB8fHyGDRvW0tISGhram44P8n4biZ4nYDwm
AEDX4HxRnJWV1Z07dzpMFAqFBQUFa9euHTFiBIVCYbPZkyZNmjhxYmxsbEtLS1FRUV5e3o8/
/hgbG7to0SIvL68xY8YIhcLIyMiBAwfiC1EoFL05f3LEiBH97+Lc7733nqmpqVwuDw0Nfenw
TPIeRRM9T5B3zQKtwfgJoGfkPSLsc5GRkQ8ePLh06RI+paWlxcLCYsyYMQsXLkQI0en0Xbt2
ZWdnp6amWllZFRYWqlSqlJSUVatWJSUlUSiUOXPmnDhxoqSkxMfHR3PJ+NkiPWMymVKptG8/
lMFFRERgD+Ry+UuHZ5J3rwd5AgBg7CBP4BYvXjxkyJBPPvmkvr4em9LY2MhisWg0WkJCwq5d
u6hUamJioqOjI/bsw4cPGQxGfn5+W1tbVlbWkSNHvvzyy7lz55qZmXVYMpVKZTKZDQ0NPTfg
yZMneP9Iv+Hs7Gxvb489fmmVgrzfRsgTAABjR94teJ/j8XgnTpyoqqoKCQlpampCCHE4nIqK
CuxKVp9//nl6enppaamvr29JSQlCqLy83NLScvjw4b1ZOJPJrK2t7WGGwsLCI0eOLFiwoC8+
CrEsXboUO0EG/VOl6C5SkHevR/Q8AeMnAAC6BnlCk4+PT3x8/O3bt/38/B4/fmxnZ1dfX3/9
+nXs2XHjxt29e5fD4UycOFEkEkkkkt4PPaFQKNjpo53JZLKoqCgPDw+hUPjee+/1zSchkqio
KM1fe4gUkCd0hbxrFmgNxk8APYM80cGCBQvi4uIePHgQHBzs4uLC5XLd3NzwZ+3s7M6fP89m
sysrKyUSyfPnz7FKxksNHTp01KhRXT5VUVGRnJwcGRmZlpbGZDL75mMQiYODg5OTk+aU7sZS
kHevB9efAAAYO8gTnX344Ye2trbLli3z8vLqHBfs7OwKCwsRQuPGjbt37x6Px+vNMm/dutXd
U0OHDm1tbX2dBhPf8uXL161bp3kPFGwsxYULFzSvS0HebyPUJwAAxg7OF+3SjBkzampqeq4W
LF68OCsrS29NIrWFCxd2Dgqdh2eSd68H9QlAONDfAfSMvEeERNPW1vZKZ3s2NTXhI+TYbDae
Xbhcbs9XviIjPp8fGhp66tSpDl82rOPj3Llz2AW5ybvXI3qegPGYAABdgzyBaWlpkXSvubm5
sbGxvb29ubm5paVFqVRi/SANDQ0qlUoul+uow4LH4+HXrjAzM6PRaNhjPp+PH3gIBALsAYPB
4HA4dDqdx+NRKBQ+n4/Pib2Ww+EwGAxTU1MWi9XDzLr4IAihzz77LDU1tXPk0owU5P02Ej1P
kDepAQDIgrxbcO1UVVUVFxeXl5dX/gN7jF9zogNzc3OBQCAQCKhUKpvNNjU1NTMz43K56J8d
OVZOYDKZbDYbewm229aibTKZDL+Mpmb1Aosy2GMswWCPJRIJ9kCtVmPtVygUMpmsvb29sbER
n/iqOocPrHwiEAiwj2lmZsZkMnk8HofDYTKZfD6fxWKZmpqam5szmUwul8vlcplMprm5ueZi
/fz8LCwsuizh4JGCvHs9oucJLCdCARwAoDt4nqiqqhKLxUKh0NLSst/U29va2u7du3fv3r38
/PwHDx7k5eWJxWL8WSsrKwcHB2dn54kTJ9rY2FhYWAj+F5/Pp1KJPtLupbAIggUULLK0tLQ0
Nzdj4QOrteDho76+Xq1Wa86MlWQaGxtra2ubmppkMllra2svkwoWR/h8PpPJ5HA4JiYm3SUG
uVw+ffp0Ly8vKyurPv78ekH0PIH+6fLoN//b4KUgPgI9w/PEgQMHtmzZgk00MzOzsrKytLQU
CoVYwsB+WllZ4b8KhUJibpqqqqru3Llz8+bN27dv5+bmYjfu4vF4b775ZkREhIeHh5ubm4OD
w6BBg/CLLPVvWJ0A7xbpK1goaWhoaG1tlUqlUqm0tbW1oaEByx/19fWtra0ymaypqamlpQUL
IqamptilwLrU2tp669atDlUNsiBBnsCiHDH/aQEA/QCeJ6KiokaMGFFbW1tXVycSifCfBQUF
IpGoy6ssmJmZDRgwAMsW5ubmfD4f+4kd2WtOMTc319HOu62trbS09NGjR48ePcrNzb1582ZF
RQVCiMVieXl5ffTRR76+vqNGjXJycoKk3rdYLBaLxXqlmHLnzp1p06Z1ed1xJpMpFApHjRrl
5eXVd23UH9LkCUO3AgDQb+Hni7q6uvZw84jW1laRSIQljA6ZQyQSvXjxoqioqL6+vqGhoa2t
rcslYB3qfD6fx+OZm5tTqVRsUIK5uTk2KhAbIYj1xHd+uUqlamhowEZNisVi7GddXV1paSn+
jg4ODr6+vqtWrRo7dqyXl5d2gxiA7ly8eLGlpaXzdA6HM2XKlOPHj3/11Ved735CCpAnAADG
rpfjMZlMpq2tra2t7UvnlMlkDQ0NWLbQ/CmRSPBflUqlRCIRiUQNDQ1Y/z3Wl9+bBmP1DwsL
CwsLC0dHx3feecfV1dXNzW3IkCEWFha9WQIwCJVKdfDgwc4nwnA4nPDw8CNHjlCpVPLu8iBP
AMKB8RNAz/r8/A4Oh8PhcHqTPDrDuuTlcrlareZwOJ1nwAobr91GYABJSUmde804HM67774b
FxeHbffIe5UEEuQJ8q5cAAApEOp8US265AEpqNXq6OjoDnmCw+FMmzYNDxMIIRqNRtJdHglC
LtQnAAA6RaFQiJMnQH915swZkUikOYXFYo0cOfLkyZOaFVny7vIgTwDCgf4OoGdUKhXu3wF0
7auvvtIsTtDpdDs7u4sXL3Y4e5FOp5N0lwd5AgBg7AjV3wH6pYyMjOLiYvxX7PLe6enpnS81
Qd4ufnLkCZKuXAAAKUCeALq2efNmuVyO/8rlcq9fv25vb995TvIeQpMgT5C3+AMAIAUYPwF0
qry8/NatW3ifGpvNvnDhwrBhw7qcGeoTOkTesAa0A+MngJ7RaDTIE0B3EhISNMPE/v37J0yY
0N3M5N3lQZ4AABg72MgAnYqPj8euiclms9euXfuvf/2rh5mhPqFD8K8OANAp8m7BAfEVFRVh
p4my2ezZs2d/9dVXPc9P3m8jCfIEeVcuAIAU4KAF6M7FixfVajWLxRo1atTPP//80vnJ+20k
QZ4g78oF2oHxE0DP4KAF6M7JkycVCsWwYcM6X2qiS+T9NkKeAAAYO/JuwQHBtbe3i0SikJCQ
jIyMXt41lLy7PBLcv4O8KxcAQAqQJ4CO0Gi0x48fv9JLyPttJEd9gqQrFwBACnDQAoiDvLs8
EuQJuJ6VsaFQKHAzBaBP5D0iBP0PeXd5JMgTcOhgbOAvDvQM8gQgDvJ+GyFPAMKBvzjQM/Ju
wUH/Q94NIOQJQDhwcyagZ7CR0Vp4eHhYWJg+X9jvkTfdkiBPkHflAu3Axh3oGWxkXsfp06dP
njypzxf2b+TdAML5ooBw4C8O9AzyhNaSkpKOHz+OX1mhqanp4sWLOTk5Hh4eCxcuxGfrPL3D
C19Jd+/SP5D32wh5AhAO9HcAPSPvFvz13blz5+rVqzY2Nu+++y6TyUQIiUSi2NjYp0+fenp6
Ll26VCAQ9PByKpWK7dFLSkp27tyZkJDQ1NSEEHJ0dOx5Ov7CV9Ld0voT8n4bSdDfAXnC2MBf
HOhZv//KZWZment78/n8devWPXv2DJ++evXqsWPH7ty5c+nSpdOmTUMIKZXKGTNmbNu27fjx
42vWrBk5cmR2djY2c1VVVW1tLUKosrLy4MGD2ES1Wp2Xl4cQ+vTTT/fu3evu7p6dna1QKEpL
S7EZupuOvxAhdOrUqYEDB1IoFCqVOn78+OvXryOE8vPzk5KSEEI7duyg0WjJyck9LK0/Ie+3
EfIEIBz4iwM9I+8RYW9IJJK33377r7/+cnJySktL8/b2LikpQQjt2bNn9+7dR48erauri4uL
u379+tOnT1NTU2/durVjx4729naxWBwREfHWW29t2rRJLpcPGzZs3rx5SqVyzpw577///o0b
NxBClZWVo0ePbmlpWbx4sYmJSUlJSWFhIY1Gw9+9u+n4Czdu3BgeHi4Wi2NiYhISEszMzCZN
mnTixIkbN25s2LAhJydn3bp1KpUqOjq6h6X1JyT+NqoJ77333vv5558N3QqgPxMmTLhx44ah
WwGMyO3bt8eMGWPoVujKkSNHEEKWlpYikUgmk3l5eU2aNEksFvN4PC6XGxERsWLFCmtra3t7
e4VCsW7dOhsbm/b2dvzlx44d8/T0xO6yPXLkyFWrVjGZTA6Hs3nzZrVaLRaLEULFxcVqtTon
JycgIAAh5OHhkZycrFKpsCV0OR1/4UcffUSn02/duoW/49dffy0QCHbu3CkQCAYMGBASEnL4
8GGEUEVFRQ/v0m/cu3dv5MiRhm6FNqA+AQgH/uJAz0h8RNgLWDXC2dnZwsKCzWYvWrQoJycn
MTGRwWAkJSWVlJTEx8cPGjQoNTXVxMRELBZzOBwq9X92Dffv3//Pf/4zdOjQwsLCH3744Zdf
fgkNDa2srEQI8fl8Op2emZmJEPL29k5PT797966Dg0N4eHhQUFBDQ0N30/EXMpnMQYMGjR07
Fn87uVyuVCrr6uokEgmXy/3tt9/mzZtHo9FevHjRw7v0G+T9NkKeAIQDf3GgZ/37K1dVVcXn
87OysqKjo9PT00+ePGllZZWfnz9s2LDg4ODc3NzW1tasrKzhw4cjhKRSaefR0CqVau7cuXPn
zlUoFJ999llERISLiwt2mysKhWJlZVVTU6NSqebPn5+bm+vp6Xn+/Plr166VlZUtX768u+n4
C/38/EpKStavX5+WlpaYmBgcHLx9+/b4+HiRSIQQiouLY7PZbDbbwcGhoKCgu6Xpf63qDnnz
BJzfAQgHzu8AekbeLXhvtLa2zpgxw8fHZ8OGDdu3bw8MDExJSUlLS/vpp59ycnJ8fHw0Z1ar
1eXl5XK5nM1mY1Ps7e1tbW337dv322+/jRo1KiYmBiE0ffr0PXv2YDP4+/s7OjoihDIyMk6f
Ph0eHm5vby+VSmUy2d27d3uYjr1wzpw569evP3jw4NatW9ls9qRJkzIyMnx9fbOysqZOnTpl
yhTsXQICAjIzM999993ultZvkHiXZ+gOl5f75JNP9uzZY+hWAP0JDg6+dOmSoVsBjEhhYaG7
u7uhW6Er77777pIlSzpMlEqlTk5OAwYMOHHiRFFRUVFR0dmzZ9euXYvtF0pKSrR4o7q6uuXL
l9va2lIoFIFAEBj4/7F33nFRHP//n+u90bsIotgJoKJBwV5jVIxYox+NUaMf8zUaW0xiNDEa
o1GjUWNLNBEb9oKiBgErEkWJKAii9HaFK9zB3e3vj/llv/elHHd4/eb5B49lbmb3vbd7s699
v2feE3vv3j095fpRqVRlZWX4v/n5+adOnWrz3uyIV69eBQYGWtuKtoD8EwibA11xhIVxbP8E
hUIhEAiNClksVnJy8qxZs6ZOnYoX0mi0vn37jho1ytvbuw0HcnV13b179+7duw0s1w+VSvXy
8sL/DQoKCgoKavPe7Aj77QCRnkDYHCjegbAwjt3JuLi4wLwRjQgODk5LS8vMzCwsLCQSiR06
dAgNDaVQKJa3EKGL/apbO9AT9vvlItqGY3fuCBvEsTsZb2/v69evt/RpRERERESEJe1B6IdE
Itnp3WgH8zsc+6eOaArSEwgL49idTL9+/Z48efL3339b2xCEQZDJZDvtAO1AT1AolIaGBmtb
gbAcKN6BsDCOrSeioqLCw8MdMjW1Q2K/d6MdxDsoFEpdXZ21rUBYDuSfQFgYMpnswC8tRCIx
MzPT2lYgDMV+O0D78E/U19db2wqE5bDfnxPCTqFSqQ6sJxD2hf36J+xAT6CfurOB4h0IC4OC
qs7M9u3bN23aZG0r/hf7faGyAz2BfurOhv3+nBB2CoVCsc03woyMjAkTJty8edPahrTO559/
/uuvv1rbirbw5s2blStXnjt3ztqG/H/geEwMw6xtiNEgPYGwOZCeQFgYAoFAJBJtTVJkZWUN
GTIkNDR0wIAB1raldc6cOXPlyhVrW9EWNm/ePGjQoNWrV9vOI9xOfbRITyBsDiKRiPQEwsK0
uZ+pqKiQyWQmtwcAsHjx4oiIiA0bNpDJtj5wvr6+vrCw0E47aiKRuHHjxmfPnl24cMHatvx/
7HQIBdITCJuDRCLZozZH2DVtGPfd0NCwadOmHj160Ol0k9uTlZWVmpq6bds2k++5KXFxcePH
j3+bPeTk5Gg0GjPpKgvQq1evmJgY24nX2KmPFukJhM1hp78lhF1j7Ljv2trafv36ffnll97e
3ubwHxw/fjwyMrJHjx4m33OznD179tixY21uXlpaCgBwcXExnUWWZvHixVeuXCkpKbG2IQAg
/4T5QHrC2UB6AmF5jO1n4uPjnz59imEYvqC2abl27VqjlcTNx8mTJw8fPszlctu8B7lcDgDw
9PQ0nVHmQiqVHj9+/PPPPz9y5Ihu+bhx43x9fRMSEqxlmC52mnLb1sNyAOkJ58NOxyIh7Bqj
4h27d+9OT09XqVRsNnvSpEnmsEcikTR9otTU1GzevLm4uDgsLGzOnDkCgQCW379//8aNG15e
XtOmTaPRaMYei0gkzpgx420OoVQqAQADBw409tCt0pI9baCgoGDr1q2HDx+WSqUAgMDAQPys
AQBEInHYsGFXr15dtmyZCex+O+w15baV10s3gCtXrowYMcLaViAsx9KlS3/88UdrW4FwLjp0
6JCXl2dIzaysLCaTCftPX19fM9nTt2/f7t2765Y0NDT07dsX77r9/f0fPHiAYdjSpUsBAK6u
rgCAmJgYvH5dXd2FCxfWrVu3cePG3377TSwWJyQk8Pn80tJSvM6uXbtevXql1WofP35s7CF+
+eUXMpnMZDIPHDiwb98+AIBUKtV/UmlpaeHh4Tweb+XKlcXFxbBQqVQuWLAAxoy6desmFAr1
n7Ke+jglJSWVlZUYhr1582bfvn2wcNSoUQCAXr16ZWRk1NfXN221bdu24OBg/adgGby9vXUv
k71gB3ri+vXrgwcPtrYVCMuxfPnyTZs2WdsKhHPRuXPnZ8+etVpNJBJ5e3sTCAQAAJvN3rt3
r5ns2b59OwDg8uXLeAmcfbBlyxaNRiMUCpcsWRIREbFjxw4ymfz7779jGLZnzx4AQFFREYZh
v/zyCzQSZ+nSpYsWLWKz2TKZDN+nu7v7li1bXr9+DZc1MPwQBw4cAAB06tQpLi5u5cqVU6dO
BQA0+5DGEQqFPB4PABAWFhYREeHp6Zmfn9/Q0DBmzJjQ0NDExMS8vLzhw4eHhYVptdqWTrln
z5566l+/fv3LL7+Uy+U8Hm/gwIENDQ0wZnTr1i0Mw06ePEmhUFxdXQ8fPgwTPDRi9+7dnp6e
b3nhTIKfnx+8jvaFHeiJW7du9e/f39pWICzHypUrv//+e2tbgXAuevToAd/R9aBUKnv37o17
+wUCgVKpNJM9tbW1ISEhQUFBIpEIlqxatcrLy0v3QSgUCjkcDpvNnjhx4sKFCz09Pf38/Orr
6z/77DMAQFBQ0Lp161JTU4cPHw4A+Oabb+Lj49999128+ZkzZwAAT548EQqFAID8/HzDD/HO
O++MGjVKpVJhGPbo0SMSiQQAuHbtmp4zOnToEADAzc2tpqZGLpeHh4cPHjx4586dPB7vzZs3
GIY1NDT4+PgAAM6dO9fSKeuvf+TIkbCwsK+//hoA0LNnzyVLltBoNBaLtXbtWljh4cOHMTEx
AIAePXokJibiQgSydOlSG3nWBAYGvnr1ytpWGI0djMdE+badDTQeE2F5Wu1ntFrtBx98kJ2d
rVKpAAAsFmvVqlVtGKxgIBwO5+jRo6WlpSNHjoTxfqFQyGKxiMT/7bQTEhKoVOrJkycLCgr2
7dsXEBCQlJREoVBu3rzZt2/f3NzcL7/8Mj8/Pzk5mcViLVmyhE6nl5SUwB+XTCZbs2ZNfHx8
9+7d+Xw+mUxOT083/BBFRUWzZs2iUqllZWVxcXGxsbFjx449e/asnjMqKCgAAAQFBbm4uDCZ
zFmzZj18+DA1NXXixIn+/v4AgDVr1giFwuDg4BUrVsCxLE3t0V8fAPDkyZNvv/22c+fOOTk5
O3bs+OOPP0aPHl1UVAQ/jYiISElJefTokb+/f1xc3KBBgyQSCfwoJyfn0KFD06dPf/tr9/bY
aR9oB3oCjcd0Nuz0t4Swa/T3MxiGzZ079+bNmwqFApYQCIQFCxaY1aTIyMh9+/bdu3cvOjo6
Ly9PJpM1GqecnZ3dpUuXESNGZGZmqlSqBw8edO3aFQDQqVOnFy9ebNu2bfbs2bNnz+ZwON26
deNwOB9++GFhYeH06dP37t3bt29ftVoN4xcEAsHd3R0m5jLwEC4uLps2bVq6dGl4eDiBQPjz
zz/nzp2bkJAApU+zlJaW8vn8Bw8erFy5MiUl5dixY+7u7sHBwcePH1+yZEn//v1/+OGH/fv3
nz179vXr12PGjJFKpU3t0V8fAKDVaidNmjRp0qT6+vpPP/104sSJwcHBeXl58KMpU6ZkZmaG
hYVdvHjx5s2bhYWF8+fPl8vlU6dO7dGjh6ur68yZM012/d4CO50vagfxjqysrB49eljbCoTl
WLt27ddff21tKxDOxYABA1JSUpr9SKPRzJw5k81m490mnU5fuXKlZQzbs2cPgUAICgqaPHky
kUiUy+X4R1u3biUSiRkZGY2a5OXlde3alUQi9enTJy0t7aOPPsKHoO3Zs4fBYPD5/I8++giO
WITEx8efOHFi6tSpBh7i5MmTHA6HTCZPmDChvLwcFs6aNeuff/5p6USmT58+Y8aM7du3s9ls
AoEwcODAp0+fCoXCmJgYAoHQvn17PFxy4cIFJpM5ffr0pvbor//XX3/5+PiIRKJ9+/a98847
MBqVlpbGZrMxDNNoNL6+vnQ6fdq0aStWrFi4cKG7u3unTp2ePXtGpVKnT59eWFhoyBWxAF27
ds3Ozra2FUZjB3ri2bNnnTt3trYVCMuxfv36NWvWWNsKhHMxZMiQ5OTkpuVqtXrKlCksFkv3
NYzJZOo+jM3N+fPnPTw8Ll26NHbsWN1ymUzWvn17Dw+Po0eP5ubm5ubmnj9/fvny5VFRUd26
dSsoKIDV1q1bZ+Ar2fXr19t2CEOYNm3a7NmzDa/frD1vSXV19fz58318fAgEgkAgiI2NvXfv
ngn3byp69OiRlZVlbSuMBuWfQNgcKP8EwvI028+o1er4+PirV6/CfE0QMpk8adIkd3d3i9n2
3nvvVVRUAADgjEccFouVnJw8a9YsOL0CQqPRwsPD4+Pjvb29YcmwYcO++uqrtLS0/v376z/Q
4MGDBw8e3IZDGAKFQmk05aRVmtrzlri6uu7evXv37t0m3Kc5sNN4B9ITCJvDTn9LCLumaT4r
mUw2ZsyYjIwMfMwEhE6nz58/37LWtUhwcHBaWlpmZmZhYSGRSOzQoUNoaCiFQtGt06dPnw8+
+AAOHWhDCktDDmEILi4uVVVVxrayBTQaTW1trf6P+Hw+nEtikiPa6RgypCcQNgfSEwjL02h+
R2Vl5cCBAwsKCmDmR104HE6fPn0sa10rRERERERE6Klw5MiRffv2NRJGpj1Eq3h7e1+/fv1t
9tBmVCpVbW1tbW2tWCyWSCS1tbXwr25hXV2dQqGoq6tTKpUymayhoUEikWi1WpFIZNSx2Gw2
jUbj8XgMBoNOp/P5fAaD4ebm5unp6enp6e7u7uvr265dO39/fz2azE77QKQnEDYHlUo1dqVH
BOIt0e1nCgoKYmJiKisrm96HRCJxwoQJFrfubaHRaIsWLbKuDf369fv888///vvv8PBwk+xQ
IpGIRCKhUFhTUwM3hEIhvqG7XVdX19JOmEwml8vlcrkcDodGozGZTFdXVxqNxmazKRQKj8cj
kUh8Ph8AQKfTGQxGS/uBjgqFQqFSqUQikUqlUigUtbW1KpWquLj48ePHVVVVcKYxhEQieXt7
BwcHh4aGdu7cuUuXLl26dPH19cU/RXrCLCA94WwgPYGwPDDeUVZWlpaWNnfuXLlc3kOXUbQA
ACAASURBVKzDmcPhjB492vLmOQBRUVHh4eGvXr3Soyfq6+tFIhHUAbp/G+kDuNHsBWIymS4u
LgKBwMXFpUOHDnDDxcWFy+XyeDzuv/D5fPhvGwI3baa2tra8vLykpOT169eFhYWFhYUFBQWn
Tp2qqamBFby9vXv37t27d++6ujoU7zALRq3Tg3AA0BVHWB4Y79i7d+8333yjp5pcLpfL5c+e
PYNPKSqVajEL7RTdEMP69evFYvGuXbtEOkB9ANEd96oLn893dXWF4iAwMBBXDE036HS6hU/Q
cKCU6dixY6Pyqqqqf/75Jzs7OyMj48GDB+fPn2/fvj3yT5gFlB/T2UD+CYTlgX7QqVOnEgiE
77//Xtc1rYtarf7ggw/wf9lstqurK/48Y7PZLBaLzWYLBAK4wWKxdMv5fD50pFvqtEyDWCxW
KpUKhUIikSiVSrlcLpVKlUolTDmlVColEkmjoQn435b2Cb8lSHBwMPwCG+HyL8ZODLEv3N3d
Y2NjY2Nj4b8SiWTChAnIP2EW7HRkCqLNID2BsDzQK9axY8evv/568ODBI0eOlMlkzdbkcrl7
9uwRi8Uwco//rayslMlkYrEYjubTcyw4EYDP58OUUDweD6aUxjf4fD58guIb+Drdxi7Y3Whu
AhxdWF9fDz0Bcrkc/taalqtUKrFYDMcntnoUBoOBBxT4fL6Pjw98F8dDDDweTyAQ4BsCgcDu
RJXFgGM57fGpZwd6gkAgwMEpcIFahMODPFIIy6N710VHR1+4cGH06NEtTYjg8XhTpkzRszeV
SiWXy8VisVQqlcvlMplMIpHAt3m5XN5oG9ZXKBQikUipVMLBg/iGgU90w2GxWDBMA6UJhUKB
qT+ZTCaNRqNSqVDEcDgcOp0OFwODExaYTCacsABHJsINOJ4RrgeGMBVovqgZga5IpCecBOSf
QFieRnddbGzs1atXm/VSSKXS3377rVFqqUbQaDQajebi4mJCC3FhATdIJBKXyzW8OZVKNVV2
BIS5sVOvvH08oaGe0DNXB+FIID2BsDw0Gq3RmIno6OgrV640lRQYhl2+fLm+vt7CgzEZDAbs
A40NeSDsDjvVE3awvihAU0adDKQnEJanqZ4A/wY+mExmo3ISiXTjxg1LmYZwOuw03oH0BMLm
QHoCYXma1RPg38CH7uKiAACpVPr7779byjSE04H8E2YE6QmnAukJhOVpSU+AfwMfupICw7CL
Fy+iuxRhJpB/wowgPeFUID2BsDx69ARoTlKQSKTk5GSLmIZwOpB/woyghIlOBdITCMujX0+A
JmMppFLpwYMHLWIawulAesKMoIQETgXSEwjL06qeAP93LAWc5WGnC3AjbBwU7zAjKN7hVCA9
gbA8hugJ8H8DH0Qi8bfffjO7ZQjnA/knzAjSE06FgT07AmFCDL/rcEmhUCh++uknrVZrbtsQ
zgbyT5gRpCecCgaDATMNIxAWwygVC8dSsFis8vJylIgCYXKQf8KMID3hVNDpdJVKhWGYtQ1B
OBHGesViY2OTkpKoVOqWLVvMZxXCOUH+CTOC9IRTQSAQqFQqCnkgLEkbomzR0dFJSUl37twp
Li42k1UI5wT5J8wI0hPOBoPBaGlpRwTCHLRt1E5sbOzly5ePHTtmDpMQTgvyT5gRpCecDTSE
wlR8/vnnv/76q7mbOAA0Gq1ty4JHR0ePHTvW5PYgnBnknzAjSE84G0wmE+kJk3DmzJkrV66Y
u4kD8Dazijp27GhaYxBODvJPmBGkJ5wNB/ZPKJXKxMTEoUOHEonEqKgosx6rvr6+sLDQqN9O
G5o4BmiWMsJ2QP4JM4LybTsbb6MnXr58WVBQYFp7TEJ+fv6HH37o4eExceJEmUy2f//+X375
JS4ubvz48WY6Yk5OjkajkclkZm3iGCA9gbAdkH/CjKB8285Gm8djnj59ul+/ft7e3iY36W3Q
aDRjx47t1KnTkSNHIiIikpKS7t69O3v27PDwcADA2bNnzTSgr7S0FADg4uJi1iaOAdITCNvB
Tv0TZGsbYBAo3uFstME/oVarP/vss507d0ZFRTEYDDMZ1jZkMtmFCxcAAMnJyUOGDNH96OTJ
k3/++SeXyzXHceVyOQDA09PTrE0cA/jSgmEYgUCwti0IZ8dO9YR9+CeQnnA2jB2PKZfL+/fv
f+DAASqVOmnSJPMZ1jZ4PN53331HIBBmz5598OBB3ZuZSCTOmDFj1KhRbdvz/fv3N2zYcPDg
wWbfreGEhYEDBxq+Q8ObZGdnf/vtt9u2bXOMmb0EAgHFVRE2Aop3mBGkJ5wNo/wTEonk3Xff
ffz4sUKhIJPJI0eONKttbWP16tW3b98OCgqaM2dOcHDw7t274boPGIZlZWXh1e7evbt69epr
167hJdnZ2SdPngQAbNmyhUQiJSYm4h8tW7YsKipq69atc+bMGT58OCzcvXs3hUJhsVgHDx6E
4qBVsaKnyenTp729vQkEApFIfPfdd2/dugXLL126FBkZ+eWXXy5ZsmT06NFv/fXYBCjkgbAR
kH/CjCA94WwYrieUSmVsbOzz58/hg9DNza1Tp05mtq6N9O3bNyUlJSUlpWvXrp988smUKVO0
Wm1RUVGvXr2g8UuXLn333Xe///774cOHFxUVwW8gNTX1iy++ePjw4apVq7Ra7cqVK+Hefv75
5+3bt//+++/V1dV79uy5detWcXHxwYMHP/nkk+Dg4JEjR+bl5f31118AABqNpscqPU2+/PLL
uLg4oVC4YcOGw4cPc7ncwYMHHz16NDMzc+LEiT179kxPT9+8eXNKSkphYaGZvzxLgPQEwkaw
U/8EGj+BsEUM1BMYhk2ePPnFixfwMcBgMObOnWt+696KmJiYmJiYXbt2LVq0aOzYsaNGjWpo
aCgtLT1//vzWrVuXLFny3XffCYVCiUQSEhJy/vx5tVpdXV09evToIUOGfPDBB7Nnzy4qKmKz
2V988QWdTr9w4cKDBw9OnTrl5+fn6em5c+fOUaNGnTlzhkqlPn78ODIyEgCQkpIydOjQluzR
06SmpoZMJt+6dQvOa50+ffr69esXLVo0bNgwFot1+fJlV1fXPn36KBQKLy8vi32B5gPpCYSN
gPwTZgTpCWeDyWTCgYH6+eGHH65fv44rDwKBMH/+fDOb1hZWrFixefNm3ZI5c+Zwudy8vDw+
n08mk9PT08+cOePj47NlyxYGg+Hr63vgwAGVSuXu7i4SiUQiEZvNPnXqVHx8PIlEqqysTEhI
oFKpJ0+eLCgo2LdvX0BAQFJSEoVCKSoqmjVrFpVKLSsri4uLi42NHTt27NmzZ/XYpqcJjUYL
CAjQTZKhUCjUanV+fn6vXr1cXV0BAGQy+auvvqLT6eb55iwKnU5vW4pMBMK0kEgke9QTduOf
cMIJ8c4Mh8Np9Yrfvn173bp1+GBAFou1bt06+JCzNbKzsy9fvpyYmBgVFUUmk+VyeXJyslar
nTp1KoFAcHd3r6ioGDZsWGpq6rhx43r37p2amnrt2rVBgwa98847e/fuBQDs2bOHyWQCAPz9
/Z89e5adnd2lS5cRI0aMGDFC90AuLi6bNm26d+/e0aNHWSzWn3/+mZGR8eGHH27cuJHD4TRr
m54m0dHR27ZtW7169cCBA6urq3///ffk5OSjR4+mpaXt3r17586dH330kWMoCQhc2NbaViAQ
gEwm22O8A2D2wJYtWz777DNrW4GwHNu3b//vf/+rp0J5eXmjHAlBQUFqtdpiFhpFTU3NihUr
/P394VxEGo02ePDghw8fwk/j4+NPnDjR0NDw8ccfu7m50en0Dh06AAAOHjyIYdhnn302bNgw
fFczZ878+OOPt27dSiQSMzIyGh3o5MmTHA6HTCZPmDChvLwcFs6aNeuff/5pyTY9TbRa7erV
qz08PAAATCbzvffeu337NoZhtbW1MTExAAA2mz1s2LAvv/wyKSlJo9GY7guzDpGRkU2/UgTC
8pw5c2bcuHHWtsJoCBiGWUPGGMfPP/+cl5e3Y8cOaxuCsBCHDh1KTU09dOhQs5+qVKp+/fo9
ffoUj4JxOJw9e/ZMnTrVgjaakRcvXoSGhr58+TI4OLi+vl4oFOIDFAoKCh49ejRixIju3bvL
5fJt27bBEQ/Pnz9PT09PTU2VyWTnz59v3769WS3UarXnz58/ceLE/fv3CwoKSCRSVlZW165d
zXpQczNgwIBvv/12wIAB1jYE4excuHBh375958+ft7YhxmE38Q40fsKp4HK5Uqm02Y8wDJs2
bdrz5891bwmtVhsXF2cp68zOy5cv/fz8goODAQBUKlV3tGNQUFBQUBAAIDk5edasWboSikaj
hYeHx8fHWyA9KJFIHDdu3Lhx4wAA5eXlarXaz8/P3Ac1Nw68agzCvrDT8Zh2oydQnhmngsPh
1NbWNi3HMGzu3LlJSUm6OZSIROKECRP0z4q0L4qKirp06aK/TnBwcFpaWmZmZmFhIZFI7NCh
Q2hoKIVCsYyFujjG5A6A9ATCZkDzRc0IWr/D2eBwOE39E1qtdsaMGefOnWs09YPNZs+ePduC
1pmLHTt2DBgwICws7Pnz5wZm0YiIiIiIiDC3YfaIVquVSCT4vzKZjEqlenh46EmnbWxWVgTC
TCD/hBlB8Q5no2m8Q6lUTp48+fr1603nkWq12ujoaAtaZxbKyso+/fTTgICA5OTkO3fuxMfH
W9si26WhoaGysrK8vLysrKyysrKkpKSysrKiokIoFAqFQjjDVldM4JDJZA8PDy8vL19f37Cw
sKioqNjYWDhxBiD/BMJmQHrCjCA94Ww0ineUl5cPGzYsPz+/6VIRBAJh+PDhZLJ93Ml68Pb2
Xrt27bfffgs9E9u2bbO2RdZELpeXlpZCxQD/lpWVVVRU4NKhUX03NzdPT0+BQODn59ejRw+B
QCAQCFgslu4s2fr6+srKytLS0oqKisLCwitXrqjVagaDMXz48I8++mjEiBFITyBsBBTvMCNI
TzgbeLyjqKjo9u3bCxcurK2tbVawczicKVOmWNxAs/D111/HxMR8+OGH0dHR/fr1s7Y5ZkSp
VFZXV9fU1JSXl1dUVEC5UF5eXlpaWllZWVxc3MgLRaPRPDw8fH19g4KCoqOjPT09vb29vb29
YaGHhweVSjXWhrq6urt37168ePHYsWNnz54NDQ3t1KlTYGCgyU4SgWgryD9hRpCecDZgPisM
ww4cOPDNN9/oqSmTyRISEm7evMnhcPh8Pvtf+Hw+h8OB21wul8fjEYl2kA02NjY2Pz/fKsMq
3x61Wi2RSMQ61NTUVFVVQelQXV1dXV1dWVlZXV3dNGjF5XJ9fHw8PT0jIiJGjhzp6+uLiwYv
Ly9zpCljMBiDBg0aNGjQpk2bzp49u379epFIhPwTCFsA+SfMCNITzgaZTKZQKHV1ddOmTaPT
6d98842eRMhwCSuZTKZ/EhCTyYTyQiAQsNls+C+VSmWxWHQ6ncFgMBgMOp3OYrGoVCqbzaZQ
KFwul0QiQS0iEAiIRCKPxyORSFwu1/Tn/C9WFxMikUilUikUitraWpVKJZVK5XJ5fX09Xg5F
Q9O/LaU0ZbPZ7u7uHh4e7u7unTt3dnNzc3Nz8/DwgBteXl4+Pj4MBsPCp4lDoVA++OCDuLi4
DRs2OMba6wh7B/knzAjSE04IDHmEhISsXLkyOjp65MiRzT6utFotjUYrKSkhEAj19fUymUws
FkulUplMJpPJamtrJRKJ7F9EIhG+XVlZWVRUpFAolEplXV2dQqEwKtcyhUJpJEcAAFB/wAq6
HhHdbT6fj08xaGm7DYjFYjw3HYZhYrEYbotEokYbeE18QyKR1NfX47qh1WORyWQ+n8/j8fh8
vkAg8Pb2httN/0LFYBdTeYlEIpvNrqmpsbYhCARav8OcID3hhPB4PIlE4unpCQCIjo6+cuVK
S5JCLpenpKQMHDiQSqW6uLg0ysNtFPCBKpVK1Wp1bW2tRqOBD12RSATnH2o0mtra2oaGBugO
kcvlUI7U1dXhHhSJRKLVauHzG27Dct1Hvu62mYDuFgAALnfwDRqNxmQy+Xw+1EMAAIFAALc5
HA6NRuNyuUwmk0aj8fl8Go2mW47v1vFA4zERNoKdrt+B9ATCRnFxcREKhfi/0dHRFy5cGDNm
TNPQu1Qq/fHHHwcOHPj2B2WxWCwWSyAQvP2uDEdXW+BehDbbAHWAaSxzMpCeQNgIKN5hRpCe
cELc3Nyqq6t1S2JjYy9evNhUUmAYdvPmTZlMxmazLWujaeDz+fi2haUMQhekJxA2gp2Ox7SD
Ee8A5dt2SlxdXZsGs2NjY5OSkprqBiqVmpSUZCnTEI4Jg8FA4zERtoCd+ifsQ0+gfNtOiJub
W7OD42DgA89pCKmtrT1y5IilTEM4Jsg/gbARkH/CjKB4hxPSrH8CEhsbe/Xq1UZeiuTkZD1z
ShGIVkF6AmEjIP+EGUF6wglxdXVtNH5CFzjjQ1dSUCiU69evW8Q0hGOC9ATCRkB6wowgPeGE
6PFPQBoFPqRS6aFDhyxiGsIxQXoCYSOgeIcZQXrCCWlp/IQuuoEPDMMuX75cVVVlEesQDgha
rxxhI9ipf8JW5ovCNEEwgxDQyQIEN2CyoJa82boT7vFkOwQCAU7DQxPw7JRW/RMQ3VRXRCLx
t99++/zzz3UrqNVqmPlRpVLhWSPBvwkuuVwum8121ARNCKMwoX8C78ocOP0XwnwY5Z8Qi8Ua
jUYikcA8e/BxKZPJGhoadPPp6QIz9sJ8vnDlIzc3t7dfJYdgVJI+jUaDpxM2kLq6uqKiIrgm
UEVFRWVlZVVVVVVVVXl5OVwWSCwWw76+2eYcDgcuRV1fX9/SEoIwm6F+M6CqgH9hYmM+n0+h
UDgcDkwFyGQyBQIB3OByuRwOh8lkslgsPp/PZDK9vLzeJheyY6BSqahUqsW+h7KysoiIiNLS
UryktrZWKpXC1SJwxGKxSCR68eLFxYsX1Wo1lUrt3r277goUrf4sCQSCr69vhw4dhgwZMnv2
bG9vbzOfGaKNKJVKEolkvvVNZDKZt7c3XNi2EbCnEgqFNTU1QqFQKBTCRc6EQqFIJIK3JZ7l
XSKR6LYlk8kCgaBdu3YhISExMTHvvfeej4+PmU4B8Zao1Wr4xLEKeOdWU1MzbNiw3377DS+B
C+zpdn11dXVQNDTaCUyDC1+z8Qdo0wNhGAa7R3wnJBIJqorAwMDOnTt37NixU6dOoaGhMEmx
IRihJ8Ri8QcffFBQUBATE9O3b9+wsLCQkBA8FY9cLn/z5k1RUVFxcfErHcrKygAAVCoVLgjk
5eXl5ubm7u7u5eXl7u6OP7CZTCaPx4NLMQEA4GpMBhqmC64toMMD5kjGlzOAyQfhVwnVHHxE
KRQK2F8oFAq43JFMJlMoFHh257KyMi8vrzbY4zCUlZXFx8dnZGS0b9++ffv2QUFBcNVHFxcX
+JfH4wEA4BUkk8kcDgc2hJIZbsNnPExQrZumGv5VKBRSqVQqleI/nszMTB8fH+i4whNHAgBo
NBqPx8PXiRAIBDwer7a29uzZsw0NDUuWLImKioIppblcLpVKxbNH6zqrYLZsiURSW1v78uXL
vLy8CxcuPHjwoLi42MPDw4JfLcIgJBLJ+++/f+vWLYFAAJcWc3d3d3Nzc3FxYbPZcC1ZLpcL
3xbgym0t7Qp2DtBxBf/Cu1SpVO7atWvChAkikUj8f8Hz37DZbHjDw57XxcVFIBA0XdsWd5rC
bkQkEhUWFr548eL69evPnj0rLS118v7ENhEKhZMnT3769GlkZGRkZGTHjh39/Py8vLx8fX0b
TVDXD3xCi0Qi2Mngy+npvgU1+iuRSHS7OCaTyWAwPDw8eP/C5/Nhd4fDYDCgXODz+XDZQuhz
bcOJy2SyqqoquPZvdXV1QUHBixcv8vLycnNzZTJZeXm5gZLCCD2Rk5PTpUuXffv23blz5+HD
h8+fP29oaIC9Nvx9AgAEAoGfn1/7/4u/v79uBkD7oqioKCAgID8/PygoyNq2WJNz5859/PHH
iYmJBQUFr169KigoqKiogC9qNTU1unEEA9Fd0hN2viwWCz4SuFwu7KPhNtwQCATwXx6P15ID
OT09fciQIYMHD7506VIbzrG2tpbH4+Xm5oaEhLShOcKsvHjxIjQ09O7du7W1tdDHWV1dXVVV
1cgxAB288EWipV1B9yRcJxZqX9gRw95MIBDwW8DV1bUlL6mBNDQ00On0hw8fvvPOO2+zH4Q5
yMzM7N2794kTJ/7++++HDx++evWqpKQEpjjT/9IPV/OBurPpggBw4UBcDTTawP+FNx7ctvoi
wzguLi7Hjx8fOnSoIZWNcOxIJBIKhfLRRx999NFHAID6+vrXr19XVVUpFAoSieTl5RUQEADX
FnIk4GsEypqXmZkZERERHR0dHR3dbAUorqESb/Sjwhf4hitOwV7bHEZGR0cnJSW9//77ZWVl
bQhbsFgsAoHQtDtA2AJSqZRIJPbp08eoiJtarVYqlbaTiJ1Cobi6ulZUVFjbEEQzlJeXu7m5
xcXFxcXF4YUSiaSkpAT3XqtUqqZRVHzxPCqVymazoZsWX2PP4udhSrp3756VlWV6PSEWi3Xd
DFQqNSQkxOHf5CgUCplMRnrixYsXXbt21VNBd4SKFYmNjb106dKJEyc+/fRTY9uSSCQGg9Hs
EqYIq1NbW8vhcIwdvkMmk21HTEA8PT3Ly8utbQWiGcrLy5vGoaDDwCr22AJdunTJyckxsLIR
80UlEolzfq1MJhPpiZKSEl9fX2tbYRDR0dFjxoxpW1sWi4X8E7YJ1BPWtsIEeHl5IT1hm5SV
laGhso3w8fGBgyANAemJ1kF6AgBQWlpqL3oCABAcHNy2hiwWC/knbBOpVOoYesLT0xPFO2yT
iooKw+cyOAne3t6Gy18j9ESjeIfzgPQEAEAoFL797GTbh8PhID1hmziMnjAkURvCKjhJL2cU
Rslf5J9oHaQnAAByudzeBxYZAop32Cy1tbVwVK+9w+Vy4Ww4hK3hMPeYCWGz2Ya/YiE90TpM
JtPJnzEqlUqtVptpUoZNYdSPB2FJpFKpY/T1PB5Pz1xWhBVBeqIpRiWNRXqidZB/Aq4DzmAw
rG2I2UF6wmZxmHgH0hM2C8xAY20rbAsGg9HQ0GDgYiJIT7QO0hMw6ZkzZBxH8Q6bxWHmdyA9
YbM4zD1mQmCaV/hK2SpoPGbroFUHiUQiAKDZdWUcDOSfsFkcxj/B4XCaXSIEYXUcJqZmQox6
mUT+idZB76zwZjJq6Tg7hU6nG6jEERbGYWLbNBqtpeUPEdZFqVSixWCbBekJk4HiHTBZfdOF
7BwPE65YjTAtDuOfoFKp+OpiCJsCLqFsbStsC6NeI43QEzKZzNYy11oGNL+DTqcTiURnEFU0
Gg35J2wTh4ltU6lU5J+wTRoaGmxnIS4bAY7ENHANdyPW71Cr1c75XaPxEwQCgcFgOIOeQPEO
m8VhYttUKhXDMPTosjXq6+sxDIPDD03Fw4cP//rrr+jo6NDQUKuvbdQ25HI5hUIx0G1jnJ4g
kUhttcqOcZJHqX6cZBAJnU53cu1osygUCsfIgAK75vr6eqQnbAoYhDJtvCM3N3fVqlVwMVJP
T8/IyMj+/fvPnj3b3d3dhEcxK0ZlMjQi3qHRaJxTT6DxE8Bp9ASDwUD+CdtErVYb6HRFINoA
HB9m2nts6tSparUawzAMwx49ejRjxox79+4FBgb+8ccfbd7nwoUL9+/fb0Ij9aNQKJCeMCVo
/AQAgMViOYOoQv4Jm8XB+h9nyOZiX5jviiQmJq5atcrb2zs+Pv7MmTN79uyZOXPm+fPn27Y3
DMPS09MbFWq12qysrOzs7Lc2tjHIP2FikH8COI1/Ao2fsFm0Wi3Mg2LvOMO8a3vEfLPinz59
WlRUhP87Y8aMqVOnbtiwoW178/DwKCwsxP+tr6//5ZdfOnTo0KdPnxUrVhiYyNJwzKInMAzT
arVITzgtTuKkQXrCZnHa9xmEZTCfnigpKWnk/HBxcXkbPyieXzUzMzM8PHzZsmVjx459+fLl
pUuXTB4TNIuegCNKHOP9wFhQTgIAAJvNdgY9gXIN2SwO5p9wjHNxJMynJ8RiMZTCarU6Jydn
2bJlO3fufO+999q8Q61WK5PJli9fHhUV5eLikp2dvW3bNj8/P9OZ/L/I5XLDx0EbpyecczwU
kUh0hlTT+uHz+WKx2NpWmB0CgYDc0baJw/gnFAoFkUg07bxExNtjPj2BYVhCQgKBQKBQKF26
dNmyZUvfvn2//PJL+KlKpfrkk08oFAqBQOjevbtIJMIbZmdnnzx5EgCwZcsWEomUmJgIy1+9
ehUaGrp9+/aVK1empKQEBQWZ3GYcs4zHhHrCMX7PxkIikeDpOzMCgUD3RndUkHa0TeAIecfo
fxQKBYPBQOMxbQ34tmzy8QcAAAKBUF9fLxAI8BnCZWVlpaWl8HATJ07866+/jh8/npeX5+vr
O2jQIFzTpKamfvHFFw8fPly1apVWq125ciXcm1QqLSkp2bVr1/r1683t6DJq3S5DTcHdNW00
yp5BegI4jZ5A19o2caT3GYdJpOFg0Gg0AoFgjuFTrq6uPj4+QqGwvr6+tLT0wIEDGIaNGjVK
q9Xu3bs3LS3t2rVrEyZMCAwMfPr06ePHjy9cuAAbqtXq6urq0aNHDxky5ODBgy9fviwqKuLx
eDQaTSAQZGZmmtzUpohEIsMzcRmqJ2g0GpVKdc6lF9E7KwCAz+c7g55A19o2gRfFMcYc1NXV
IT1hgxAIBCqVag49sWDBggULFsBtb2/v2bNnX7p06fnz5+np6ampqRMnTvT39wcArFmzRigU
BgcHr1ixAibXEolEIpGIzWafOnUqPj6eRCJVVlbm5uZ6eXktX7583759SUlJ5h4/bpR/wojx
EGw228Bldh0gyagu6J0VACAQCJxh/ATSE7YJ8k8gLIDJp3dlZ2cTicSePXv26RZU7gAAIABJ
REFU7NlTtzwtLQ0AwGQyg4ODf/75Zw6H8/Dhw9u3bx85cqRnz569e/ceM2ZMYmJiWVkZAGDP
nj3whvH393/27Nmvv/46ePDgZcuWJSUljRo1ikwm5+bmBgYGmtBsXcylJzgcjoH+CQdIMqoL
0hPAaeIdSE/YJvCiOMaYg7q6OgaDYW0rEM1Ap9NNOL1LpVKFhYVpNJrevXtDDwSksLAwMzNz
3rx5kZGRwcHBd+7c2b59e2Bg4NWrV4cOHQoAOHHiRHx8/CeffOLh4TFs2DBYCACIiYlJT0/v
1q3bvHnzyGTy5cuXP/7442vXrpl1bK9R8Q7j9ISB/ompU6dOnToVbpeVlaWmph47dmzdunV7
9+6dPn264Ue0EdAzBiA9gbAqdDodAGDsu6NSqbx06dKePXtu3LjRu3fve/fumcc64zBqQj/C
kpjWP0Gj0UaMGHHz5s0HDx48ePAAAEAgEHx9fXv16rVw4cJZs2YBAAQCQUpKSqOGY8aMgZPz
6+vrhUIhXv7VV189evRo79698F8mk/k2ebsNxIz+CQP1BCQxMfHhw4fff/99fHx8fHz8kSNH
Zs6cyeVyx44da/hObAESiaTVajEMc4zXo7bB5/MVCoVKpTJcC5eWlsrlci8vr+zs7KqqqkGD
Btn+evdIT9gmJBKJTqcbngElPz//m2++OXv2rFQqjYqK2r9/f1hYWFxcnFarPXPmjFlNbRUU
77BZTB7vuHjx4ts0p1KpXl5e+L9BQUFmnRraLCKRyPTzOwAAHA6ntrbW8PqmTTJqRWDU1slD
HtDlZcgQihMnThCJRKjEO3bsyOVy+/Xr9/7772/cuNH8Zr4tKLZlsxiYUU2j0YwdO7ZTp05H
jhyJiIhISkq6e/fu7Nmzw8PDAQBnz549duyY+Y3VB4p32CwoPW4jVCqVUqk0S7zDzc2tqqrK
8PomTzLaLFKp9PLlyw8fPuzRo8eMGTNMu3MIriecM50XBEpUsVjs6empv2ZAQEC3bt2YTGZ2
dnZERMTcuXO9vLz27t2Lh8CaYoGLaCAon5XNYmDGd5lMBqfbJScnDxkyRPejkydP/vnnn1wu
11wmGoZRDmSEJUF6ohHwBZLH4xlY34gHpL+//8uXL40yBYYJ1Wp1Xl7egQMHdu7cuWrVKvhp
TU3N5s2bi4uLw8LC5syZY+w0ELVavWTJkvLy8qtXr8IoTGBgYKNH0f3792/cuOHl5TVt2jTo
pW/bQeEsNSd3g7PZbDKZjOeN10NUVNSTJ08AADExMf/9738nTpwIAGjUs+MUFBRs3br18OHD
LV3EprR0EU1yufFr7RhTEx0JA1ek4/F433333Zo1a2bPnr127doZM2bgSYSIROLbqFVT9Sci
kcjDw6PNZiDMB9ITjYBj5ox4OmMGs3Pnzj59+hhePy4ujkql6h7r3XffVSqVGIY1NDT07dsX
L/f393/w4EFiYiKMFREIhH79+qWkpGAYtmvXLjc3t7KyskY7h4NZAAC9evXKyMior69vVGHp
0qUAAFdXVwBATExMSwc15EQyMzMJBAK+jL3T4urqevXqVcPrBwUFPX/+HP/36dOnJ06cwDDs
xx9/JBKJp06dwjBs1KhRzV7EhIQEPp9fWlqKl+zatevVq1ctXURTXe5Hjx4BABoaGgw/TYRl
iIyM3L17t4GV79y5ExMTA6/7L7/8otFoMAzTarWPHz/WrbNq1SrdW7rZWxRiwv5k5MiR69at
M/BEEJZk+PDh3333nbWtsCHu3r1LoVAMr2+Enjh37pyPj4/h9eGLqW6S0aCgoIKCAgzDoENy
y5YtGo1GKBQuWbIEVqBSqRs2bDhy5MiIESNIJNKff/45c+ZMAEBWVpbunhMSEkgk0qJFiygU
iqur6+HDh2F/gbNjxw4ymfz7779jGLZnzx4AQFFRUdODRkREGHIiqampDAbD8BN3VIKDg48f
P25gZbFYTKVSdUXYrl27QkJCMjIy4P3QoUMHDMNOnjzZ7EVctGgRm82WyWR4ibu7+5YtW5q9
iCa83FlZWQAAlUpl4GkiLEZsbOyPP/5oVJOUlJQRI0YAACZNmqTRaF6/fk2hUOrq6jAM++yz
z/Bo7Js3bxQKBdbCLYqZuj+JiorauXOncSePsAjjx4//4osvrG2FDZGUlOTm5mZ4fSP0RGZm
JpFIbOoJaIl58+bh+gMmGW3fvn1oaKhGo1m1apWXl5fu82PBggVkMvnu3bt4ybp16wQCwaJF
i3x9fTEMmzp16pgxYzAMe/DgAZPJhD/Ihw8fwreQHj16JCYmwlkYQqGQw+Gw2eyJEycuXLjQ
09PTz8+vvr6+6UEN5MqVK0Z9p45KeHj43r17Dax8/fr1Ll266JZs375dIBB4eHiMHDny4MGD
sB/HWriI8fHx7777Lt4Wjsl/8uRJ04to2sudnZ0NAICPHIRNMWbMmLVr17ah4c6dOwEAf/zx
B5x6l5+f/9NPPwEAlixZolAoiouL//nnHxqNdvXq1WZvUZP3J6GhoX/88UcbTgRhbmbOnLl4
8WJrW4FhGAa7Qcu00sPRo0c7duxoeH0jgsT+/v5arbakpMTA+nqSjAqFQhaLpRuiptFoAQEB
UVFReIlCoVCr1RqNJjg4OD09/ejRoxcvXkxKSho3btykSZMWLlwIAIiIiEhJSXn06JG/v39c
XNygQYMkEklCQgKVSj158mRBQcG+ffsCAgKSkpIoFErTgxpIVVWVnWbiMi18Pt+Q8ROQa9eu
+fj46JY0mzsWtHAR6XR6SUkJnGohk8nWrFkTHx/fvXv3phfRtJcbrlDjGHkYHQwPD4+KiopW
q61YsWLz5s26JXPmzOFyuXl5eXw+n0wmp6ennzlzxsfHZ8uWLQwGw9fX98CBAyqVyt3dvdlb
1OT9SU1NjYuLi7GtEBaAy+Ua3sWZj0OHDrm7uxu7uoWBrbZv375p0yYD92ns2GEjfgxubm4M
BkN3CmhLZGdnP3v2rGfPnmvWrNEtx5OMymSyRsMbo6OjCwoKVq9enZycnJCQMGLEiB9++GHf
vn2urq4lJSXTpk3r1q0bAGDkyJEdOnT45ZdfAABarXbKlCmZmZlhYWEXL168efNmYWHh/Pnz
s7Ozu3TpMmLEiMzMTJVK9eDBg65duwIAmh7UQN68eRMQENCGhg6GgXpi586dLBbrhx9+uH37
dvfu3V1dXV1dXV+8eKGbO5bJZMLcsS1dxA8//LCwsHD69Ol79+7t27evWq2GfuamF9G0l1up
VJLJZDxCh7AdfHx84C2kn+zs7OXLl0dFRf3P//zPsmXLFixY0K1bN61WO3XqVAKB4O7uXlFR
MWzYsNLS0nHjxn333XfDhw/funXroEGD3nnnnWZvUZP3J2Kx2AFWIXBIeDyeUTkRMjIyJkyY
cPPmTdOa8ddff9XU1BiV7cnwVm/evFm5cuW5c+cM2aexesKI+R0EAsHf3//Nmzf6qxmSZBTD
sNevX+vmdZkwYcLq1av379///fffM5nMwYMHp6Wl9evXr3v37j/99NPEiRP379+/Zs0apVL5
7bff4rO309LSzp49GxcX5+fnJ5PJ5HL5o0eP5s2bt3fv3ocPH0ZGRuoa1vSgBpKenv7OO+8Y
1cQh4fP5huSfyM/Pr6ur43A4/v7+Q4YM6dq1a//+/Tt16sRisZrmjp02bVqzF3HQoEF79uxZ
smRJUlLSxIkTN2zYAG/rphcxJCTEhJcb5QawWby9va9du9ZqtSNHjvzwww9Hjx7dsWMHhmE0
Gi06Ovr48eMdO3YEAAwYMCAwMHD8+PFv3rw5ffr0tWvX/Pz8AAAwb2+zt2hoaKgJbzCpVNrQ
0ID8E7aJUf6JrKysIUOGLFy4cMCAAaY1A47iMjZ9ooGtNm/e/Pjx49WrV48dO7bVykbPbTYq
mjJkyJANGza0Wm306NG6nTKBQPDz8xs/fvzBgwdhgOf69etjx4416tDNUl1dPX/+fB8fHwKB
IBAIYmNj7927J5PJ2rdv7+HhcfTo0dzc3Nzc3PPnzy9fvhwaAweEGs6FCxeoVOo///zz9tba
O0uWLJk2bVqbm6tUKt15Ovn5+XD8fLMXsaWdNL1zTHu5L1++7OHhYeSZISzBmTNn/Pz8TL7b
58+fAwBevnyJtXCLmvYGe/36NQCgoqLCxKeBMAV79+41cFAthmEDBgwYOHCgyW0QCoUw3tp0
VmPbWtXV1Z06dWrIkCEEAgHO0ITJv8+dO9fqbj/++OOPP/7YcDOM0xOzZ89esGCBUU2swsuX
L6Ojo3VlE41G69u37/r1640dajd48OBVq1aZyU774quvvjKJCjQ5JrzciYmJ7dq1M4+ZiLfi
/v37ZDK5DeMf9XPx4sVWZYoJb7C///6bQCCgCcm2SUJCQkhIiCE1Hz9+DJpMPGxKeXn5rl27
dEuuXbuGz+4pLCzUnYIA2b17NxyUU1xcbLDhzbd6+fLljBkzOBwOACAqKurAgQOZmZnwo5iY
mNGjR7e620mTJq1YscJwM4xL+Ojj4/P06VOjmliF4ODgtLS0zMzMwsJCIpHYoUOH0NDQtgXF
s7KyPvvsM5NbaI8wGAyTpzc1CSa83CjeYbP4+Pio1eqqqqpWM7QaRVFRUZcuXfTXMeENVlNT
w+PxnDnTri3D4/EMjHccP348MjKyR48eeIlUKu3Wrdu5c+fCwsLwwtu3by9cuLBfv36wEMOw
+fPnl5WVzZ8/n0QizZw5MyMjo1GWtl9//XXevHm7d++ura319fU10PJGrTQazfjx4y9fvqzR
aGJjY1euXDl8+HDd+osXL/7ggw9KSkr0H0Imkxm16JJxt7WBEXQbISIiIiIi4m32gGGYSCRy
c3MzlUl2DZPJVCgU1raiRd7+cgOkJ2wYb29vMplcVFRkEj2xY8eOAQMGhIWFPX/+vFOnToY0
MckNVl1djfoTm4XL5Ro4HvPatWu9evXSLcnMzHzz5k2jpy9cvgvvUi5dulRQUAAAaGho+Pvv
v1NTUzt06KBb//r16yUlJfPnz9+9e7fhq981baUn6zxk3Lhxvr6+CQkJy5Yt07NnY4cHGTfZ
yXD55hjU1dVpNBrbXxXTMtisf8KEID1hs5BIJB8fHzj+4C0pKyv79NNP33///dzc3Dt37rRr
1+7t92kgNTU1MMkmwgbh8XhKpVKlUrVaUyKRwLnlOKmpqR07dmyqD9zc3EJCQuC/+JqIKpXq
k08+wTBs9OjReGWNRrN69eoVK1bA+gbqiWZbwazzBAJh9uzZBw8ebGhoaNSKSCQOGzbs6tWr
+neuUCiM6g+N0xP25Z94e2BECkMLRAEAbN4/YRKQnrBlAgICWp1fZgje3t5r164tLS3t1KlT
RkaGbtpsc4P0hC0DF74y5J3Z3d39/v37uiWvX79utJg4hmG//fbbp59+Cp8jZ86cuXv37uDB
gwEAixcvfvjwIQBg5MiReP2dO3dKpdJFixbBaRcw/VqrtNRq9erVt2/fDgoKmjNnTnBw8O7d
uxtNb+7evfurV6/079zY/hD5J/QBw5yNdKjTwmAwkJ5AWJGAgABD8t8Ywtdff52cnOzv7z9l
ypR+/fqZZJ+GgPSELYOvotxqzcmTJz99+vTKlSt4iVKphCMfcU6dOlVSUjJv3jwAgEwmW758
+dy5c8eMGQMAOHz4MCzHJyGLRKL169cPHTr0jz/++O9//wsAmDhx4u7du/Wbob9V3759U1JS
UlJSunbt+sknn0yZMkVXUtBotFaTXxkb7zBu/ARM94FhmLFTY+0UfKVyaxtiEziDf0IqlTbq
FBC2g7FLHOsnNjY2Pz/fwrnLhEIhGj9hs8BVlA3RE//5z3927ty5aNGizMxMqELc3Nz+/vtv
vEJVVdXixYu/++47mFt53rx5KpXqhx9+uHPnDgBg6tSpUVFR586dwzORfPzxxzU1NT///DMA
AN6TAwYMaHU5XENaxcTExMTE7Nq1a9GiRWPHjp02bRosf/nyJUzKogfzjp9gsVgajcaQ8JJj
QCAQyGQy8k9AnGH8REVFhWmnDyBMiKura01NjQl3aPlEqCKRCCXHtFkIBAKPxzNET3A4nKNH
j5aWlo4cORKmpBwwYMDt27fv3bsHABCLxePGjWvfvv38+fMBAHv37k1ISNi/fz+Xyx06dOiv
v/564MCByspKPN/jpk2bbt26NWrUqGXLll27dq26unrgwIFubm76h+7paaUn6zz8Nycn59Ch
QzCNmx6MHT9hnH/CCVc3IJFISE9AmEwmnG3vwN6pysrKzp07W9sKRPO4uLiIRCJrW/FWIAeY
jcPn8w28xyIjI/ft2zdjxozo6OhTp069//77oaGhI0aMGD58eHp6Op/P/+uvv4hE4uHDhxcs
WLB06dJhw4YBAEgk0ty5cwEAlZWVcFzFwYMH165de/PmTd1xPHw+Hw6waAn9rbKzsy9fvpyY
mBgVFUUmk+VyeXJyMsw6L5fL586de/Lkyfbt28Plu/Vg3vET0PPvVJOnYQoda1thEzAYDK1W
69jeKbT2my3j4uJi4CA1m8XYCf0ICyMQCAyfczB9+vQ9e/Y8ffp0xIgRRCLx4sWLPXr0OH36
dEhIyI0bNzw8PAAA+fn5o0aN+v777xu11Wg08Mnyww8/nD9/vtGgYG9v79evXyuVypYOrb/V
kSNHVqxYUVpaumPHji1bthw6dCgwMDAlJaVjx45v3rxJTEycPHlycnIyjUbTc3Zqtbq+vt6M
4yfUajWJRHLg19OmoHgHDlTTbVsDyV4oLy9H8Q6bRSAQID2BMCvGzmGcN2+ej4/PRx991NDQ
EBQUlJqa2qjCN99802zD8PDwM2fOAABgxvdG/PTTT+PHj6fT6S0dV38rOp2+ceNGfHqqLp07
dzbwnRBW0685GmG0f8Kpgh0AAAqF0nTyrnPi8DoSw7Dq6mr4VoGwQQQCgVwur6+vt7YhbQfp
CRvHKP8E5L333quoqDDquQsAmDFjRmFhYUufUqnUZvNQ6adtrVoCvjoa9cQ3Tk+o1WqnCnYA
AFgslrHr0Ds2DpyNQyQSNTQ0oHiHzQIVrV3rWqlUivSELWP4+AmHB3b1Rv3ckJ5oBQ6HY+w6
9Ag75fXr10Qi0fCc+QgLAyOP9tsFYRgml8uRnrBlnC1nox7Mric0Go39/pjbhuEZ3R2eNtxe
9kVBQYGvr6+emCXCutj7+K26ujqtVstisaxtCKJFUIePY3Y90dDQYPkZ29YF+SdwYNza2DCh
HfHy5cvg4GBrW4FoEXvvf+zdv+IMsNlsFOCGwJETRk1HME5PiEQimOHceUB6AkelUpHJZAce
kJufn99oOR+ETWHvegK+8MF5UgjbBHX4ONBTq2fOalOMu7OFQiGeH9RJQLcXjkqlcuxYQGFh
Yfv27a1tBaJFHENP2G+8xhlgs9mow4dQKBQSiWRUwiGj9YSzJYtF4TQclUrlwMEOAEBxcTGe
ARdhg9TV1dm1ooWRDjT/3JZBL5C60Ol0M/onRCIR8k84LWKxmMvlWtsKM1JUVIT0hC1j79nG
mEwmgUBw+EX17BrU4evCYrHkcrnh9ZF/ohXQ7YUjFosd+OorFAqZTGbXjyuHp7y83K6zjRGJ
RDqdjvSELcNms+vq6lBOZIixGe7R+IlW4HA4KN4BceyrD73Qdh2ed3gqKirsWk8AALhcrkQi
sbYViBaBIV27zsFqQlxcXIxa0Rf5J1oB+SdwampqXF1drW2FuWCz2UQiEV1rW6asrMzLy8va
VrwVXl5e5eXl1rYC0SJotKwurq6uSE+YEqQncKqqqhxYT5BIJA8Pjzdv3ljbEESL2Hu8AwDg
7e1dVlZmbSsQreDAqwoYhZubW1VVleH1UbyjFdD8DpzCwsKAgABrW2FGwsLCMjMzrW0FokUc
IN7h6+tbVFRkbSsQLSKVSkkkklGLdDswAQEBr1+/Nry+cZnaxGIxn8+H2wqFory8XCQSyWQy
3RlQbDabxWKx2Ww+n89ms+09IM3hcORyuVarRVloCgsL27Vrp6cChmEw9b1UKlWr1fX19U3H
BjMYDDqdzuFwyGSyrfm6IiMjMzIyrG0FokVw/0RDQwNMYsjn8+3LQd25c+fTp09b2wpEi4jF
Yh6PRyAQiouLX79+XVdXJ5FIlEpls9McYA+G/yUQCPCGxP9a2npTExQUdOzYMcPrG6EnpFJp
fX39qVOn1q9f//z5c1xls1gsKpWqW013cCyVSsW1hUAgcNHB1dUV3xYIBHw+3wanI7JYLK1W
K5fLORyOtW2xJmq1uri4WCKRXLhwoaSkpKysrKSkpKKiQiwWSyQS+LcNjhwymczhcGg0GpPJ
hDcSn88X6MV8HrKIiIjdu3djGGZfjygnoba2VqFQfPnll9OnT9eN6fJ4PNh7wDvH1dXVw8PD
zc3Nzc3N1dXVzc3N09OTz+fbSGLfjh07Zmdno3vMZrl16xZcA1Yul9PpdAaDwePxaDRa01Xc
tFqtRCKBL1H4q1QjoKogkUhcLpfD4bBYLBaLBZ+G+Dbc4HA4PB6PxWIxmUwejwcrW91NEhQU
VFhYaPjrNMHwQNGbN2/atWsXEhIyefLksLCwkJAQPz+/Zt8PVCqVXC4Xi8VSqVQul8NtmUwm
EomEOtTU1MAN/DlEJBJ1ewcej4f/hd87j8eD1wY+hygUCpvNplKpLBYLPpNaPQu1Wg3HQyiV
SqlUKpVKRSKRVCqtra2VSqVisbiysrKysrK8vLyqqqqysrK6uhoAUFxc7OTLTr569SooKIhA
IHh6enp7e/v6+vr6+np7e+NXB79YAAAul0sikeDVabQfuVxeX19fW1urVqvFYjG8HCqVSqFQ
wI/EYrGoBfD0go2EKQ6DwRAIBEwmE/YCbDabwWBAIQi7BgAAdKfBpckrKyuLi4vLy8sLCgqy
s7OzsrJEIlFBQQHKkmmD5ObmdurUae7cuePGjfP19eVwOBqNpra2ViQSiXWorq6urKysqamp
/hetVgv+7dl1lQfcgEIW9ir4OyXs1uBtrMckpVJZV1cH/n201NXVKZVKsVgMO0C8e9EFZgdC
95htgmFY586d4+Lihg0b1rFjR29vb2Ob49oCVxgikQjeHvBpqFAoRCIRfCzKZDKxWAwLa2tr
a2tr5XI5vKNwBAIBFBZQcDCZTCaTCRUJk8mE7+qwELpVdF0j0HHSBh+eWCx+9epVQUHBlStX
EhISSktLDZTjRuiJmpqavLy8qKgooywzBLVaLRQK8ddcvIPAS+C/CoVCLBbDa4PLgka0pCpg
q6bl8KuH4pHD4fD5fHd3dw8PD29vbw8PD7gBS5w83qFQKGpqary8vKwYwIJSA5ehEFykikQi
+FtVKBTw99nqDplMpq+vr5eXV2BgYPfu3cPCwsLCwtzd3S1wLghjSU1NPXbs2C+//GJUKwzD
ampqcLWB9y34BnyvgNJE9xkAAJBIJFCLtAR8q4HbAoEAf52l0+ksFgv2Ks062FxdXdGqYDaI
RqPRarXWjdHj4gO+Yul2aNBFB9/PcUUikUjkcrlSqYQ3LfzbFB6PB1/XiURiU6EM738YoVYo
FCqVikQi+fv7h4WFff755/369TPQeCP0hA0Cw6jwW4DvCvAVoWlNXLLhXQB8c236Ao1wGKRS
aV1dHXRI4GsGwqiKQCCAbi3rWogwnOLiYm9vb6svRyeRSNhsttXNQCD0oKst4N9GjpNGz30o
NWCXyGQyPTw82rVr1wZdZd96AoFAIBC2RnV1tbu7e15enqMu2Pvjjz+eOnXq3r17MGtwTk5O
aGiotY2yPk7tw0cgEAgEos3Q6fQvvvjCzc3N2obYBCiGh0AgEAhEW6DT6d9++621rbAVkH8C
gUAg7I+wsLBt27bB7XHjxoWHh8Pt06dPh4SEvM2nhh8FAFBaWjphwgQWixUQELB8+XKVSoW3
PXPmTEBAAJvN/vDDD/EBTHv27Gnfvj2dTg8LC7t69SosbGknOTk5MTExDAYjKipq48aNcDZA
cXExgUAoLCyEdX788Ud8lkCz+6muriYQCAcPHgwKCmIwGEOHDi0tLYX1S0pKxo8fz+FwfHx8
1q5dq9+Yf/75p3///gwGo3///niSU7FYTCAQnj9/DgDIyMgYNGgQHIIwdOhQPBPUs2fPBgwY
wGAwwsPDN27cCCMj5eXlBAJhy5YtfD5/ypQpLTWHxv/555/t27dnMpmTJ0/Ozs5+9913WSzW
gAEDSkpK9HyrujR7pm/evJk4caKLi4ubm9vixYvh0EMDj9g8GAKBQCDsjeXLl7///vsYhmm1
WhcXFzKZDKeozJ8/f9GiRW/zqeFHwTCsT58+cXFx2dnZd+7cCQsLW7x4MYZhMElzYGBgSkrK
7du3O3TosGDBAgzDnjx5wmKxkpKSXr169cUXX3A4HJlM1tJO6urqAgICZs2a9ebNmyNHjrBY
rD59+mAYBlMfvXr1Clq4efNmWK7fmKioqKKiIqFQGBYW9sknn2AYplaru3XrNnz48KysrBs3
bri5uf3666/6jZk+fXpOTs6+ffuoVCo8KBztmJOTI5VKXVxcli5dmp+ff+/eve7du//nP//B
MEypVLZr127atGnPnj07dOgQg8Ho1KkThmFQkURFRaWkpNy/f7+l5tD4mJiYqqqq3NxcOp3u
5eWVkZEhFAojIyPhJWjpW8Vp9kzr6uqCgoLGjBnz5MmTGzduBAUFwa/FkCO2BNITCAQCYX/c
uHFDIBBoNJqsrKwOHTp07Njx6tWrGIYFBwdfunTpbT41/CgpKSkMBkOhUMDKd+7coVAoKpUK
PpNOnToFy8+cOUOj0ZRK5blz57hc7vPnzzEMU6lU165dUyqVLe3k3Llzuo/GOXPm6NcT+o25
cOECLN+yZUt4eDisT6FQKioqYPnx48cTEhJa2snZs2d1jfnPf/7TSE+Ul5d/99139fX1sMLG
jRt79+6NYVhiYqJAIJDL5bB80aJFunri9OnTsLyl5tD4K1euwPLIyEiAWkuGAAAFwElEQVT4
1Mcw7Jtvvhk0aBCGYc1+q7oXsdkzPXHiBJvNhnM9MAy7cuUKiUQSi8WGHLEl0PgJBAKBsD+i
o6Pr6+ufPHmSlpbWv39/jUaTnp4eEhJSXFwcGxtLJpPb/KnhRzl8+LBSqcRTtmAY1tDQ8OrV
K7hwIB6GiIyMVKlUBQUFQ4cODQ0NDQ0Nfeedd9577705c+bQaLScnJxmd/L8+fOQkBB8Unef
Pn2ys7P1fCEt7Qcag68VwGQy4XLkz5498/Pzw1eEmTRpEgBgz549ze7k2bNnusb06tXr2bNn
ukf39PRcuHDh/v37s7KycnJyHjx40LVrVwDAkydPunTpgmdF6tu3b3JyMt4qODhYf3OIn58f
3KDRaPg2lUqFsZhmv1Vd25o903Xr1oWGhuKJqvr27avRaPLy8gIDA1s9YksgPYFAIBD2B5VK
jY2NTUlJSU9PHz16tEajOXr0qJ+fX0xMDHx6vc2nBh5FrVYHBARcv35dt4m/vz9MNog/1WDy
LhqNxmAw7t27l5qaeu7cuSNHjuzcufPu3bst7YTJZOrmE8PTITTK9ogv76DfGN1sChiGwVNr
mjiypZ2A/7voqO4SE5CysrJevXq1a9du9OjRY8eOzczMPHfuHDx33bPA/m+CBvzbbqm57hfY
7OkDAJr9Vjt27KhrbdNWdDpd919omEajMeSILYHGYyIQCIRdMnz48L/++is9Pb1///79+/e/
f//+xYsXR4wY8fafGniUTp06FRcX0+n0Dh06dOjQQSwWf/HFF/jjMzc3F248ffqUyWQGBASk
pqb+9NNPMTExW7duzc3NZbFYycnJLe2kS5cuubm5+LoYjx8/hhvwWY7nO87Ly4Mb+o1pSkhI
SFFREb4WzJYtWyZPntzSTrp165aXl4dn3cWNwTl9+rRWq01LS1u9evWoUaPKysrgE7pr1645
OTl4Fu2WVjBuqbkhNPuttnqmoaGhz58/x7/Ge/fukUikt80XoicWgkAgEAib5cWLF1Qq1cvL
C/7r6elJIBBycnLe/tNDhw4lJCS0WlOj0fTs2bN///6PHz/++++/e/ToMW7cOOzfqP/QoUNl
Mll1dXWvXr3WrFmDYVhaWhqFQjny/9q5d9DUwSgO4FsSHyAqKIJghmBFQfABDm5mSB0KQs0m
UtwUnAQXhw4OCu4GRR0sgiDO7dSCg+DoIhVLrTh0cxUfmA7hStEqllzxXvj/phiTk/N9GXIg
58vDw3Q6bbfbBEF0u91DQTabjcfjCYVCr6+vrVZr24+52Wxomg6Hw/1+v1wu63Q6af/xZLZD
EwTB4XBIcdxutxT/5eXFaDRWKpVDQRaLhdVq5Xl+OBw2m021Wr3TP9FoNCiK6nQ6s9msVquR
JCldZblc0jQdjUalY5RKpc1mE//0T4xGIymrQ6fvJO/3+3O5nLSdy+X8fv+hWf1+E38c6Wq1
stlsoVBoMBh0Oh2GYSKRyIlXPAT1BADA/4qmaZ7npe1wOEzT9F/5l2XZ29vbU478+Pi4ublR
qVR6vf7u7k7q75OeSYVC4erqSqfTJZPJbadhqVRiGIYgCIZhqtXqkSCiKE4mE47jSJL0er3x
eHy7juP5+dlut5MkyXFcsVjc7j+SzH49IYrieDwOBoMURZnN5nw+fzyZ9/d3lmUVCoXL5cpk
Mjv1xHq9jsfjWq1Wo9EEAgFBECiKktbC9Pt9n89HEITH40kkEk6nU9yrJw6dfuLT/cdZ/X4T
fxzp29tbMBhUKBQGgyGVSs3n8/3p+lU9ge9tAwDAv277ietLJ/I7n5+fg8GAZVnp5/39fa/X
e3p6umxWZ4L+CQAAgLNYLpfX19e1Wm0ymTw+PgqCwPP8pZM6F6zvAAAAOAuLxVKv17PZbCKR
MJlM6XQ6FotdOqlzwfsOAAAAkAvvOwAAAEAu1BMAAAAgF+oJAAAAkAv1BAAAAMiFegIAAADk
Qj0BAAAAcn0B5MeIyni3XwgAAAAASUVORK5CYII=
--------------94A230CB6D64448942D2CD7D--

--------------871AF0412CC34429D28BDB28--


From nobody Wed Jun 27 09:26:42 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC67130E88 for ; Wed, 27 Jun 2018 09:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOksIyUCN4qJ for ; Wed, 27 Jun 2018 09:26:35 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE7C130E19 for ; Wed, 27 Jun 2018 09:26:34 -0700 (PDT)
Received: from [177.237.72.114] (helo=[172.30.2.54]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fYDH4-0007SD-GQ; Wed, 27 Jun 2018 18:26:31 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-CB0F1E6F-1BE6-4965-94FB-6687ECD85705; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPad Mail (15F79)
In-Reply-To: <4cf7f274-ceb8-1734-6e83-1f83766e8061@aol.com>
Date: Wed, 27 Jun 2018 11:22:04 -0500
Cc: Brian Campbell , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net>   <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net>  <9007FECD-C700-4314-B990-3B5B5414F540@lodderstedt.net> <4cf7f274-ceb8-1734-6e83-1f83766e8061@aol.com>
To: George Fletcher 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Scopes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jun 2018 16:26:41 -0000

--Apple-Mail-CB0F1E6F-1BE6-4965-94FB-6687ECD85705
Content-Type: multipart/alternative;
	boundary=Apple-Mail-B66F9DEF-F466-47C1-9C59-943FA7753542
Content-Transfer-Encoding: 7bit


--Apple-Mail-B66F9DEF-F466-47C1-9C59-943FA7753542
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi George,

thanks a lot for investing the time to assemble this flow description!

If I got it right the idea is to move the definition of the required permiss=
ions (scope)=20
of the requested access token to the interaction between signing service and=
 authz service
when the permission ticket is obtained as reaction to the attempt of the cli=
ent (the insurance=20
company) to sign a document. So the client does not need to know what scope t=
o request.
It instead uses the permission ticket (minted by the RS and the AS) to reque=
st the needed=20
permissions.=20

Is that correct?

best regards,
Torsten.

> Am 24.06.2018 um 15:01 schrieb George Fletcher :
>=20
> Not sure I have the flow exactly correct... here is an attempt to define a=
 flow based on UMA. It's a little difficult to label which flows are which p=
arts of the specs. Specifically I am using...
>=20
> https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html
> https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-05=
.html
>=20
> If you want the see the image... take the following text and load it into h=
ttps://www.websequencediagrams.com/
>=20
> title Signing Sequence
>=20
> participant "Browser" as B
> participant "Insurer" as I
> participant "Signer" as S
> participant "Bank\n(UMA AS)" as A
>=20
> B->I: complete process
> I->S: sign doc\n(required params)
> S->A: permission req\n(what the signer needs)
> A->S: permission ticket
> S->I: Not authorized\n(AS + permission tckt)
> I->A: request RPT\n(permission tckt)
> A->I: need_info
> I-->B: redirect
> B->A: claims interaction endpoint
> A->B: user verification & consent
> B->A: user meets required claims
> A-->B: redirect
> B->I: user met claimns\n(permission tckt)
> I->A: request RPT\n(permission tckt)
> A->I: RPT issued
> I->S: sign doc\n(RPT)
> S->A: introspect\n(RPT)
> A->S: permissions\n(required params)
> S->I: Signed doc
>=20
> 
>=20
>> On 6/24/18 4:27 AM, Torsten Lodderstedt wrote:
>> Hi George,
>>=20
>> how is the dynamic nature (hash) of the authorization request handled in y=
our solution?
>>=20
>> Note: the signing service is not provided by the insurance company but a t=
hird party, a sol-called trusted service provider. The insurance company as t=
he client in this flow sends the request to this provider.
>>=20
>> best regards,
>> Torsten.
>>=20
>> Am 23.06.2018 um 21:07 schrieb George Fletcher :
>>=20
>>> Thanks Torsten.
>>>=20
>>> I think I have a solution :) Just to make sure I have the flow correct..=
.
>>>=20
>>> Assumption: Using a mobile client
>>>=20
>>> 1. User (using their mobile client) attempts to sign a document with the=
 insurance company
>>> 2. Insurance company redirects the user to their Bank asking for identit=
y proof, and signing of specific documents
>>> 3. User interacts with Bank to get authorization for the specific transa=
ction
>>> 4. Mobile client submits request to insurance company using token that i=
s specific to the user, document etc.
>>>=20
>>> This is effectively the UMA 2.0 flow [1]
>>>=20
>>> 1. Mobile client attempts to invoke resource at the insurance company
>>> 2. Insurance company registers the request with UMA AS (the bank in this=
 case) and gets a permissions ticket
>>> 3. Insurance company instructs mobile client to contact the bank
>>> 4. Mobile client contacts the bank specifying the permissions ticket
>>> 5. User meets banks requirements for the specific transaction (claims in=
teraction)
>>> 6. Bank issues mobile client the RPT (token)
>>> 7. Mobile client invokes resource at insurance company with RPT
>>>=20
>>> Note that the insurance company can specify the necessary bits that need=
 to be in the token when it interacts with the Bank (as the UMA AS). [There m=
ight be some profiling required here]
>>>=20
>>> I think it's worth exploring whether UMA will solve this use case.
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.htm=
l
>>>=20
>>>> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote:
>>>>> Am 22.06.2018 um 23:08 schrieb George Fletcher :
>>>>>=20
>>>>> I would think that the scope issued to the refresh_token could represe=
nt the category or class of authorizations the refresh_token should be able t=
o perform. For example, the kind of transactions that can be bound to access=
 tokens. The scope issued into the access_token could be one of the "paramet=
erized" ones. But maybe I'm not fully understanding the use case :)
>>>> Let me try to explain ;-)
>>>>=20
>>>> The client is an issuance company wanting the customer to electronicall=
y sign a new contract (legally binding!). Signing in the end means to send a=
 request containing the hash of the document to an API. The API will respond=
 with an CM/S Object containing signature, certificate etc that the client w=
ill embedded in the contract document (typical PDF).
>>>>=20
>>>> We want the user to authorize the signing request using their bank as I=
DP/AS. Therefore the client sends the OAuth authorization request to the AS.=
 The actual signing request needs to be bound to client, user AND hash (docu=
ment) in order to prevent fraud. Regulation (eIDAS) requires to always demon=
strate the sole control of the user over the whole process. The AS therefore=
 binds (scopes) the access token to exactly this single document/signing req=
uest. If the client wants the user to sign another document, it needs to got=
 through the whole process again.
>>>>=20
>>>> One could think about a general signing permission represented by a ref=
resh token, but not in the high assurance level cases I=E2=80=98m looking in=
to.
>>>>=20
>>>> Hope that helps,
>>>> Torsten.
>>>>=20
>>>>=20
>>>=20
>=20
> --=20
> Distinguished Engineer                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
> Office: +1-703-265-2544           Photos: http://georgefletcher.photograph=
y

--Apple-Mail-B66F9DEF-F466-47C1-9C59-943FA7753542
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi George,

thanks a lot for investing the time to assemble this flow descripti=
on!

If I got it right the idea is to move the defin=
ition of the required permissions (scope) 
of the requested a=
ccess token to the interaction between signing service and authz service
when the permission ticket is obtained as reaction to the attempt of t=
he client (the insurance 
company) to sign a document. So the=
 client does not need to know what scope to request.
It instead us=
es the permission ticket (minted by the RS and the AS) to request the needed=
 
permissions. 

Is that correct=
?

best regards,
Torsten.

Am=
 24.06.2018 um 15:01 schrieb George Fletcher <gffletch@aol.com>:


 =20
    
 =20
 =20
    Not sure I have the flow
      exactly correct... here is an attempt to define a flow based on
      UMA. It's a little difficult to label which flows are which parts
      of the specs. Specifically I am using...

      

https://docs.kantarainitiative.org/uma=
/wg/oauth-uma-grant-2.0-05.html

https://docs.kantarainitiati=
ve.org/uma/wg/oauth-uma-federated-authz-2.0-05.html

      

      If you want the see the image... take the following text and load
      it into https://www.websequencediagrams.com/

      

      title Signing Sequence

      

      participant "Browser" as B

      participant "Insurer" as I

      participant "Signer" as S

      participant "Bank\n(UMA AS)" as A

      

      B->I: complete process

      I->S: sign doc\n(required params)

      S->A: permission req\n(what the signer needs)

      A->S: permission ticket

      S->I: Not authorized\n(AS + permission tckt)

      I->A: request RPT\n(permission tckt)

      A->I: need_info

      I-->B: redirect

      B->A: claims interaction endpoint

      A->B: user verification & consent

      B->A: user meets required claims

      A-->B: redirect

      B->I: user met claimns\n(permission tckt)

      I->A: request RPT\n(permission tckt)

      A->I: RPT issued

      I->S: sign doc\n(RPT)

      S->A: introspect\n(RPT)

      A->S: permissions\n(required params)

      S->I: Signed doc

      

      <uma-signing-rpt.png>

    

    
On 6/24/18 4:27 AM, Torsten Lodderstedt
      wrote:

    

    

      
      
Hi George,

      


      

      
how is the dynamic nature (hash) of the authorization request
        handled in your solution?

      


      

      
Note: the signing service is not provided by the insurance
        company but a third party, a sol-called trusted service
        provider. The insurance company as the client in this flow sends
        the request to this provider.

      


      

      
best regards,

      
Torsten.

      


        Am 23.06.2018 um 21:07 schrieb George Fletcher <gffletch@aol.com>:

        

      

      

        

          
          Thanks Torsten.

            

            I think I have a solution :) Just to make sure I have the
            flow correct...

            

            Assumption: Using a mobile client

            

            1. User (using their mobile client) attempts to sign a
            document with the insurance company

            2. Insurance company redirects the user to their Bank asking
            for identity proof, and signing of specific documents

            3. User interacts with Bank to get authorization for the
            specific transaction

            4. Mobile client submits request to insurance company using
            token that is specific to the user, document etc.

            

            This is effectively the UMA 2.0 flow [1]

            

            1. Mobile client attempts to invoke resource at the
            insurance company

            2. Insurance company registers the request with UMA AS (the
            bank in this case) and gets a permissions ticket

            3. Insurance company instructs mobile client to contact the
            bank

            4. Mobile client contacts the bank specifying the
            permissions ticket

            5. User meets banks requirements for the specific
            transaction (claims interaction)

            6. Bank issues mobile client the RPT (token)

            7. Mobile client invokes resource at insurance company with
            RPT

            

            Note that the insurance company can specify the necessary
            bits that need to be in the token when it interacts with the
            Bank (as the UMA AS). [There might be some profiling
            required here]

            

            I think it's worth exploring whether UMA will solve this use
            case.

            

            Thanks,

            George

            

            [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html=


          

          
On 6/23/18 3:43 AM, Torsten
            Lodderstedt wrote:

          

          

            

              
Am 22.06.2018 um 23:08 schrieb George Fletcher <=
a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:gffletch@aol.com" moz-do-no=
t-send=3D"true"><gffletch@aol.com>:

I would think that the scope issued to the refresh_token could represent the=
 category or class of authorizations the refresh_token should be able to per=
form. For example, the kind of transactions that can be bound to access toke=
ns. The scope issued into the access_token could be one of the "parameterize=
d" ones. But maybe I'm not fully understanding the use case :)


            

            
Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sig=
n a new contract (legally binding!). Signing in the end means to send a requ=
est containing the hash of the document to an API. The API will respond with=
 an CM/S Object containing signature, certificate etc that the client will e=
mbedded in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS=
. Therefore the client sends the OAuth authorization request to the AS. The a=
ctual signing request needs to be bound to client, user AND hash (document) i=
n order to prevent fraud. Regulation (eIDAS) requires to always demonstrate t=
he sole control of the user over the whole process. The AS therefore binds (=
scopes) the access token to exactly this single document/signing request. If=
 the client wants the user to sign another document, it needs to got through=
 the whole process again.

One could think about a general signing permission represented by a refresh t=
oken, but not in the high assurance level cases I=E2=80=98m looking into.

Hope that helps,
Torsten.




          

          

        

      

    

    

    
--=20
Distinguished Engineer                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photograph=
y


 =20


=

--Apple-Mail-B66F9DEF-F466-47C1-9C59-943FA7753542--

--Apple-Mail-CB0F1E6F-1BE6-4965-94FB-6687ECD85705
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow
ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla
MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p
Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp
vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048
LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp
WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC
AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK
6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF
BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx
AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f
BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu
dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC
hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w
IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6
7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ
koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6
xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM
5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe
Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDYyNzE2MjIwNFow
IwYJKoZIhvcNAQkEMRYEFK5wSkngE5GJm7TQ5QcP8TW9nSuGMIG+BgkrBgEEAYI3EAQxgbAwga0w
gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh
bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID
lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk
MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQBbF39jxVmgB3feLP8/
oborz0JlRN7XqFmCOh6XcF2KQ716oAMaTPC4HNU7kHPUgXuYHZaaVJMcAl2nEpLBbN+C17UhdYym
VZlTXjKnVA0GcIvezWu9JG2ewU/ho6g6fHeYfhwAcpV16f5mvG2DyIIDKdE+QIMunPf4+yiVDaOC
T7cve2Om3DYYOMEhGJOATDPmziBSF8sljTleAmhzBT/g9Qa3WxfMd2Gz3uzjl6Zmbr4FDrboy3mX
BOWegDwvFDT1D7gaTIPNTgNYHeQTGJXTIe7lVtvmlS3kJTfMKGCiQUQqLgDwZt3v2PlK0gV/SDna
IuqaMHQThoJAgHXZ1NfNAAAAAAAA
--Apple-Mail-CB0F1E6F-1BE6-4965-94FB-6687ECD85705--


From nobody Wed Jun 27 10:17:43 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FC5130E03 for ; Wed, 27 Jun 2018 10:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fo5q6gCMx8cF for ; Wed, 27 Jun 2018 10:17:37 -0700 (PDT)
Received: from sonic306-30.consmr.mail.bf2.yahoo.com (sonic306-30.consmr.mail.bf2.yahoo.com [74.6.132.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA7A9130DFF for ; Wed, 27 Jun 2018 10:17:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1530119855; bh=9R4klQhWOWmEIcf9LlczL3aIlGdQIiWf3Iph1NOifUg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=ixQYYYaKjorm0PpK0H7gwGVIodY8uog3mLXOpdhvxYY/TvKKgdeUj4NFvt0da5IKngYtPY7A4bpvsEIheGocMSvxGg2ieVGezhXN7JGZwQJdNnatlRGzQYYqUesit7m1UtRclBcoDx3+wEi8QYoKy8mFkI4GkKzIy9zV9eeEMrs4LWH9ujEBvHTCisMx5T8DtePQOvBL6xuXhiDUg4aTFzwl6c1dx6cP/GvpC4tzek9APouOmS//dzO95U8jJdg3qEL0EozCjY7CkKBEaytqRs2nXFIIJPlO/QrBjt27ZWNUWPBRY/10ljvjtZ6SWIYKmrlxl8nIYEvFanIUD0Eecg==
X-YMail-OSG: ZNCOrLYVM1kmL1y9kqVDDFxEquh10gUgLwhKsVo.U7k8GMPOEpLMY6rlv1Wxsz8 0LELVJ.FmVxzNZ2APTE1qZuSoptPFriGKyqsNrKiJqAKxEHVg5Oc-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Wed, 27 Jun 2018 17:17:35 +0000
Received: from 108.sub-174-192-35.myvzw.com (EHLO [100.78.35.73]) ([174.192.35.108]) by smtp410.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 2fbc489acdde9377240e080af0486bd4;  Wed, 27 Jun 2018 17:13:34 +0000 (UTC)
Content-Type: multipart/alternative; boundary=Apple-Mail-A9AE15E7-2D39-44B5-9ABA-0230F4996017
Mime-Version: 1.0 (1.0)
From: George Fletcher 
X-Mailer: iPhone Mail (15F79)
In-Reply-To: 
Date: Wed, 27 Jun 2018 13:13:33 -0400
Cc: Brian Campbell , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <48E721A7-E5F8-4016-83FC-9CDCA944A0AA@aol.com>
References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net>   <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net>  <9007FECD-C700-4314-B990-3B5B5414F540@lodderstedt.net> <4cf7f274-ceb8-1734-6e83-1f83766e8061@aol.com> 
To: Torsten Lodderstedt 
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Scopes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jun 2018 17:17:41 -0000

--Apple-Mail-A9AE15E7-2D39-44B5-9ABA-0230F4996017
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Yes, that is the basic idea and matches the UMA flow. I think some profiling=
 of UMA is required but may be good place to start.

Thanks,
George

--
Identity Standards Architect
Identity Engineering=20
Oath

> On Jun 27, 2018, at 12:22 PM, Torsten Lodderstedt  wrote:
>=20
> Hi George,
>=20
> thanks a lot for investing the time to assemble this flow description!
>=20
> If I got it right the idea is to move the definition of the required permi=
ssions (scope)=20
> of the requested access token to the interaction between signing service a=
nd authz service
> when the permission ticket is obtained as reaction to the attempt of the c=
lient (the insurance=20
> company) to sign a document. So the client does not need to know what scop=
e to request.
> It instead uses the permission ticket (minted by the RS and the AS) to req=
uest the needed=20
> permissions.=20
>=20
> Is that correct?
>=20
> best regards,
> Torsten.
>=20
>> Am 24.06.2018 um 15:01 schrieb George Fletcher :
>>=20
>> Not sure I have the flow exactly correct... here is an attempt to define a=
 flow based on UMA. It's a little difficult to label which flows are which p=
arts of the specs. Specifically I am using...
>>=20
>> https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html
>> https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-0=
5.html
>>=20
>> If you want the see the image... take the following text and load it into=
 https://www.websequencediagrams.com/
>>=20
>> title Signing Sequence
>>=20
>> participant "Browser" as B
>> participant "Insurer" as I
>> participant "Signer" as S
>> participant "Bank\n(UMA AS)" as A
>>=20
>> B->I: complete process
>> I->S: sign doc\n(required params)
>> S->A: permission req\n(what the signer needs)
>> A->S: permission ticket
>> S->I: Not authorized\n(AS + permission tckt)
>> I->A: request RPT\n(permission tckt)
>> A->I: need_info
>> I-->B: redirect
>> B->A: claims interaction endpoint
>> A->B: user verification & consent
>> B->A: user meets required claims
>> A-->B: redirect
>> B->I: user met claimns\n(permission tckt)
>> I->A: request RPT\n(permission tckt)
>> A->I: RPT issued
>> I->S: sign doc\n(RPT)
>> S->A: introspect\n(RPT)
>> A->S: permissions\n(required params)
>> S->I: Signed doc
>>=20
>> 
>>=20
>>> On 6/24/18 4:27 AM, Torsten Lodderstedt wrote:
>>> Hi George,
>>>=20
>>> how is the dynamic nature (hash) of the authorization request handled in=
 your solution?
>>>=20
>>> Note: the signing service is not provided by the insurance company but a=
 third party, a sol-called trusted service provider. The insurance company a=
s the client in this flow sends the request to this provider.
>>>=20
>>> best regards,
>>> Torsten.
>>>=20
>>> Am 23.06.2018 um 21:07 schrieb George Fletcher :
>>>=20
>>>> Thanks Torsten.
>>>>=20
>>>> I think I have a solution :) Just to make sure I have the flow correct.=
..
>>>>=20
>>>> Assumption: Using a mobile client
>>>>=20
>>>> 1. User (using their mobile client) attempts to sign a document with th=
e insurance company
>>>> 2. Insurance company redirects the user to their Bank asking for identi=
ty proof, and signing of specific documents
>>>> 3. User interacts with Bank to get authorization for the specific trans=
action
>>>> 4. Mobile client submits request to insurance company using            =
 token that is specific to the user, document etc.
>>>>=20
>>>> This is effectively the UMA 2.0 flow [1]
>>>>=20
>>>> 1. Mobile client attempts to invoke resource at the insurance company
>>>> 2. Insurance company registers the request with UMA AS (the bank in thi=
s case) and gets a permissions ticket
>>>> 3. Insurance company instructs mobile client to contact the bank
>>>> 4. Mobile client contacts the bank specifying the permissions ticket
>>>> 5. User meets banks requirements for the specific transaction (claims i=
nteraction)
>>>> 6. Bank issues mobile client the RPT (token)
>>>> 7. Mobile client invokes resource at insurance company with            =
 RPT
>>>>=20
>>>> Note that the insurance company can specify the necessary bits that nee=
d to be in the token when it interacts with the Bank (as the UMA AS). [There=
 might be some profiling required here]
>>>>=20
>>>> I think it's worth exploring whether UMA will solve this use case.
>>>>=20
>>>> Thanks,
>>>> George
>>>>=20
>>>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.ht=
ml
>>>>=20
>>>>> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote:
>>>>>> Am 22.06.2018 um 23:08 schrieb George Fletcher :
>>>>>>=20
>>>>>> I would think that the scope issued to the refresh_token could repres=
ent the category or class of authorizations the refresh_token should be able=
 to perform. For example, the kind of transactions that can be bound to acce=
ss tokens. The scope issued into the access_token could be one of the "param=
eterized" ones. But maybe I'm not fully understanding the use case :)
>>>>> Let me try to explain ;-)
>>>>>=20
>>>>> The client is an issuance company wanting the customer to electronical=
ly sign a new contract (legally binding!). Signing in the end means to send a=
 request containing the hash of the document to an API. The API will respond=
 with an CM/S Object containing signature, certificate etc that the client w=
ill embedded in the contract document (typical PDF).
>>>>>=20
>>>>> We want the user to authorize the signing request using their bank as I=
DP/AS. Therefore the client sends the OAuth authorization request to the AS.=
 The actual signing request needs to be bound to client, user AND hash (docu=
ment) in order to prevent fraud. Regulation (eIDAS) requires to always demon=
strate the sole control of the user over the whole process. The AS therefore=
 binds (scopes) the access token to exactly this single document/signing req=
uest. If the client wants the user to sign another document, it needs to got=
 through the whole process again.
>>>>>=20
>>>>> One could think about a general signing permission represented by a re=
fresh token, but not in the high assurance level cases I=E2=80=98m looking i=
nto.
>>>>>=20
>>>>> Hope that helps,
>>>>> Torsten.
>>>>>=20
>>>>>=20
>>>>=20
>>=20
>> --=20
>> Distinguished Engineer                  =20
>> Identity Services Engineering     Work: george.fletcher@teamaol.com
>> AOL Inc.                          AIM:  gffletch
>> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
>> Office: +1-703-265-2544           Photos: http://georgefletcher.photograp=
hy

--Apple-Mail-A9AE15E7-2D39-44B5-9ABA-0230F4996017
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Yes, that is the basic idea and matches the=
 UMA flow. I think some profiling of UMA is required but may be good place t=
o start.

Thanks,
George

--
Iden=
tity Standards Architect
Identity Engineering 
Oath=


On Jun 27, 2018, at 12:22 PM, Torsten Lodderstedt <<=
a href=3D"mailto:torsten@lodderstedt.net">torsten@lodderstedt.net> wr=
ote:

Hi George,

thanks a lot for investing the time to assemble this f=
low description!

If I got it right the idea is to m=
ove the definition of the required permissions (scope) 
of th=
e requested access token to the interaction between signing service and auth=
z service
when the permission ticket is obtained as reaction to th=
e attempt of the client (the insurance 
company) to sign a do=
cument. So the client does not need to know what scope to request.
It instead uses the permission ticket (minted by the RS and the AS) to requ=
est the needed 
permissions. 

I=
s that correct?

best regards,
Torsten.

Am 24.06.2018 um 15:01 schrieb George Fletcher <gffletch@aol.com>:


 =20
    
 =20
 =20
    Not sure I have the flow
      exactly correct... here is an attempt to define a flow based on
      UMA. It's a little difficult to label which flows are which parts
      of the specs. Specifically I am using...

      

https://docs.kantarainitiative.org/uma=
/wg/oauth-uma-grant-2.0-05.html

https://docs.kantarainitiati=
ve.org/uma/wg/oauth-uma-federated-authz-2.0-05.html

      

      If you want the see the image... take the following text and load
      it into https://www.websequencediagrams.com/

      

      title Signing Sequence

      

      participant "Browser" as B

      participant "Insurer" as I

      participant "Signer" as S

      participant "Bank\n(UMA AS)" as A

      

      B->I: complete process

      I->S: sign doc\n(required params)

      S->A: permission req\n(what the signer needs)

      A->S: permission ticket

      S->I: Not authorized\n(AS + permission tckt)

      I->A: request RPT\n(permission tckt)

      A->I: need_info

      I-->B: redirect

      B->A: claims interaction endpoint

      A->B: user verification & consent

      B->A: user meets required claims

      A-->B: redirect

      B->I: user met claimns\n(permission tckt)

      I->A: request RPT\n(permission tckt)

      A->I: RPT issued

      I->S: sign doc\n(RPT)

      S->A: introspect\n(RPT)

      A->S: permissions\n(required params)

      S->I: Signed doc

      

      <uma-signing-rpt.png>

    

    
On 6/24/18 4:27 AM, Torsten Lodderstedt
      wrote:

    

    

      
      
Hi George,

      


      

      
how is the dynamic nature (hash) of the authorization request
        handled in your solution?

      


      

      
Note: the signing service is not provided by the insurance
        company but a third party, a sol-called trusted service
        provider. The insurance company as the client in this flow sends
        the request to this provider.

      


      

      
best regards,

      
Torsten.

      


        Am 23.06.2018 um 21:07 schrieb George Fletcher <gffletch@aol.com>:

        

      

      

        

          
          Thanks Torsten.

            

            I think I have a solution :) Just to make sure I have the
            flow correct...

            

            Assumption: Using a mobile client

            

            1. User (using their mobile client) attempts to sign a
            document with the insurance company

            2. Insurance company redirects the user to their Bank asking
            for identity proof, and signing of specific documents

            3. User interacts with Bank to get authorization for the
            specific transaction

            4. Mobile client submits request to insurance company using
            token that is specific to the user, document etc.

            

            This is effectively the UMA 2.0 flow [1]

            

            1. Mobile client attempts to invoke resource at the
            insurance company

            2. Insurance company registers the request with UMA AS (the
            bank in this case) and gets a permissions ticket

            3. Insurance company instructs mobile client to contact the
            bank

            4. Mobile client contacts the bank specifying the
            permissions ticket

            5. User meets banks requirements for the specific
            transaction (claims interaction)

            6. Bank issues mobile client the RPT (token)

            7. Mobile client invokes resource at insurance company with
            RPT

            

            Note that the insurance company can specify the necessary
            bits that need to be in the token when it interacts with the
            Bank (as the UMA AS). [There might be some profiling
            required here]

            

            I think it's worth exploring whether UMA will solve this use
            case.

            

            Thanks,

            George

            

            [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html=


          

          
On 6/23/18 3:43 AM, Torsten
            Lodderstedt wrote:

          

          

            

              
Am 22.06.2018 um 23:08 schrieb George Fletcher <=
a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:gffletch@aol.com" moz-do-no=
t-send=3D"true"><gffletch@aol.com>:

I would think that the scope issued to the refresh_token could represent the=
 category or class of authorizations the refresh_token should be able to per=
form. For example, the kind of transactions that can be bound to access toke=
ns. The scope issued into the access_token could be one of the "parameterize=
d" ones. But maybe I'm not fully understanding the use case :)


            

            
Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sig=
n a new contract (legally binding!). Signing in the end means to send a requ=
est containing the hash of the document to an API. The API will respond with=
 an CM/S Object containing signature, certificate etc that the client will e=
mbedded in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS=
. Therefore the client sends the OAuth authorization request to the AS. The a=
ctual signing request needs to be bound to client, user AND hash (document) i=
n order to prevent fraud. Regulation (eIDAS) requires to always demonstrate t=
he sole control of the user over the whole process. The AS therefore binds (=
scopes) the access token to exactly this single document/signing request. If=
 the client wants the user to sign another document, it needs to got through=
 the whole process again.

One could think about a general signing permission represented by a refresh t=
oken, but not in the high assurance level cases I=E2=80=98m looking into.

Hope that helps,
Torsten.




          

          

        

      

    

    

    
--=20
Distinguished Engineer                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photograph=
y


 =20


=

--Apple-Mail-A9AE15E7-2D39-44B5-9ABA-0230F4996017--


From nobody Thu Jun 28 11:40:22 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD6C130E05 for ; Thu, 28 Jun 2018 11:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrsNNm75cJIp for ; Thu, 28 Jun 2018 11:40:16 -0700 (PDT)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E74131045 for ; Thu, 28 Jun 2018 11:40:12 -0700 (PDT)
Received: from [177.237.72.114] (helo=[172.30.2.54]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fYbo3-0006oH-Bj; Thu, 28 Jun 2018 20:40:08 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-E9ED9368-C0DB-46FB-AA62-019FADBDD561; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPad Mail (15F79)
In-Reply-To: <48E721A7-E5F8-4016-83FC-9CDCA944A0AA@aol.com>
Date: Thu, 28 Jun 2018 13:37:59 -0500
Cc: Brian Campbell , oauth 
Content-Transfer-Encoding: 7bit
Message-Id: <070AE935-F052-4587-8FF8-A306F541A2CD@lodderstedt.net>
References: <291DC85D-66B4-403F-8159-52D0091F7631@lodderstedt.net>   <00432150-20C0-4B5F-AB4E-92F96B968A3A@lodderstedt.net> <01e15dff-2bef-831f-0b00-f64137ccc80e@aol.com> <0EF040C2-F0C2-4586-828A-A809A0373F40@lodderstedt.net>  <9007FECD-C700-4314-B990-3B5B5414F540@lodderstedt.net> <4cf7f274-ceb8-1734-6e83-1f83766e8061@aol.com>  <48E721A7-E5F8-4016-83FC-9CDCA944A0AA@aol.com>
To: George Fletcher 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Dynamic Scopes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jun 2018 18:40:20 -0000

--Apple-Mail-E9ED9368-C0DB-46FB-AA62-019FADBDD561
Content-Type: multipart/alternative;
	boundary=Apple-Mail-B70897F1-0C64-470C-88A2-CB7258E07494
Content-Transfer-Encoding: 7bit


--Apple-Mail-B70897F1-0C64-470C-88A2-CB7258E07494
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi George,

I=E2=80=98m intrigued by the idea to encapsulate scope preparation and resou=
rce identification=20
into the RS. This seems to be a viable pattern to implement transaction-orie=
nted=20
authorization.

I=E2=80=98m not sure whether this justifies the implementation of UMA 2.0 in=
 AS (additional=20
grant types, claims interaction endpoint, endpoints for RS/AS interactions),=
=20
RS and client.=20

I think the basic idea could also be utilized by preparing a transaction-spe=
cific=20
scope value when the client calls the RS for the first time. The client coul=
d=20
then pass this value in the scope parameter as part of a standard authz code=
=20
grant type authz request.

Does this sound reasonable?

best regards,
Torsten.

> Am 27.06.2018 um 12:13 schrieb George Fletcher :
>=20
> Yes, that is the basic idea and matches the UMA flow. I think some profili=
ng of UMA is required but may be good place to start.
>=20
> Thanks,
> George
>=20
> --
> Identity Standards Architect
> Identity Engineering=20
> Oath
>=20
>> On Jun 27, 2018, at 12:22 PM, Torsten Lodderstedt  wrote:
>>=20
>> Hi George,
>>=20
>> thanks a lot for investing the time to assemble this flow description!
>>=20
>> If I got it right the idea is to move the definition of the required perm=
issions (scope)=20
>> of the requested access token to the interaction between signing service a=
nd authz service
>> when the permission ticket is obtained as reaction to the attempt of the c=
lient (the insurance=20
>> company) to sign a document. So the client does not need to know what sco=
pe to request.
>> It instead uses the permission ticket (minted by the RS and the AS) to re=
quest the needed=20
>> permissions.=20
>>=20
>> Is that correct?
>>=20
>> best regards,
>> Torsten.
>>=20
>>> Am 24.06.2018 um 15:01 schrieb George Fletcher :
>>>=20
>>> Not sure I have the flow exactly correct... here is an attempt to define=
 a flow based on UMA. It's a little difficult to label which flows are which=
 parts of the specs. Specifically I am using...
>>>=20
>>> https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-05.html
>>> https://docs.kantarainitiative.org/uma/wg/oauth-uma-federated-authz-2.0-=
05.html
>>>=20
>>> If you want the see the image... take the following text and load it int=
o https://www.websequencediagrams.com/
>>>=20
>>> title Signing Sequence
>>>=20
>>> participant "Browser" as B
>>> participant "Insurer" as I
>>> participant "Signer" as S
>>> participant "Bank\n(UMA AS)" as A
>>>=20
>>> B->I: complete process
>>> I->S: sign doc\n(required params)
>>> S->A: permission req\n(what the signer needs)
>>> A->S: permission ticket
>>> S->I: Not authorized\n(AS + permission tckt)
>>> I->A: request RPT\n(permission tckt)
>>> A->I: need_info
>>> I-->B: redirect
>>> B->A: claims interaction endpoint
>>> A->B: user verification & consent
>>> B->A: user meets required claims
>>> A-->B: redirect
>>> B->I: user met claimns\n(permission tckt)
>>> I->A: request RPT\n(permission tckt)
>>> A->I: RPT issued
>>> I->S: sign doc\n(RPT)
>>> S->A: introspect\n(RPT)
>>> A->S: permissions\n(required params)
>>> S->I: Signed doc
>>>=20
>>> 
>>>=20
>>>> On 6/24/18 4:27 AM, Torsten Lodderstedt wrote:
>>>> Hi George,
>>>>=20
>>>> how is the dynamic nature (hash) of the authorization request handled i=
n your solution?
>>>>=20
>>>> Note: the signing service is not provided by the insurance company but a=
 third party, a sol-called trusted service provider. The insurance company a=
s the client in this flow sends the request to this provider.
>>>>=20
>>>> best regards,
>>>> Torsten.
>>>>=20
>>>> Am 23.06.2018 um 21:07 schrieb George Fletcher :
>>>>=20
>>>>> Thanks Torsten.
>>>>>=20
>>>>> I think I have a solution :) Just to make sure I have the flow correct=
...
>>>>>=20
>>>>> Assumption: Using a mobile client
>>>>>=20
>>>>> 1. User (using their mobile client) attempts to sign a document with t=
he insurance company
>>>>> 2. Insurance company redirects the user to their Bank asking for ident=
ity proof, and signing of specific documents
>>>>> 3. User interacts with Bank to get authorization for the specific tran=
saction
>>>>> 4. Mobile client submits request to insurance company using token that=
 is specific to the user, document etc.
>>>>>=20
>>>>> This is effectively the UMA 2.0 flow [1]
>>>>>=20
>>>>> 1. Mobile client attempts to invoke resource at the insurance company
>>>>> 2. Insurance company registers the request with UMA AS (the bank in th=
is case) and gets a permissions ticket
>>>>> 3. Insurance company instructs mobile client to contact the bank
>>>>> 4. Mobile client contacts the bank specifying the permissions ticket
>>>>> 5. User meets banks requirements for the specific transaction (claims i=
nteraction)
>>>>> 6. Bank issues mobile client the RPT (token)
>>>>> 7. Mobile client invokes resource at insurance company with RPT
>>>>>=20
>>>>> Note that the insurance company can specify the necessary bits that ne=
ed to be in the token when it interacts with the Bank (as the UMA AS). [Ther=
e might be some profiling required here]
>>>>>=20
>>>>> I think it's worth exploring whether UMA will solve this use case.
>>>>>=20
>>>>> Thanks,
>>>>> George
>>>>>=20
>>>>> [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.h=
tml
>>>>>=20
>>>>>> On 6/23/18 3:43 AM, Torsten Lodderstedt wrote:
>>>>>>> Am 22.06.2018 um 23:08 schrieb George Fletcher :
>>>>>>>=20
>>>>>>> I would think that the scope issued to the refresh_token could repre=
sent the category or class of authorizations the refresh_token should be abl=
e to perform. For example, the kind of transactions that can be bound to acc=
ess tokens. The scope issued into the access_token could be one of the "para=
meterized" ones. But maybe I'm not fully understanding the use case :)
>>>>>> Let me try to explain ;-)
>>>>>>=20
>>>>>> The client is an issuance company wanting the customer to electronica=
lly sign a new contract (legally binding!). Signing in the end means to send=
 a request containing the hash of the document to an API. The API will respo=
nd with an CM/S Object containing signature, certificate etc that the client=
 will embedded in the contract document (typical PDF).
>>>>>>=20
>>>>>> We want the user to authorize the signing request using their bank as=
 IDP/AS. Therefore the client sends the OAuth authorization request to the A=
S. The actual signing request needs to be bound to client, user AND hash (do=
cument) in order to prevent fraud. Regulation (eIDAS) requires to always dem=
onstrate the sole control of the user over the whole process. The AS therefo=
re binds (scopes) the access token to exactly this single document/signing r=
equest. If the client wants the user to sign another document, it needs to g=
ot through the whole process again.
>>>>>>=20
>>>>>> One could think about a general signing permission represented by a r=
efresh token, but not in the high assurance level cases I=E2=80=98m looking i=
nto.
>>>>>>=20
>>>>>> Hope that helps,
>>>>>> Torsten.
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>=20
>>> --=20
>>> Distinguished Engineer                  =20
>>> Identity Services Engineering     Work: george.fletcher@teamaol.com
>>> AOL Inc.                          AIM:  gffletch
>>> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
>>> Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy

--Apple-Mail-B70897F1-0C64-470C-88A2-CB7258E07494
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hi George,
<=
br>
I=E2=80=98m intrigued by the idea to encapsulate scope prepara=
tion and resource identification 
into the RS. This seems to b=
e a viable pattern to implement transaction-oriented 
authori=
zation.

	


	
I=E2=80=98m not sure whether this justifies the implementation=
 of UMA 2.0 in AS (additional 
grant types, claims interactio=
n endpoint, endpoints for RS/AS interactions), 
RS and client=
. 

	


	
I think the basic idea could also be utilized by preparing a t=
ransaction-specific 
scope value when the client calls the RS=
 for the first time. The client could 
then pass this value i=
n the scope parameter as part of a standard authz code 
grant type authz request.

	


	
Does this sound reasonable?

	


	
best regards,

	
Torsten.

Am 27.06.2018 um 12:13 schrieb Ge=
orge Fletcher <gffletch@aol.com&g=
t;:

Yes, that is the basic idea and=
 matches the UMA flow. I think some profiling of UMA is required but may be g=
ood place to start.

Thanks,
George

=
--
Identity Standards Architect
Identity Engineering 
Oath

On Jun 27, 2018, at 12:22 PM, Torsten Lodder=
stedt <torsten@lodderstedt.net=
> wrote:

Hi G=
eorge,

thanks a lot for investing the time to assem=
ble this flow description!

If I got it right the id=
ea is to move the definition of the required permissions (scope) 
=

of the requested access token to the interaction between signing servic=
e and authz service
when the permission ticket is obtained as reac=
tion to the attempt of the client (the insurance 
company) to=
 sign a document. So the client does not need to know what scope to request.=

It instead uses the permission ticket (minted by the RS and the A=
S) to request the needed 
permissions. 

Is that correct?

best regards,
T=
orsten.

Am 24.06.2018 um 15:01 schrieb George Fletcher <gffletch@aol.com>:


 =20
    
 =20
 =20
    Not sure I have the flow
      exactly correct... here is an attempt to define a flow based on
      UMA. It's a little difficult to label which flows are which parts
      of the specs. Specifically I am using...

      

https://docs.kantarainitiative.org/uma=
/wg/oauth-uma-grant-2.0-05.html

https://docs.kantarainitiati=
ve.org/uma/wg/oauth-uma-federated-authz-2.0-05.html

      

      If you want the see the image... take the following text and load
      it into https://www.websequencediagrams.com/

      

      title Signing Sequence

      

      participant "Browser" as B

      participant "Insurer" as I

      participant "Signer" as S

      participant "Bank\n(UMA AS)" as A

      

      B->I: complete process

      I->S: sign doc\n(required params)

      S->A: permission req\n(what the signer needs)

      A->S: permission ticket

      S->I: Not authorized\n(AS + permission tckt)

      I->A: request RPT\n(permission tckt)

      A->I: need_info

      I-->B: redirect

      B->A: claims interaction endpoint

      A->B: user verification & consent

      B->A: user meets required claims

      A-->B: redirect

      B->I: user met claimns\n(permission tckt)

      I->A: request RPT\n(permission tckt)

      A->I: RPT issued

      I->S: sign doc\n(RPT)

      S->A: introspect\n(RPT)

      A->S: permissions\n(required params)

      S->I: Signed doc

      

      <uma-signing-rpt.png>

    

    
On 6/24/18 4:27 AM, Torsten Lodderstedt
      wrote:

    

    

      
      
Hi George,

      


      

      
how is the dynamic nature (hash) of the authorization request
        handled in your solution?

      


      

      
Note: the signing service is not provided by the insurance
        company but a third party, a sol-called trusted service
        provider. The insurance company as the client in this flow sends
        the request to this provider.

      


      

      
best regards,

      
Torsten.

      


        Am 23.06.2018 um 21:07 schrieb George Fletcher <gffletch@aol.com>:

        

      

      

        

          
          Thanks Torsten.

            

            I think I have a solution :) Just to make sure I have the
            flow correct...

            

            Assumption: Using a mobile client

            

            1. User (using their mobile client) attempts to sign a
            document with the insurance company

            2. Insurance company redirects the user to their Bank asking
            for identity proof, and signing of specific documents

            3. User interacts with Bank to get authorization for the
            specific transaction

            4. Mobile client submits request to insurance company using
            token that is specific to the user, document etc.

            

            This is effectively the UMA 2.0 flow [1]

            

            1. Mobile client attempts to invoke resource at the
            insurance company

            2. Insurance company registers the request with UMA AS (the
            bank in this case) and gets a permissions ticket

            3. Insurance company instructs mobile client to contact the
            bank

            4. Mobile client contacts the bank specifying the
            permissions ticket

            5. User meets banks requirements for the specific
            transaction (claims interaction)

            6. Bank issues mobile client the RPT (token)

            7. Mobile client invokes resource at insurance company with
            RPT

            

            Note that the insurance company can specify the necessary
            bits that need to be in the token when it interacts with the
            Bank (as the UMA AS). [There might be some profiling
            required here]

            

            I think it's worth exploring whether UMA will solve this use
            case.

            

            Thanks,

            George

            

            [1] https://docs.kantarainitiative.org/uma/wg/oauth-uma-grant-2.0-08.html=


          

          
On 6/23/18 3:43 AM, Torsten
            Lodderstedt wrote:

          

          

            

              
Am 22.06.2018 um 23:08 schrieb George Fletcher <=
a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:gffletch@aol.com" moz-do-no=
t-send=3D"true"><gffletch@aol.com>:

I would think that the scope issued to the refresh_token could represent the=
 category or class of authorizations the refresh_token should be able to per=
form. For example, the kind of transactions that can be bound to access toke=
ns. The scope issued into the access_token could be one of the "parameterize=
d" ones. But maybe I'm not fully understanding the use case :)


            

            
Let me try to explain ;-)

The client is an issuance company wanting the customer to electronically sig=
n a new contract (legally binding!). Signing in the end means to send a requ=
est containing the hash of the document to an API. The API will respond with=
 an CM/S Object containing signature, certificate etc that the client will e=
mbedded in the contract document (typical PDF).

We want the user to authorize the signing request using their bank as IDP/AS=
. Therefore the client sends the OAuth authorization request to the AS. The a=
ctual signing request needs to be bound to client, user AND hash (document) i=
n order to prevent fraud. Regulation (eIDAS) requires to always demonstrate t=
he sole control of the user over the whole process. The AS therefore binds (=
scopes) the access token to exactly this single document/signing request. If=
 the client wants the user to sign another document, it needs to got through=
 the whole process again.

One could think about a general signing permission represented by a refresh t=
oken, but not in the high assurance level cases I=E2=80=98m looking into.

Hope that helps,
Torsten.




          

          

        

      

    

    

    
--=20
Distinguished Engineer                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photograph=
y


 =20


=

--Apple-Mail-B70897F1-0C64-470C-88A2-CB7258E07494--

--Apple-Mail-E9ED9368-C0DB-46FB-AA62-019FADBDD561
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow
ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla
MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p
Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp
vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048
LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp
WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC
AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK
6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF
BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx
AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f
BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu
dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC
hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w
IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6
7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ
koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6
xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM
5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe
Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDYyODE4MzgwMFow
IwYJKoZIhvcNAQkEMRYEFHG6gotrDtz0AcsPRQ16uJwhYpTaMIG+BgkrBgEEAYI3EAQxgbAwga0w
gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh
bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID
lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk
MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQBPSFTn2lTXApb9wabr
vwCdhEqnKQrYJ/vwLZgN/IRjiB44oeVVAmoiNNih7m4u8vPjMQ+ktTIEPz9TdMO1EpqerdZfH9Wd
0xIgJ2utH/gq3258gsCQSqyCF503q12FSn3P1W75olBXfZz4EHkh4o/cKIGy7fHRVtmUc8FOKTgH
n0yxblPR4iHsQlxaxVWCRUM29AwOQ8FwGCJN1pchFX8qm5mZvg0P9ayFM1nulaUFG6r01vE+VGxI
LLVydYkHtzwBt50LyaqBOTtNn3wqYetQ6VlatCnU+6yeEg1xftRVZEQ7/h9RqKqbmtpgfDQqzcMB
LM2zgBDYqa9mim04TXmgAAAAAAAA
--Apple-Mail-E9ED9368-C0DB-46FB-AA62-019FADBDD561--


From nobody Thu Jun 28 13:15:12 2018
Return-Path: 
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 211CA130DCB; Thu, 28 Jun 2018 13:14:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153021689405.18540.5214482725778765448@ietfa.amsl.com>
Date: Thu, 28 Jun 2018 13:14:54 -0700
Archived-At: 
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jun 2018 20:14:55 -0000

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

        Title           : OAuth 2.0 Incremental Authorization
        Author          : William Denniss
	Filename        : draft-ietf-oauth-incremental-authz-00.txt
	Pages           : 8
	Date            : 2018-06-28

Abstract:
   OAuth 2.0 authorization requests that include every scope the client
   might ever need can result in over-scoped authorization and a sub-
   optimal end-user consent experience.  This specification enhances the
   OAuth 2.0 authorization protocol by adding incremental authorization,
   the ability to request specific authorization scopes as needed, when
   they're needed, removing the requirement to request every possible
   scope that might be needed upfront.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz-00


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

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


From nobody Thu Jun 28 14:34:52 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAEC1310FB; Thu, 28 Jun 2018 14:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2TVhzkWQKOf; Thu, 28 Jun 2018 14:34:25 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD25A1310F0; Thu, 28 Jun 2018 14:34:25 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 5E208B80DBF; Thu, 28 Jun 2018 14:34:20 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, oauth@ietf.org
Content-type: text/plain; charset=UTF-8
Message-Id: <20180628213420.5E208B80DBF@rfc-editor.org>
Date: Thu, 28 Jun 2018 14:34:20 -0700 (PDT)
Archived-At: 
Subject: [OAUTH-WG] =?utf-8?q?RFC_8414_on_OAuth_2=2E0_Authorization_Serve?= =?utf-8?q?r_Metadata?=
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jun 2018 21:34:43 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 8414

        Title:      OAuth 2.0 Authorization Server Metadata 
        Author:     M. Jones,
                    N. Sakimura,
                    J. Bradley
        Status:     Standards Track
        Stream:     IETF
        Date:       June 2018
        Mailbox:    mbj@microsoft.com, 
                    n-sakimura@nri.co.jp, 
                    RFC8414@ve7jtb.com
        Pages:      23
        Characters: 53831
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-oauth-discovery-10.txt

        URL:        https://www.rfc-editor.org/info/rfc8414

        DOI:        10.17487/RFC8414

This specification defines a metadata format that an OAuth 2.0 client
can use to obtain the information needed to interact with an
OAuth 2.0 authorization server, including its endpoint locations and
authorization server capabilities.

This document is a product of the Web Authorization Protocol Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


From nobody Thu Jun 28 15:54:56 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350C4131108 for ; Thu, 28 Jun 2018 15:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auZkEETzibfS for ; Thu, 28 Jun 2018 15:54:51 -0700 (PDT)
Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-bl2nam06on0102.outbound.protection.outlook.com [104.47.53.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850C1131104 for ; Thu, 28 Jun 2018 15:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IaY73Nka9ITmtuVXtzlUHdMyRld0cIYSenW4eN5F9GA=; b=ZKz/7sHll0SnJx7tbYE0LbtrAon+TBcDGwmZ4BlF4UNzwqD0giJUKEy7sbr6qnAXmx0tk94gvleFpBmZEafw9corQxyLh37UD42AacxQ/vNUmDW1XSh23tTeFtapw4Fe9j29YRGBdH+fj0RnskZ9eBDRZboQIitzWIo6j3rGi40=
Received: from BL0PR00MB0292.namprd00.prod.outlook.com (52.132.19.158) by BL0PR00MB0322.namprd00.prod.outlook.com (52.132.20.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.0; Thu, 28 Jun 2018 22:54:49 +0000
Received: from BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::6d75:a4f2:5410:f461]) by BL0PR00MB0292.namprd00.prod.outlook.com ([fe80::6d75:a4f2:5410:f461%2]) with mapi id 15.20.0952.000; Thu, 28 Jun 2018 22:54:49 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: OAuth 2.0 Authorization Server Metadata is now RFC 8414
Thread-Index: AdQPLyHlo5SvdinXRB+PDkhQc4eLfw==
Date: Thu, 28 Jun 2018 22:54:49 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [107.16.95.220]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL0PR00MB0322; 7:2XJWXmQZXoiJiiwymrhn4LDxxsfoKML0/btpLoys6jvwcUQpSEGqvaaVfRlWbNruuXWbVK0RYPr2rrsI8/xkEq29/2XUYIzkFMU71K/QzR1HvlQjKd1kNx3i73w7V2PZnOmOx8CND6COanCusy+Ufn4Lh3g2CnMj7X3dkD4J6CnKgVLsGq2d8H7dgE0+V4+j/ASBI1j9iXV0FK6YF1UJ68/K1jCCzI70iwFTY60ncpgz+GGZg/hLhli2vbFOD7J3
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 6c3579c4-818a-4d2c-76fa-08d5dd4a26e9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652037)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600026)(711020)(48565401081)(2017052603328)(7193020); SRVR:BL0PR00MB0322; 
x-ms-traffictypediagnostic: BL0PR00MB0322:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(31418570063057)(35073007944872)(21748063052155)(21532816269658)(1591387915157);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(3002001)(10201501046)(3231270)(2018427008)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BL0PR00MB0322; BCL:0; PCL:0; RULEID:; SRVR:BL0PR00MB0322; 
x-forefront-prvs: 0717E25089
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(346002)(396003)(366004)(209900001)(54164003)(189003)(199004)(8990500004)(316002)(22452003)(476003)(7736002)(256004)(486006)(97736004)(66066001)(2906002)(21615005)(790700001)(6116002)(3846002)(53936002)(8936002)(81166006)(99286004)(1730700003)(81156014)(5630700001)(186003)(8676002)(9686003)(54896002)(6306002)(55016002)(236005)(102836004)(5660300001)(10290500003)(5640700003)(6506007)(5250100002)(478600001)(68736007)(72206003)(966005)(2501003)(26005)(53376002)(6436002)(606006)(33656002)(6916009)(14454004)(10090500001)(86612001)(2900100001)(25786009)(106356001)(86362001)(7696005)(74316002)(2351001)(105586002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR00MB0322; H:BL0PR00MB0292.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: UU6giki1ZXh2BTJkech/tk627ONKOnORF+yfGKT+2uH7JEn0O2bznqveH/Hzjh4DsEDEw+76qBSXVSOry/mT8ViJmnreixaU5MXw6MZuVLMZ1vws8VJuw6OAF5LdI1UgleI/UUNhtuU4QI36N9d9x/MTnEAT9WPTKK/0ZXuKphfYAyUejJZslkGOugt4i4wBfBLoLaJgaOyjJYfV8TvkwKjcF9+61LpsAwriw856mwLnnz6jf+0e/4QU/edROj938OOmzZqa60lv5q6n8kI+AO2wgNBXck15C007PTjQR72fKr9ncfkoylew36HDwpu4JpvuZjWr9QRtcrca2+srs797RCgxWq/y+N09RMSohd0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BL0PR00MB0292114ED161717408E72C46F54F0BL0PR00MB0292namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6c3579c4-818a-4d2c-76fa-08d5dd4a26e9
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2018 22:54:49.2405 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR00MB0322
Archived-At: 
Subject: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata is now RFC 8414
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jun 2018 22:54:55 -0000

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

The OAuth 2.0 Authorization Server Metadata specification is now RFC 8414.  The abstract describes the spe=
cification as:

This specification defines a metadata format that an OAuth 2.0 client can u=
se to obtain the information needed to interact with an OAuth 2.0 authoriza=
tion server, including its endpoint locations and authorization server capa=
bilities.

The specification defines a JSON metadata representation for OAuth 2.0 auth=
orization servers that is compatible with OpenID Connect Discovery 1.0.  This specification=
 is a true instance of standardizing existing practice.  OAuth 2.0 deployme=
nts have been using the OpenID Connect metadata format to describe their en=
dpoints and capabilities for years.  This RFC makes this existing practice =
a standard.

Having a standard OAuth metadata format makes it easier for OAuth clients t=
o configure connections to OAuth authorization servers.  See https://www.ia=
na.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-se=
rver-metadata for the initial set of registered metadata values.

Thanks to all of you who helped make this standard a reality!

                                                       -- Mike

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


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











The OAuth 2.0 Authorization Server Metadata specific=
ation is now
RFC 8414.  =
The abstract describes the specification as:


 


This specification define=
s a metadata format that an OAuth 2.0 client can use to obtain the informat=
ion needed to interact with an OAuth 2.0 authorization server, including it=
s endpoint locations and authorization
 server capabilities.


 


The specification defines a JSON metadata representa=
tion for OAuth 2.0 authorization servers that is compatible with
OpenI=
D Connect Discovery 1.0.  This specification is a true instance of=
 standardizing existing practice.  OAuth 2.0 deployments have been usi=
ng the OpenID Connect metadata format to describe
 their endpoints and capabilities for years.  This RFC makes this exis=
ting practice a standard.


 


Having a standard OAuth metadata format makes it eas=
ier for OAuth clients to configure connections to OAuth authorization serve=
rs.  See

https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#au=
thorization-server-metadata for the initial set of registered metadata =
values.


 


Thanks to all of you who helped make this standard a=
 reality!


 


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


 


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


 






--_000_BL0PR00MB0292114ED161717408E72C46F54F0BL0PR00MB0292namp_--


From nobody Thu Jun 28 16:15:27 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33A0130E37 for ; Thu, 28 Jun 2018 16:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level: 
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhILUl_Qvm0L for ; Thu, 28 Jun 2018 16:15:23 -0700 (PDT)
Received: from mail-ua0-x241.google.com (mail-ua0-x241.google.com [IPv6:2607:f8b0:400c:c08::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40762130E2E for ; Thu, 28 Jun 2018 16:15:23 -0700 (PDT)
Received: by mail-ua0-x241.google.com with SMTP id z4-v6so3820540uao.12 for ; Thu, 28 Jun 2018 16:15:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LH59EU8xxVFsljs/ucnDTNdrAYVuO7K97pvJUWClOMo=; b=ka1f/wjUA6S12ng1dpX4+I4W2Lh/jHYwl3iy12xlidEiQZZDt5ziN6XG+VbaA8oVwJ pTIZZGVpUq/Lja6oDctJkJppqSV2d5EVLNhnAjJI/Z4k+Ihz4h8/vhATn5us+PtRMDnj wND1r5u9t2/LCQJpUkF+Df6K99YNINfx+yorxDkfLisMlKaTdmB0d9d0vf59mDFe/iiP QQKQQOfcuFe4Mb/piMwPdFFH8FQlSsRXKZOEXqdqk93xQpXhdN0cgE95Gz18RwFEfjJc SHbueMZvexKwV7DHVknmki8Ju/NZk425W4SwZILwcfW3L5qSbXsW5JBgd5omeymsAtE6 s6Fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LH59EU8xxVFsljs/ucnDTNdrAYVuO7K97pvJUWClOMo=; b=H+9lemts7tgw4WEl45GYS310PxafPfmmZeizpbYy4GeUeC0BO/FswsI/m99ahP4xI/ 7ltgNLiDGWLvOh7wccHAjgPl6eB5GkBjHjySbUd72eTexQyMa79DxBmMx0oArlIdTT8Y Ji9PsLlKEAntSVaUej3C8gTSDERBkmClVM/xkiHJ4nZUm50RDDGfRu2g9jtCW64xPqpk nPJgliL2H+P+bDsFuxYuFLGTqIe4SFBL8qRCH4DSeGtLCuYDcxY6asDOLd1Yj7VWuoW7 4nye/8K4U6rUK7oX4pmwTK8ZvQ65bclR+mV+P3C8VL4DZj5TvVoG1wu6twDTntfqAcTa FoNw==
X-Gm-Message-State: APt69E0gt43XWeQx8pm4OzZ6aKIivxq6T09bFamyMpY+DJbYmatkE/uM MsEeQqo/HNA7+qRjjg50NpH3BDXgUEFXlLFEP3bEolEo
X-Google-Smtp-Source: AAOMgpefLgIhRl31P01FnQ10L5DeUIkmk5D7xE6gWZ7mWtQuiA4uRwRLwiTYLqk8Gqj9WTvu32jok/32569kmIiznR8=
X-Received: by 2002:ab0:2157:: with SMTP id t23-v6mr7827037ual.108.1530227721828;  Thu, 28 Jun 2018 16:15:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ab0:6383:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 16:15:01 -0700 (PDT)
In-Reply-To: 
References: 
From: William Denniss 
Date: Thu, 28 Jun 2018 16:15:01 -0700
Message-ID: 
To: Mike Jones 
Cc: "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000c99d14056fbbe7ca"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata is now RFC 8414
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jun 2018 23:15:26 -0000

--000000000000c99d14056fbbe7ca
Content-Type: text/plain; charset="UTF-8"

Congratulations!

Really glad that we have an RFC specifying how servers should provide their
configuration data in machine readable form. Helps with developer
experience (less manual configuration), as well as mitigating mix-up
attacks (better association of related endpoints), amongst other benefits.

I'm happy to say that the AppAuth clients support RFC 8414, through
discovery methods that take a complete URL
,
in addition to the issuer-based ones designed for OIDC usage.


On Thu, Jun 28, 2018 at 3:54 PM, Mike Jones <
Michael.Jones=40microsoft.com@dmarc.ietf.org> wrote:

> The OAuth 2.0 Authorization Server Metadata specification is now RFC 8414
> .  The abstract describes the
> specification as:
>
>
>
> This specification defines a metadata format that an OAuth 2.0 client can
> use to obtain the information needed to interact with an OAuth 2.0
> authorization server, including its endpoint locations and authorization
> server capabilities.
>
>
>
> The specification defines a JSON metadata representation for OAuth 2.0
> authorization servers that is compatible with OpenID Connect Discovery 1.0
> .  This
> specification is a true instance of standardizing existing practice.  OAuth
> 2.0 deployments have been using the OpenID Connect metadata format to
> describe their endpoints and capabilities for years.  This RFC makes this
> existing practice a standard.
>
>
>
> Having a standard OAuth metadata format makes it easier for OAuth clients
> to configure connections to OAuth authorization servers.  See
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#
> authorization-server-metadata for the initial set of registered metadata
> values.
>
>
>
> Thanks to all of you who helped make this standard a reality!
>
>
>
>                                                        -- Mike
>
>
>
> P.S.  This announcement was also posted at http://self-issued.info/?p=1883
> and as @selfissued .
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--000000000000c99d14056fbbe7ca
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Congratulations!

Really glad that we have an =
RFC specifying how servers should provide their configuration data in machi=
ne readable form. Helps with developer experience (less manual configuratio=
n), as well as mitigating mix-up attacks (better association of related end=
points), amongst other benefits.

I'm happy to s=
ay that the AppAuth clients support RFC 8414, through discovery methods tha=
t take a co=
mplete URL, in addition to the issuer-based ones designed for OIDC usag=
e.

<=
br>
On Thu, Jun 28, 2018 at 3:54 PM, Mike Jones <=
span dir=3D"ltr"><Michael.Jones=3D40microsoft.com@dmarc.ietf.or=
g> wrote:











The OAuth 2.0 Authorization Server Metadata specific=
ation is now
RF=
C 8414.=C2=A0 The abstract describes the specification as:


=C2=A0


This specification define=
s a metadata format that an OAuth 2.0 client can use to obtain the informat=
ion needed to interact with an OAuth 2.0 authorization server, including it=
s endpoint locations and authorization
 server capabilities.


=C2=A0


The specification defines a JSON metadata representa=
tion for OAuth 2.0 authorization servers that is compatible with
OpenID Connect Discovery 1.0.=C2=A0 This specification is =
a true instance of standardizing existing practice.=C2=A0 OAuth 2.0 deploym=
ents have been using the OpenID Connect metadata format to describe
 their endpoints and capabilities for years.=C2=A0 This RFC makes this exis=
ting practice a standard.


=C2=A0


Having a standard OAuth metadata format makes it eas=
ier for OAuth clients to configure connections to OAuth authorization serve=
rs.=C2=A0 See

https://www.iana.org/assignments/oauth-parameters/oauth-parameter=
s.xhtml#authorization-server-metadata for the initial set of regis=
tered metadata values.


=C2=A0


Thanks to all of you who helped make this standard a=
 reality!


=C2=A0


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


=C2=A0


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


=C2=A0







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--000000000000c99d14056fbbe7ca--


From nobody Thu Jun 28 17:00:55 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD0C131023 for ; Thu, 28 Jun 2018 17:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSDcVxdmI8wW for ; Thu, 28 Jun 2018 17:00:40 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AFC3130E3F for ; Thu, 28 Jun 2018 17:00:38 -0700 (PDT)
Received: from [177.237.72.114] (helo=[172.30.2.54]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fYgq3-0004DO-4b; Fri, 29 Jun 2018 02:00:35 +0200
Content-Type: multipart/signed; boundary=Apple-Mail-D886DACE-4B37-4890-81BE-231A06067289; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt 
X-Mailer: iPad Mail (15F79)
In-Reply-To: 
Date: Thu, 28 Jun 2018 19:00:31 -0500
Cc: "oauth@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: <5E0936CA-0B7C-4771-B317-31B40EE9EAA9@lodderstedt.net>
References:  
To: Mike Jones 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata is now RFC 8414
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2018 00:00:44 -0000

--Apple-Mail-D886DACE-4B37-4890-81BE-231A06067289
Content-Type: multipart/alternative;
	boundary=Apple-Mail-012EA17A-D385-42F2-A75C-9BDAC9BB71B0
Content-Transfer-Encoding: 7bit


--Apple-Mail-012EA17A-D385-42F2-A75C-9BDAC9BB71B0
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Congratulations!

> Am 28.06.2018 um 18:15 schrieb William Denniss :
>=20
> Congratulations!
>=20
> Really glad that we have an RFC specifying how servers should provide thei=
r configuration data in machine readable form. Helps with developer experien=
ce (less manual configuration), as well as mitigating mix-up attacks (better=
 association of related endpoints), amongst other benefits.
>=20
> I'm happy to say that the AppAuth clients support RFC 8414, through discov=
ery methods that take a complete URL, in addition to the issuer-based ones d=
esigned for OIDC usage.
>=20
>=20
>> On Thu, Jun 28, 2018 at 3:54 PM, Mike Jones  wrote:
>> The OAuth 2.0 Authorization Server Metadata specification is now RFC 8414=
.  The abstract describes the specification as:
>>=20
>> =20
>>=20
>> This specification defines a metadata format that an OAuth 2.0 client can=
 use to obtain the information needed to interact with an OAuth 2.0 authoriz=
ation server, including its endpoint locations and authorization server capa=
bilities.
>>=20
>> =20
>>=20
>> The specification defines a JSON metadata representation for OAuth 2.0 au=
thorization servers that is compatible with OpenID Connect Discovery 1.0.  T=
his specification is a true instance of standardizing existing practice.  OA=
uth 2.0 deployments have been using the OpenID Connect metadata format to de=
scribe their endpoints and capabilities for years.  This RFC makes this exis=
ting practice a standard.
>>=20
>> =20
>>=20
>> Having a standard OAuth metadata format makes it easier for OAuth clients=
 to configure connections to OAuth authorization servers.  See https://www.i=
ana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-se=
rver-metadata for the initial set of registered metadata values.
>>=20
>> =20
>>=20
>> Thanks to all of you who helped make this standard a reality!
>>=20
>> =20
>>=20
>>                                                        -- Mike
>>=20
>> =20
>>=20
>> P.S.  This announcement was also posted at http://self-issued.info/?p=3D1=
883 and as @selfissued.
>>=20
>> =20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-012EA17A-D385-42F2-A75C-9BDAC9BB71B0
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Congratulations!
=

Am 28.06.2018 um 18:15 schrieb William Denniss <wdenniss=3D40google.com@dmarc.ietf.org<=
/a>>:

Congra=
tulations!

On Thu, J=
un 28, 2018 at 3:54 PM, Mike Jones <Michael.Jon=
es=3D40microsoft.com@dmarc.ietf.org> wrote:











The OAuth 2.0 Authorization Server Metadata specifica=
tion is now
RFC=
 8414.  The abstract describes the specification as:<=
/p>

 


This specification defines=
 a metadata format that an OAuth 2.0 client can use to obtain the informatio=
n needed to interact with an OAuth 2.0 authorization server, including its e=
ndpoint locations and authorization
 server capabilities.


 


The specification defines a JSON metadata representat=
ion for OAuth 2.0 authorization servers that is compatible with
OpenID Connect Discovery 1.0.  This specification is a t=
rue instance of standardizing existing practice.  OAuth 2.0 deployments=
 have been using the OpenID Connect metadata format to describe
 their endpoints and capabilities for years.  This RFC makes this exist=
ing practice a standard.


 


Having a standard OAuth metadata format makes it easi=
er for OAuth clients to configure connections to OAuth authorization servers=
.  See

https://www.iana.org/assignments/oauth-parameters/oauth-parameters=
.xhtml#authorization-server-metadata for the initial set of registe=
red metadata values.


 


Thanks to all of you who helped make this standard a r=
eality!<=
/span>


 


         =
;            &nb=
sp;           &n=
bsp;            =
         -- Mike


 


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


 







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-012EA17A-D385-42F2-A75C-9BDAC9BB71B0--

--Apple-Mail-D886DACE-4B37-4890-81BE-231A06067289
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFPjCCBTow
ggQioAMCAQICEQCSJtR3C5gtrmIWapJ6EgOVMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQGEwJH
QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK
ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGlj
YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODAxMDQwMDAwMDBaFw0xOTAxMDQyMzU5NTla
MCgxJjAkBgkqhkiG9w0BCQEWF3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAv7DF8qZUUXBAJoSmv9yoqrhhGdqD8LF+dInQfkJNYgRBtTohMg+p
Uy6TOfwPMJL7nxFZQKeROtLGcFCxoZAEtpXso6m7P3GcYleN1waJRH981U81XzH2clCg9+YRnIUp
vof1EPRFyBgaVuLYiTlgVccBQ/n73mUAVkP5a9UOVblWAeQvGCvsV2TlPNCOXOtphvG137/0s048
LsHqWgtNW/Ev/2OoAdaFj5fCk70OB8jI9RZupXh5sUeznlHInWtnk7t8hL+HjeNVN0mtHubZ8btp
WfStV7PT3erDhFgwLg984+00kzGdCxXHsIWPa2vb2TWKrpEJrBK8ZDY8oqX+DwIDAQABo4IB7TCC
AekwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFOGxsCWszkCbF4VK
6r3xiP6+8T0lMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF
BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx
AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f
BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu
dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC
hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu
ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w
IgYDVR0RBBswGYEXdG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQwDQYJKoZIhvcNAQELBQADggEBALA6
7MMPtwJynHzvV7nqHNhd78IX9df4ZZPBPv42mZbyCyXgMhbESSO4bGDQTcSpdJzgIueIGl6k4+SQ
koKJHGoKUKtMg5nYwk7X5yrr2JNxwGaCOwLR1W/uU092icWT56lT/3scU1Hmv9l/hXnSHaiqqcU6
xi+taGoHWtb61IzTYk7ezv4UUSBzJdutobWBuI0nNI4eSk6c9IXZoyhOcV7Egw4BFciQhP/KxveM
5x71yWvS1b7yp1CCaPypBuUdqag/WVc+vR1IdmQbk4Es0Ku25ohUh40pDdDX62iBpUSnukzTgTJe
Q0oBmeTidCoa+V8FEF9OAcI7TqUEd1YAHPYxggO6MIIDtgIBATCBrTCBlzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0
aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCSJtR3C5gtrmIWapJ6EgOVMAkGBSsOAwIaBQCgggHh
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDYyOTAwMDAzMVow
IwYJKoZIhvcNAQkEMRYEFMQF4dLmat2ysx5pMEBUvgv8dshsMIG+BgkrBgEEAYI3EAQxgbAwga0w
gZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1Nh
bGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAkibUdwuYLa5iFmqSehID
lTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy
IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVk
MT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBAhEAkibUdwuYLa5iFmqSehIDlTANBgkqhkiG9w0BAQEFAASCAQBh7+nzDycjGNKpOJhg
jUarv/RnIE+C50sfsShVA8iROIhkZfRECFZJxcg/n1p4GhTbOof9umJRsbZ+l28EKbKJNwT7mnxw
9scXQ5/Zsyhfv1OvgZGkxVRFEpMzpK0KZWb4K4eHsqxRopMY4spAJT+FtdWYyFZAPhyQO8JUo1LG
QIbsUd5f7MKlBx3bcQjgKqZwEBIve1xDxpey1waz62u5LNYz7l0sjUt1iHbjIotG6PEXLwOez/aT
IGOaN4W98pgI36YDmRznE4KF4GTVmHkwbYcVpHh62nGnA/h/rf7xrtv76qy31GhNdMjuAYZPLluJ
Ar2H/ZR4r2bmmL/82jQyAAAAAAAA
--Apple-Mail-D886DACE-4B37-4890-81BE-231A06067289--


From nobody Thu Jun 28 17:03:03 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD943130DF1 for ; Thu, 28 Jun 2018 17:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level: 
X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2jSpWqOKEcT for ; Thu, 28 Jun 2018 17:02:59 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B19B130E40 for ; Thu, 28 Jun 2018 17:02:59 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w5SNxhPN085622; Fri, 29 Jun 2018 00:02:57 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2017-10-26; bh=RKUFNKvtllkajegnGzy8bi4i6Xy40Mn1VQ140+feyHY=; b=aqRX9jKhykeU7CwlLSr/giDRLknhM4EPURw8WlVGSnsAm4lp6zkQ/3iPWVR2K1TElDPM F36vHkSw8JHDoYGxu9h20VvVGz+Y1nqr7GlKR9xBvNxpuogUvwPrLmls+ePhakQx/BNm JFOmUb3eqt02Q07C+iew7OOe5vbqj4XtwWowzR5tW+zfFQ9LtxgQ8sXy9aW8hNyZIvsS Bkiw0xJkeaH5UnzeIdDtfESxtZIX3nPyBUWrCrYkE9gZonvyM64ldU2Qj5C8gz0iMa1g OSZ+5q5f7Ayty9bmvDVcHiMzpjlw6JS+M2WZNok+HkeMh6NzN2FOfTkMBaZB2UO2rOJL +w== 
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2jum58495t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Jun 2018 00:02:57 +0000
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w5T02tEY024448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 29 Jun 2018 00:02:56 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w5T02tJl002600; Fri, 29 Jun 2018 00:02:55 GMT
Received: from [10.0.1.37] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Jun 2018 17:02:55 -0700
From: Phil Hunt 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_022D6CB7-059E-42D4-B07C-D05FB4FD401C"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Thu, 28 Jun 2018 17:02:52 -0700
In-Reply-To: <5E0936CA-0B7C-4771-B317-31B40EE9EAA9@lodderstedt.net>
Cc: Mike Jones , "oauth@ietf.org" 
To: Torsten Lodderstedt 
References:   <5E0936CA-0B7C-4771-B317-31B40EE9EAA9@lodderstedt.net>
X-Mailer: Apple Mail (2.3445.8.2)
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8938 signatures=668703
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280261
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata is now RFC 8414
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2018 00:03:01 -0000

--Apple-Mail=_022D6CB7-059E-42D4-B07C-D05FB4FD401C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Congrats! Glad to see this one out!

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com =
phil.hunt@oracle.com =


> On Jun 28, 2018, at 5:00 PM, Torsten Lodderstedt =
 wrote:
>=20
> Congratulations!
>=20
> Am 28.06.2018 um 18:15 schrieb William Denniss =
>:
>=20
>> Congratulations!
>>=20
>> Really glad that we have an RFC specifying how servers should provide =
their configuration data in machine readable form. Helps with developer =
experience (less manual configuration), as well as mitigating mix-up =
attacks (better association of related endpoints), amongst other =
benefits.
>>=20
>> I'm happy to say that the AppAuth clients support RFC 8414, through =
discovery methods that take a complete URL =
, in addition to =
the issuer-based ones designed for OIDC usage.
>>=20
>>=20
>> On Thu, Jun 28, 2018 at 3:54 PM, Mike Jones =
> wrote:
>> The OAuth 2.0 Authorization Server Metadata specification is now RFC =
8414 .  The abstract =
describes the specification as:
>>=20
>> =20
>>=20
>> This specification defines a metadata format that an OAuth 2.0 client =
can use to obtain the information needed to interact with an OAuth 2.0 =
authorization server, including its endpoint locations and authorization =
server capabilities.
>>=20
>> =20
>>=20
>> The specification defines a JSON metadata representation for OAuth =
2.0 authorization servers that is compatible with OpenID Connect =
Discovery 1.0 =
.  This =
specification is a true instance of standardizing existing practice.  =
OAuth 2.0 deployments have been using the OpenID Connect metadata format =
to describe their endpoints and capabilities for years.  This RFC makes =
this existing practice a standard.
>>=20
>> =20
>>=20
>> Having a standard OAuth metadata format makes it easier for OAuth =
clients to configure connections to OAuth authorization servers..  See =
https://www.iana.org/assignments/oauth-parameters/oauth-parameters..xhtml#=
authorization-server-metadata =
 for the initial set of registered =
metadata values.
>>=20
>> =20
>>=20
>> Thanks to all of you who helped make this standard a reality!
>>=20
>> =20
>>=20
>>                                                        -- Mike
>>=20
>> =20
>>=20
>> P.S.  This announcement was also posted at =
http://self-issued.info/?p=3D1883  =
and as @selfissued .
>>=20
>> =20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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

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


--Apple-Mail=_022D6CB7-059E-42D4-B07C-D05FB4FD401C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Congrats! Glad to see this one out!



Phil

Oracle Corporation, Identity Cloud =
Services Architect
@independentid
www.independentid.com
phil.hunt@oracle.com





On Jun 28, 2018, at 5:00 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

Congratulations!

Am =
28.06.2018 um 18:15 schrieb William Denniss <wdenniss=3D40google.com@dmarc.ietf.org>:

Congratulations!
Really glad that we have an RFC specifying =
how servers should provide their configuration data in machine readable =
form. Helps with developer experience (less manual configuration), as =
well as mitigating mix-up attacks (better association of related =
endpoints), amongst other benefits.

I'm happy to say that =
the AppAuth clients support RFC 8414, through discovery methods that =
take a complete URL, in addition to the issuer-based ones =
designed for OIDC usage.


On Thu, Jun 28, 2018 at 3:54 PM, =
Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> =
wrote:









The OAuth 2.0 Authorization Server Metadata =
specification is now
RFC 8414.  The abstract describes the specification =
as:
 
This specification defines a metadata format =
that an OAuth 2.0 client can use to obtain the information needed to =
interact with an OAuth 2.0 authorization server, including its endpoint =
locations and authorization
 server capabilities.
 
The specification defines a JSON metadata =
representation for OAuth 2.0 authorization servers that is compatible =
with
OpenID Connect Discovery 1.0.  =
This specification is a true instance of standardizing existing =
practice.  OAuth 2.0 deployments have been using the OpenID Connect =
metadata format to describe
 their endpoints and capabilities for years.  This RFC makes this =
existing practice a standard.
 
Having a standard OAuth metadata format makes it =
easier for OAuth clients to configure connections to OAuth authorization =
servers..  See

https://www.iana.org/assignments/oauth-parameters/oauth-parameters..xhtml#authorization-server-metadata for the initial set of =
registered metadata values.
 
Thanks to all of you who helped make this standard a =
reality!
 
         =
            &n=
bsp;                  &nb=
sp;            =
;  -- Mike


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







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





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

=

--Apple-Mail=_022D6CB7-059E-42D4-B07C-D05FB4FD401C--


From nobody Thu Jun 28 17:12:22 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10510130E3B for ; Thu, 28 Jun 2018 17:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level: 
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tomitribe-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkavwlbZxeBL for ; Thu, 28 Jun 2018 17:12:16 -0700 (PDT)
Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2000D130DF1 for ; Thu, 28 Jun 2018 17:12:16 -0700 (PDT)
Received: by mail-pg0-x241.google.com with SMTP id b10-v6so3160891pgq.11 for ; Thu, 28 Jun 2018 17:12:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tomitribe-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=wVMWm+eBD/kCxERAXwOSpNmn89t2N8PPf75y7FvX8kc=; b=HWqYEBTPBNMqphOMzWdN7pyvhy/bLkU4E6U+BemlU7eOe8NuHMUDlRe1/BC7hn144t +eQWjLhgmWx0DBmvNFFx/EwibggHarHZIOJ162yjYyzcc5Bf9yVfQYscaHfSS/RHcbfP ZeSq0KoWjPtBJBwx7lz/UwPrYYkaiJoXG4gL5hV2ZdxmFoZ5dPyFE5099RaSibFHL4/T yPRWeECqoWmvP1DyjtgFwwA/UtAKDYUux4P5WXu3Ram/U3rbt7FpbQq7a1RIr6sndKm3 o3nZswiH2lMxWbrzIpWZmlp+SHtzSdWOegCtn9z8UN/b10FTPZsQ/1FgtYmeVISlTA+v EbMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=wVMWm+eBD/kCxERAXwOSpNmn89t2N8PPf75y7FvX8kc=; b=Mqfi7tNNtQO3f65tTmHCcuXGfIDtSFRi3v3BTg04DeVQtkO8BolJYOSpgM/k4nUHwL vbYsh6she1nnc7lIA3h3ikmBWM65i2WglCzJ/aFkXCHbwUJyhaRzfGBifCMxstBdCLuz qlTBMWopUJT9vezFFprwdwnkzuDn1lVcikdscubB3p9ndI70ZjyzNy7hrq5DBat+tHRP KP+hWrqfB8/PRtS10WDzJaDgpMIJ2jugwOpRpTfTAzt/05PwZuGfcS6a8Fm1xpzZzl7E y3T8gXgfKsBGNdUYUFT2Aj4Aia9Fh8COci4DhTsYDk8ogJfxx9XYemO4zqQZJDmHR+4e RZGA==
X-Gm-Message-State: APt69E0Dq73iR7iJl+E+19lJFn54lUEFsXTCS1Nmu+WfZ1Dm+gI9gfcg cvzdq5KIfMLEEIy5fSRxlld1MPtKIIU=
X-Google-Smtp-Source: AAOMgpcBkPE46BKHk999FHC/weZjB/GyKLi8v6AfuvPnt1m08LenbQcZO5SgHTd42nr0mdx34kgk+Q==
X-Received: by 2002:a62:1d97:: with SMTP id d145-v6mr12235624pfd.101.1530231135598;  Thu, 28 Jun 2018 17:12:15 -0700 (PDT)
Received: from [192.168.1.110] ([198.244.105.232]) by smtp.gmail.com with ESMTPSA id m7-v6sm8087934pfj.25.2018.06.28.17.12.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jun 2018 17:12:14 -0700 (PDT)
From: David Blevins 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_85403597-5247-473B-90CF-7FE3026B02E4"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 28 Jun 2018 17:12:14 -0700
In-Reply-To: 
Cc: "oauth@ietf.org" 
To: Mike Jones 
References: 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata is now RFC 8414
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2018 00:12:20 -0000

--Apple-Mail=_85403597-5247-473B-90CF-7FE3026B02E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

I'm a new face, but did want to say congratulations to all.  It's great =
to see this movement into the OAuth 2.0 umbrella.


--=20
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Jun 28, 2018, at 3:54 PM, Mike Jones =
 wrote:
>=20
> The OAuth 2.0 Authorization Server Metadata specification is now RFC =
8414 .  The abstract =
describes the specification as:
> =20
> This specification defines a metadata format that an OAuth 2.0 client =
can use to obtain the information needed to interact with an OAuth 2.0 =
authorization server, including its endpoint locations and authorization =
server capabilities.
> =20
> The specification defines a JSON metadata representation for OAuth 2.0 =
authorization servers that is compatible with OpenID Connect Discovery =
1.0 .  This =
specification is a true instance of standardizing existing practice.  =
OAuth 2.0 deployments have been using the OpenID Connect metadata format =
to describe their endpoints and capabilities for years.  This RFC makes =
this existing practice a standard.
> =20
> Having a standard OAuth metadata format makes it easier for OAuth =
clients to configure connections to OAuth authorization servers.  See =
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#a=
uthorization-server-metadata =
 for the initial set of registered =
metadata values.
> =20
> Thanks to all of you who helped make this standard a reality!
> =20
>                                                        -- Mike
> =20
> P.S.  This announcement was also posted at =
http://self-issued.info/?p=3D1883  =
and as @selfissued .
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =


--Apple-Mail=_85403597-5247-473B-90CF-7FE3026B02E4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

I'm a new face, but did want to say congratulations to all. =
 It's great to see this movement into the OAuth 2.0 umbrella.




-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

On Jun 28, 2018, at 3:54 PM, Mike Jones <Michael.Jones=3D40microsoft.com@dmarc.ietf.org> =
wrote:

The OAuth 2.0 Authorization Server Metadata specification is =
now RFC =
8414.  The abstract describes the specification as:
 
This=
 specification defines a metadata format that an OAuth 2.0 client can =
use to obtain the information needed to interact with an OAuth 2.0 =
authorization server, including its endpoint locations and authorization =
server capabilities.
 
The specification defines a JSON metadata representation for =
OAuth 2.0 authorization servers that is compatible with OpenID Connect Discovery 1.0.  This specification is =
a true instance of standardizing existing practice.  OAuth 2.0 =
deployments have been using the OpenID Connect metadata format to =
describe their endpoints and capabilities for years.  This RFC =
makes this existing practice a standard.
 
Having a standard OAuth metadata format =
makes it easier for OAuth clients to configure connections to OAuth =
authorization servers.  See https://www.iana.org/assignments/oauth-parameters/oauth-paramet=
ers.xhtml#authorization-server-metadata for the initial set of =
registered metadata values.
 
Thanks to all of you who helped make =
this standard a reality!
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;       -- Mike
 
P.S.  =
This announcement was also posted at http://self-issued.info/?p=3D1883 and as @selfissued.
 
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_85403597-5247-473B-90CF-7FE3026B02E4--


From nobody Thu Jun 28 21:50:47 2018
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B66130E64 for ; Thu, 28 Jun 2018 21:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nL9CLdNq6Bq for ; Thu, 28 Jun 2018 21:50:42 -0700 (PDT)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05376129C6A for ; Thu, 28 Jun 2018 21:50:41 -0700 (PDT)
Received: by mail-pf0-x241.google.com with SMTP id u16-v6so3635938pfh.3 for ; Thu, 28 Jun 2018 21:50:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QslFIOb8JYAFME4TPnS9shX8DTrXCMdJCdI8ihk6/bE=; b=dT2vouA8IYvV/1LdVuo83jHSFnXcP9dYb9o4kkYLEt+N3ypwLbOr79uiYpVGpZiznD kj4+6Qk+Nq56Sqv18WrOWYKtFQ9q19IU3HebvQjWeJfNZnRt6rD7vQIp28fpH9yH1JwK zxVA0Od+cJlHGyg8lGDtQ4cms9I8shXH+auD8AjHLLeej3qyxxl6mzj3r5E3v5OqUiBE dIWVhYFPMUq0GiOnWVAEFDSNpBB+DnOXUa5kwdviexe0P8olgTxe9/tEsfJtBNlS8TKY jh0lW5vNWoDfxsLTT+THGxeqOrGhN0cl4PVA71rD2wuYXtp+3jEDyHU2+UQxDa6YUc+I qSvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QslFIOb8JYAFME4TPnS9shX8DTrXCMdJCdI8ihk6/bE=; b=Nd3LRALx1US0DeLQhsc1b0t2w5qPcKQAPg9KpS4ZQBzBKbH7NLjSPDqiqbfGWedRey 1ieJ4g6L2HP/oWFI3HVGWA9oJQiWCnEVwqJIM3AtYklt0+Au14RDu6/pLlmqg3R6xWMn us0IFTnxw1iWsU8xP0OjD30ylD9ugJCSRPosRII7NeuZ2Lnf1zPz4VNKTziuYJ+jFk+Q 8ZrL0BVb1lo4cdPjDcggbbwnJqq+FSNZXGPQWfFQF/kMYskH3xXJpBxjDpWjxc9D8I8X h+ah4+UrKQhjMJe7tTvzrkNNF68UTSLby6yEWJJ4zdRWYVS6mALNHwfHpSx61E7hz5mh XLsw==
X-Gm-Message-State: APt69E3LO45O8HBMyn0NBvz0NtGT2KTDP7yzEJU5NgzvO20Kj4zD27dQ KDaHHxHPn+qoXHKXB9mVNipxDVSNvFLrg68nmAy5mQ==
X-Google-Smtp-Source: AAOMgpcEr6sz3ZHw/BoyvIJR/Z4xVK9oLUy6IozGY0ZSaAvqHF5o6MdHRKiWx9jk7knwSChN2OEAz8uaI/ybD4yoC2s=
X-Received: by 2002:a62:40dc:: with SMTP id f89-v6mr12789300pfd.194.1530247840636;  Thu, 28 Jun 2018 21:50:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:d598:0:0:0:0 with HTTP; Thu, 28 Jun 2018 21:50:40 -0700 (PDT)
In-Reply-To: 
References:  
From: Samuel Erdtman 
Date: Fri, 29 Jun 2018 06:50:40 +0200
Message-ID: 
To: David Blevins 
Cc: Mike Jones ,  "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000f5b3c6056fc09616"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata is now RFC 8414
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jun 2018 04:50:46 -0000

--000000000000f5b3c6056fc09616
Content-Type: text/plain; charset="UTF-8"

Well done!

On Fri, Jun 29, 2018 at 2:12 AM, David Blevins 
wrote:

> I'm a new face, but did want to say congratulations to all.  It's great to
> see this movement into the OAuth 2.0 umbrella.
>
>
> --
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
>
> On Jun 28, 2018, at 3:54 PM, Mike Jones  com@dmarc.ietf.org> wrote:
>
> The OAuth 2.0 Authorization Server Metadata specification is now RFC 8414
> .  The abstract describes the
> specification as:
>
> This specification defines a metadata format that an OAuth 2.0 client can
> use to obtain the information needed to interact with an OAuth 2.0
> authorization server, including its endpoint locations and authorization
> server capabilities.
>
> The specification defines a JSON metadata representation for OAuth 2.0
> authorization servers that is compatible with OpenID Connect Discovery 1.0
> .  This
> specification is a true instance of standardizing existing practice.  OAuth
> 2.0 deployments have been using the OpenID Connect metadata format to
> describe their endpoints and capabilities for years.  This RFC makes this
> existing practice a standard.
>
> Having a standard OAuth metadata format makes it easier for OAuth clients
> to configure connections to OAuth authorization servers.  See
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#
> authorization-server-metadata
> 
>  for the initial set of registered metadata values.
>
> Thanks to all of you who helped make this standard a reality!
>
>                                                        -- Mike
>
> P.S.  This announcement was also posted at http://self-issued.info/?p=1883
>  and as @selfissued .
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--000000000000f5b3c6056fc09616
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Well done!

On Fri, Jun 29, 2018 at 2:12 AM, David Blevins <d=
blevins@tomitribe.com> wrote:
I'm a new face, but did want to =
say congratulations to all.=C2=A0 It's great to see this movement into =
the OAuth 2.0 umbrella.
<=
div>



--=C2=A0
David Bl=
evins
http://twitter.com/dblevins
http://www.tomitribe.c=
om

On Ju=
n 28, 2018, at 3:54 PM, Mike Jones <Michael.Jones=3D40microsoft=
.com@dmarc.ietf.org> wrote:

The OAuth 2.0 Authorizati=
on Server Metadata specification is now=C2=A0RFC 8414.=C2=A0 The abstract describes the specificati=
on as:
=C2=A0
This specification defines a metadata format that an OAuth 2.0 client ca=
n use to obtain the information needed to interact with an OAuth 2.0 author=
ization server, including its endpoint locations and authorization server c=
apabilities.
=C2=A0
The specification defines a JSON metadata representation for OAuth 2.0 a=
uthorization servers that is compatible with=C2=A0OpenID Connect Discovery 1.0.=C2=
=A0 This specification is a true instance of standardizing existing practic=
e.=C2=A0 OAuth 2.0 deployments have been using the OpenID Connect metadata =
format to describe their endpoints and capabilities for years.=C2=A0 This R=
FC makes this existing practice a standard.
=
=C2=A0
Having a standard OAuth metadata format=
 makes it easier for OAuth clients to configure connections to OAuth author=
ization servers.=C2=A0 See=C2=A0https://ww=
w.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#authorization-server-metadata=C2=A0for the initial set of registered met=
adata values.
=C2=A0
Thanks to all of you who helped make this standard a reality!=

=C2=A0
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 -- Mike
=C2=A0
P.S.=C2=A0 This announcement was also posted at=C2=A0http://self-issued.info/?p=3D1883=C2=A0and as=C2=A0@selfissued.
<=
div style=3D"margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,san=
s-serif">=C2=A0
______________________________________=
_________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


__________________________________________=
_____

OAuth mailing list

OAuth@ietf.org

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





--000000000000f5b3c6056fc09616--