From hardjono@mit.edu Mon Oct 1 09:56:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1395711E80D5 for ; Mon, 1 Oct 2012 09:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWXL9vRtIwf3 for ; Mon, 1 Oct 2012 09:56:28 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 144AB11E8112 for ; Mon, 1 Oct 2012 09:56:27 -0700 (PDT) X-AuditID: 12074425-b7fcc6d00000091f-44-5069cb3afb3f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id D6.90.02335.A3BC9605; Mon, 1 Oct 2012 12:56:26 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q91GuGAI000782; Mon, 1 Oct 2012 12:56:16 -0400 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (OC11EXEDGE3.EXCHANGE.MIT.EDU [18.9.3.21]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id q91GuFH3008851; Mon, 1 Oct 2012 12:56:15 -0400 Received: from OC11EXHUB8.exchange.mit.edu (18.9.3.20) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Mon, 1 Oct 2012 12:55:58 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.236]) by OC11EXHUB8.exchange.mit.edu ([18.9.3.20]) with mapi id 14.02.0309.002; Mon, 1 Oct 2012 12:56:14 -0400 From: Thomas Hardjono To: Hannes Tschofenig , "oauth@ietf.org WG" Thread-Topic: New Version Notification for draft-hardjono-oauth-umacore-05.txt Thread-Index: AQHNn/UMj7f7TPydT0OpA3YtJtovfJekqwzA Date: Mon, 1 Oct 2012 16:56:13 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A108B55D9@OC11EXPO24.exchange.mit.edu> References: <20121001165147.20546.22871.idtracker@ietfa.amsl.com> In-Reply-To: <20121001165147.20546.22871.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [71.184.223.209] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0017_01CD9FD4.21817DB0" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUgUURzHebPrOiuOjaO2r02LRoMO1w6KzELMLqOiJTqoCBvd0V3cHXVm NZUiowLzykgj1zxTRLPLjDXLpA0rVzJrRUxCXPWPWBNTk8qLZhyv/z6/+R7v/ZiHSohMmRLV MUaaZSg9KXOREnIvX1VQq069OXvIP7DiZY9TYMuQQxaChD2obZKFlZf/Q9TIWZfdGlqvS6TZ TcEXXLTFN2uc4kb2J1V3VkpTwafQdCBHIb4NFqXXy0ReDtt7nvDsghL4GwBLTL3O4tAE4I/c Z3PDewC7bE1ScXgB4FTr1bmhCsA82ygQymT4Otg22egssCceAW3pHRKBPfCj8Hla2dx3Ncyw vpKJvBVWmoXzUFSK+8Hxz7N2DD8OG2v6EYEJfA+8/a5uNirHQ+GdgoLZKODv/cdaM+uR4ArY PVCMiPt4QvuX1oXdZhrsc0zCvsY2RLizBM8CsPevWIrh7rAlf0CaAxSmJV2mpT7TEp9o2giz 7DeAyKuheei+RORd8N7EW5nIa2Buht1Z5O1wsHkElAC0GvhoDCkqA6XTc3SkioukGIZmVYEB Bp0xgNYk1ALhRzvvW1sPciykBeAoIF2xEptWTThRiVyywQJWoAjphU006NSEW0SsJllLcdpw NkFPcxbgx5/V9/RhO1BKmViGJj2x5o+8D9NQySk0GztvW4lKSQXWpfl2jMCjKSMdQ9NxNDuv eqMoCTHOygfdWTqaTorS6Y2LMoLKLQCirnz5OcGDcXGUgdNFi7oVrFEqsIuCgAuCNoFZyM4/ YgdQ8Gt5YCcElyv/xBfSDr4Y4YtTqqOEYiO1KClTwamZGHvFQeyDlbiSfLnV3DnqNvbY5p6R mfOopve6dwvpSg8XnlEd/rrjQK5/8PfokrGTp8ODHJJLU689A8zsrbxV5x0518qUhvHh/g6G SnObYgbKspXLfpX6jfxUVY2tny4azE8fLjTHWyR34+WH6vYOh08e+W3eWRbSPV3q60OQUk5L bdkgYTnqP4GG6SCfAwAA Subject: [OAUTH-WG] FW: New Version Notification for draft-hardjono-oauth-umacore-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 16:56:29 -0000 ------=_NextPart_000_0017_01CD9FD4.21817DB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit __________________________________________ -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, October 01, 2012 12:52 PM To: Thomas Hardjono Subject: New Version Notification for draft-hardjono-oauth-umacore-05.txt A new version of I-D, draft-hardjono-oauth-umacore-05.txt has been successfully submitted by Thomas Hardjono and posted to the IETF repository. Filename: draft-hardjono-oauth-umacore Revision: 05 Title: User-Managed Access (UMA) Core Protocol Creation date: 2012-10-01 WG ID: Individual Submission Number of pages: 51 URL: http://www.ietf.org/internet-drafts/draft-hardjono-oauth-umacore-05.txt Status: http://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore Htmlized: http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-hardjono-oauth-umacore-05 Abstract: This specification defines the User-Managed Access (UMA) core protocol. This protocol provides a method for users to control access to their protected resources, residing on any number of host sites, through an authorization manager that governs access decisions based on user policy. The IETF Secretariat ------=_NextPart_000_0017_01CD9FD4.21817DB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP4DCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTMMIIDtKADAgECAhB4Uq7mlIth1FJ90gEtCu8wMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwMzA2MDAwMDAwWhcNMTMwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9u bzEfMB0GCSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAmPCe+VCa3OQBiPsHUyh69qmKngwP6dHrXQtHphyr1P9LnMHdF+DletpaSm1b4HXjqbzm Ne/dj5169ZzwMjFdl3cVYGbZTvILmHNXH0kSlYl4NM/59ri+UBnV3oBnXg+g3Vhet6MDWJn/7exV AY4u5SpM7I+b+yQwDlTT90rJbXcCAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAL BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh bElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAthQJhe+BCY99zTBcAG73fFOmROKAFQyQLxzV mJLBy8HV2hNXVA8qL87UpbBLcWT3+qDmMYn70X3Hhj+givCw0hLLeEpOWWRtXSuGt7MNrjQR1sNz Zl+NJQN+S9kl1AzYMec19OE8D+5A8WbOna8aWhGmMISqwJ3FBt6VUFIosTUGTHLI9H+LrgENQMif jCrY2PoLZvsgdQRtwhYTMbbeSLWuHILpZn2zEluSU6drzaTBPIA5uOUAtwCPRfocAzTh/mvfJ51y MNoLjFeZaovhhUdeBYJaI78y55A0nBsGyYQvYdESuqJf1UCGIK76M3c37q5YZOvmVA6sIloOcWk1 wzCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq +mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9Ix slQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMD rho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n 0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UC AwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4a HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIw YKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUY MCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEf MB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD 9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykg MTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0g RzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJ bOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeL eo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs 6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I 0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHML sbyg2lJY3QoOf8GCMYIEuDCCBLQCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQeFKu5pSLYdRSfdIBLQrvMDAJBgUrDgMCGgUAoIIDGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMDExNjU2MTBaMCMG CSqGSIb3DQEJBDEWBBRm6c1uae3INAkI/dYepu3JxW4BVTCBqwYJKoZIhvcNAQkPMYGdMIGaMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCCAQMGCSsGAQQBgjcQBDGB9TCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhB4 Uq7mlIth1FJ90gEtCu8wMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQeFKu5pSLYdRSfdIBLQrvMDANBgkq hkiG9w0BAQEFAASBgGQYzuKnLPsk4vrX9bcWlfHEBzfrxcBnSH/+mQgSyoGAMPLSwJqVDkxmGNtj NiRWGB0wF1GP+SYHd1P+oYcy9nitubCYgpI1fkEB56fQ7YLmnhLhO6MiKNXYZ7QrFswPNMSHaCFf 0ObSpAJxk5ywFSbD3EgJtfhaHyse99q+PJrYAAAAAAAA ------=_NextPart_000_0017_01CD9FD4.21817DB0-- From wwwrun@rfc-editor.org Thu Oct 4 15:34:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E897121F8505; Thu, 4 Oct 2012 15:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.319 X-Spam-Level: X-Spam-Status: No, score=-102.319 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyYoGWVqgyzY; Thu, 4 Oct 2012 15:34:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 87F3221F84DC; Thu, 4 Oct 2012 15:34:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 94498B1E002; Thu, 4 Oct 2012 15:30:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121004223020.94498B1E002@rfc-editor.org> Date: Thu, 4 Oct 2012 15:30:20 -0700 (PDT) Cc: oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 6755 on An IETF URN Sub-Namespace for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 22:34:52 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6755 Title: An IETF URN Sub-Namespace for OAuth Author: B. Campbell, H. Tschofenig Status: Informational Stream: IETF Date: October 2012 Mailbox: brian.d.campbell@gmail.com, hannes.tschofenig@gmx.net Pages: 5 Characters: 8336 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-urn-sub-ns-06.txt URL: http://www.rfc-editor.org/rfc/rfc6755.txt This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Web Authorization Protocol Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From Michael.Jones@microsoft.com Thu Oct 4 16:04:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956D821F8645 for ; Thu, 4 Oct 2012 16:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.714 X-Spam-Level: X-Spam-Status: No, score=-3.714 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCuTFhp3P280 for ; Thu, 4 Oct 2012 16:04:42 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6918E21F8643 for ; Thu, 4 Oct 2012 16:04:42 -0700 (PDT) Received: from mail28-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 4 Oct 2012 23:04:41 +0000 Received: from mail28-am1 (localhost [127.0.0.1]) by mail28-am1-R.bigfish.com (Postfix) with ESMTP id 496644A0189; Thu, 4 Oct 2012 23:04:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(z551biz9371Id6eah542Mzz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275dhz2fh2a8h668h839h944hd25hf0ah107ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1155h) Received-SPF: pass (mail28-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail28-am1 (localhost.localdomain [127.0.0.1]) by mail28-am1 (MessageSwitch) id 1349391873678546_14080; Thu, 4 Oct 2012 23:04:33 +0000 (UTC) Received: from AM1EHSMHS012.bigfish.com (unknown [10.3.201.247]) by mail28-am1.bigfish.com (Postfix) with ESMTP id 9930930004D; Thu, 4 Oct 2012 23:04:33 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS012.bigfish.com (10.3.207.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 4 Oct 2012 23:04:32 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.31]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Thu, 4 Oct 2012 23:04:29 +0000 From: Mike Jones To: Brian Campbell , Hannes Tschofenig Thread-Topic: [OAUTH-WG] RFC 6755 on An IETF URN Sub-Namespace for OAuth Thread-Index: AQHNooCe8/6AI1cKPUGe4O2qSfpBJ5epxA2g Date: Thu, 4 Oct 2012 23:04:28 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436680231E@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20121004223020.94498B1E002@rfc-editor.org> In-Reply-To: <20121004223020.94498B1E002@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 6755 on An IETF URN Sub-Namespace for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 23:04:44 -0000 Congratulations on completing the first OAuth working group RFC!!! -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of r= fc-editor@rfc-editor.org Sent: Thursday, October 04, 2012 3:30 PM To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: oauth@ietf.org; rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 6755 on An IETF URN Sub-Namespace for OAuth A new Request for Comments is now available in online RFC libraries. =20 RFC 6755 Title: An IETF URN Sub-Namespace for=20 OAuth=20 Author: B. Campbell, H. Tschofenig Status: Informational Stream: IETF Date: October 2012 Mailbox: brian.d.campbell@gmail.com,=20 hannes.tschofenig@gmx.net Pages: 5 Characters: 8336 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-urn-sub-ns-06.txt URL: http://www.rfc-editor.org/rfc/rfc6755.txt This document establishes an IETF URN Sub-namespace for use with OAuth-rela= ted specifications. This document is not an Internet Standards Track speci= fication; it is published for informational purposes. This document is a product of the Web Authorization Protocol Working Group = of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this = memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author = of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifical= ly noted otherwise on the RFC itself, all RFCs are for unlimited distributi= on. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Fri Oct 5 01:03:46 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443B221F8471 for ; Fri, 5 Oct 2012 01:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GD-5HtJ5zSm for ; Fri, 5 Oct 2012 01:03:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id D84E621F846F for ; Fri, 5 Oct 2012 01:03:44 -0700 (PDT) Received: (qmail invoked by alias); 05 Oct 2012 08:03:43 -0000 Received: from unknown (EHLO [10.255.128.40]) [194.251.119.201] by mail.gmx.net (mp024) with SMTP; 05 Oct 2012 10:03:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+LWEIMCtOLrOxm2o261AveqWVhdF6Ddarp/LA/7M TNDRoxXY8FDUNj From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Oct 2012 11:03:41 +0300 Message-Id: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 08:03:46 -0000 Hi all,=20 here is an agenda proposal for the Atlanta IETF meeting:=20 (The indicated names are proposals.) ------ Agenda: 1. Status Update, Agenda Bashing (Chairs) 2. Token Revocation (Thorsten) 3. Assertions (Brian + Mike) 4. OAuth Use Cases (Zachary) 5. JWT (Mike) 6. Security (Phil)=20 7. Dynamic Client Registration (Thomas) 8. Roadmap ------ In the last item we would like to discuss the bigger picture of how to = get OAuth 2.0 deployment improved. There are at least 2 parts to this, = namely (a) what other specifications do we need to work on, and (b) how = do we improve interoperability.=20 Let us know whether you think that this fits your needs.=20 Ciao Hannes & Derek PS: I am hoping to see daft updates of the WG items soon.=20 From torsten@lodderstedt.net Sat Oct 6 10:07:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BFF21F853B for ; Sat, 6 Oct 2012 10:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsyDKipYukRj for ; Sat, 6 Oct 2012 10:07:33 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD8521F853A for ; Sat, 6 Oct 2012 10:07:32 -0700 (PDT) Received: from [79.253.24.187] (helo=[192.168.71.42]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TKXqV-0004Hh-FL; Sat, 06 Oct 2012 19:07:23 +0200 Message-ID: <5070654D.40007@lodderstedt.net> Date: Sat, 06 Oct 2012 19:07:25 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> In-Reply-To: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 17:07:34 -0000 fine for me Am 05.10.2012 10:03, schrieb Hannes Tschofenig: > Hi all, > > here is an agenda proposal for the Atlanta IETF meeting: > (The indicated names are proposals.) > > ------ > Agenda: > > 1. Status Update, Agenda Bashing (Chairs) > 2. Token Revocation (Thorsten) > 3. Assertions (Brian + Mike) > 4. OAuth Use Cases (Zachary) > 5. JWT (Mike) > 6. Security (Phil) > 7. Dynamic Client Registration (Thomas) > 8. Roadmap > ------ > > In the last item we would like to discuss the bigger picture of how to get OAuth 2.0 deployment improved. There are at least 2 parts to this, namely (a) what other specifications do we need to work on, and (b) how do we improve interoperability. > > Let us know whether you think that this fits your needs. > > Ciao > Hannes & Derek > > PS: I am hoping to see daft updates of the WG items soon. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From prabath@wso2.com Sat Oct 6 10:29:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B827921F8470 for ; Sat, 6 Oct 2012 10:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ky6L9WHxdVwd for ; Sat, 6 Oct 2012 10:29:19 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43DEB21F846D for ; Sat, 6 Oct 2012 10:29:19 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so3395423vbb.31 for ; Sat, 06 Oct 2012 10:29:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=UdzHUX8pcWskCFHUybp1+wshe2PTXaa47EscClyI7EE=; b=BydgXp8jHsxZ7SX32asrM1MRqByAuktmZEIkbNVw1KskpvwVd8tHxF1RVBjN12ZTsH DWRkAfUIeOD72rqjxY/O3umD7eyjiyEAwiu0NaM+TrvEO/fCHG4jL8pENLknhrMBTev3 0FtCOT55563yQim2GnGFNjZBiNh1ZZzifkr4eMLaey97URh54/4xbI65h88pm9QEV6fW 68ZRGC7Yng7od1PJcQtkHqEQbfxvtPI+FZ74lD/25ayZ6/R03Mv5SdWd2XCc0BUqi6NC QqKIeRxo78yp7gC22wLDlBu1kMlmZd/XHk+sqAen7eK4uTUepcfRQ+ixMZSeUDUnjTV1 MkJA== MIME-Version: 1.0 Received: by 10.52.37.103 with SMTP id x7mr3870826vdj.61.1349544558457; Sat, 06 Oct 2012 10:29:18 -0700 (PDT) Received: by 10.59.0.129 with HTTP; Sat, 6 Oct 2012 10:29:18 -0700 (PDT) Date: Sat, 6 Oct 2012 10:29:18 -0700 Message-ID: From: Prabath Siriwardena To: oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnQLGHq1lHg7gWiM+tZ/YSafaR0wPjo8dXhsLamD6vkb3O0njmuxHz7rUZZmjtC+O2zi7R2 Subject: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 17:29:20 -0000 Hi folks, I would like to know your thoughts on the $subject.. For me it looks like a concrete use case where OAuth conceptually does address - but protocol does not well defined.. Please find [1] for further details... [1]: http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com From internet-drafts@ietf.org Sat Oct 6 10:30:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921FF21F846D; Sat, 6 Oct 2012 10:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCjyFtTxX8u0; Sat, 6 Oct 2012 10:30:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E9D21F8470; Sat, 6 Oct 2012 10:30:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121006173035.348.70813.idtracker@ietfa.amsl.com> Date: Sat, 06 Oct 2012 10:30:35 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 17:30:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : Token Revocation Author(s) : Torsten Lodderstedt Stefanie Dronia Marius Scurtescu Filename : draft-ietf-oauth-revocation-01.txt Pages : 7 Date : 2012-10-06 Abstract: This draft proposes an additional endpoint for OAuth authorization servers for revoking tokens. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-revocation-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-revocation-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Sat Oct 6 10:37:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E5C21F8530 for ; Sat, 6 Oct 2012 10:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, HELO_EQ_DE=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51SDTF1tCKeS for ; Sat, 6 Oct 2012 10:37:16 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.94]) by ietfa.amsl.com (Postfix) with ESMTP id B9CDE21F846D for ; Sat, 6 Oct 2012 10:37:15 -0700 (PDT) Received: from [79.253.24.187] (helo=[192.168.71.42]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TKYJN-0003cM-Lt for oauth@ietf.org; Sat, 06 Oct 2012 19:37:13 +0200 Message-ID: <50706C4B.4020106@lodderstedt.net> Date: Sat, 06 Oct 2012 19:37:15 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 CC: oauth@ietf.org References: <20121006173035.348.70813.idtracker@ietfa.amsl.com> In-Reply-To: <20121006173035.348.70813.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-01.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 17:37:17 -0000 Hi all, the new revision addresses two issues raised on the list: - The draft now gives a more precise description of the semantics of the revocation request based on the concept of the underlying access grant. - We incoporated CORS (in addition to JSONP) and renamed the respective section to "Cross-Origin Support" regards, Torsten. Am 06.10.2012 19:30, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > > Title : Token Revocation > Author(s) : Torsten Lodderstedt > Stefanie Dronia > Marius Scurtescu > Filename : draft-ietf-oauth-revocation-01.txt > Pages : 7 > Date : 2012-10-06 > > Abstract: > This draft proposes an additional endpoint for OAuth authorization > servers for revoking tokens. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-revocation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-revocation-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Sat Oct 6 11:53:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574ED21F8435 for ; Sat, 6 Oct 2012 11:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSoW3zd4nSz2 for ; Sat, 6 Oct 2012 11:53:35 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 8F92621F8432 for ; Sat, 6 Oct 2012 11:53:35 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q96IrVnH016847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Oct 2012 18:53:32 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q96IrV6f013348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Oct 2012 18:53:31 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q96IrUW8014702; Sat, 6 Oct 2012 13:53:30 -0500 Received: from [192.168.1.125] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 06 Oct 2012 11:53:30 -0700 References: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> <5070654D.40007@lodderstedt.net> Mime-Version: 1.0 (1.0) In-Reply-To: <5070654D.40007@lodderstedt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <97A330AD-C451-4472-B38C-EF59034EC810@oracle.com> X-Mailer: iPhone Mail (10A403) From: Phil Hunt Date: Sat, 6 Oct 2012 11:53:30 -0700 To: Torsten Lodderstedt X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 18:53:36 -0000 +1 Phil On 2012-10-06, at 10:07, Torsten Lodderstedt wrote= : > fine for me >=20 > Am 05.10.2012 10:03, schrieb Hannes Tschofenig: >> Hi all, >>=20 >> here is an agenda proposal for the Atlanta IETF meeting: >> (The indicated names are proposals.) >>=20 >> ------ >> Agenda: >>=20 >> 1. Status Update, Agenda Bashing (Chairs) >> 2. Token Revocation (Thorsten) >> 3. Assertions (Brian + Mike) >> 4. OAuth Use Cases (Zachary) >> 5. JWT (Mike) >> 6. Security (Phil) >> 7. Dynamic Client Registration (Thomas) >> 8. Roadmap >> ------ >>=20 >> In the last item we would like to discuss the bigger picture of how to ge= t OAuth 2.0 deployment improved. There are at least 2 parts to this, namely (= a) what other specifications do we need to work on, and (b) how do we improv= e interoperability. >>=20 >> Let us know whether you think that this fits your needs. >>=20 >> Ciao >> Hannes & Derek >>=20 >> PS: I am hoping to see daft updates of the WG items soon. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From internet-drafts@ietf.org Sat Oct 6 13:48:41 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730ED21F8443; Sat, 6 Oct 2012 13:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxlmWPfPlRh5; Sat, 6 Oct 2012 13:48:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B3821F846E; Sat, 6 Oct 2012 13:48:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121006204841.11985.42673.idtracker@ietfa.amsl.com> Date: Sat, 06 Oct 2012 13:48:41 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 20:48:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth 2.0 Threat Model and Security Considerations Author(s) : Torsten Lodderstedt Mark McGloin Phil Hunt Filename : draft-ietf-oauth-v2-threatmodel-08.txt Pages : 71 Date : 2012-10-06 Abstract: This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-v2-threatmodel-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From torsten@lodderstedt.net Sat Oct 6 13:51:42 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988D221F847D for ; Sat, 6 Oct 2012 13:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.34 X-Spam-Level: X-Spam-Status: No, score=-1.34 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, HELO_EQ_DE=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGpjUwXwGVfR for ; Sat, 6 Oct 2012 13:51:41 -0700 (PDT) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.18.15]) by ietfa.amsl.com (Postfix) with ESMTP id 84F8621F847C for ; Sat, 6 Oct 2012 13:51:41 -0700 (PDT) Received: from [79.253.24.187] (helo=[192.168.71.42]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TKbLX-0008Hk-2j for oauth@ietf.org; Sat, 06 Oct 2012 22:51:39 +0200 Message-ID: <507099DD.5080508@lodderstedt.net> Date: Sat, 06 Oct 2012 22:51:41 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 CC: oauth@ietf.org References: <20121006204841.11985.42673.idtracker@ietfa.amsl.com> In-Reply-To: <20121006204841.11985.42673.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-threatmodel-08.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 20:51:42 -0000 Hi all, this revision addresses the comments from IESG review. regards, Torsten. Am 06.10.2012 22:48, schrieb internet-drafts@ietf.org: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Web Authorization Protocol Working Group of the IETF. > > Title : OAuth 2.0 Threat Model and Security Considerations > Author(s) : Torsten Lodderstedt > Mark McGloin > Phil Hunt > Filename : draft-ietf-oauth-v2-threatmodel-08.txt > Pages : 71 > Date : 2012-10-06 > > Abstract: > This document gives additional security considerations for OAuth, > beyond those in the OAuth 2.0 specification, based on a comprehensive > threat model for the OAuth 2.0 Protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-threatmodel-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Sun Oct 7 09:08:55 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B9E21F86A3 for ; Sun, 7 Oct 2012 09:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQ-sqp4Zk0Ep for ; Sun, 7 Oct 2012 09:08:54 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE2E21F8508 for ; Sun, 7 Oct 2012 09:08:54 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q97G8p20006352 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 7 Oct 2012 18:08:51 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 7 Oct 2012 18:08:51 +0200 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.198]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Sun, 7 Oct 2012 12:08:49 -0400 From: "Zeltsan, Zachary (Zachary)" To: "'Phil Hunt'" , "'Torsten Lodderstedt'" Thread-Topic: [OAUTH-WG] Agenda for Atlanta Meeting Thread-Index: AQHNos/48a/YLsJpk0CSiL5CEZ/nNJesx4uAgAAdowCAASEdYA== Date: Sun, 7 Oct 2012 16:08:48 +0000 Message-ID: References: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> <5070654D.40007@lodderstedt.net> <97A330AD-C451-4472-B38C-EF59034EC810@oracle.com> In-Reply-To: <97A330AD-C451-4472-B38C-EF59034EC810@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "'oauth@ietf.org WG'" Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 16:08:55 -0000 +1 Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Saturday, October 06, 2012 2:54 PM To: Torsten Lodderstedt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting +1 Phil On 2012-10-06, at 10:07, Torsten Lodderstedt wrot= e: > fine for me >=20 > Am 05.10.2012 10:03, schrieb Hannes Tschofenig: >> Hi all, >>=20 >> here is an agenda proposal for the Atlanta IETF meeting: >> (The indicated names are proposals.) >>=20 >> ------ >> Agenda: >>=20 >> 1. Status Update, Agenda Bashing (Chairs) >> 2. Token Revocation (Thorsten) >> 3. Assertions (Brian + Mike) >> 4. OAuth Use Cases (Zachary) >> 5. JWT (Mike) >> 6. Security (Phil) >> 7. Dynamic Client Registration (Thomas) >> 8. Roadmap >> ------ >>=20 >> In the last item we would like to discuss the bigger picture of how to g= et OAuth 2.0 deployment improved. There are at least 2 parts to this, namel= y (a) what other specifications do we need to work on, and (b) how do we im= prove interoperability. >>=20 >> Let us know whether you think that this fits your needs. >>=20 >> Ciao >> Hannes & Derek >>=20 >> PS: I am hoping to see daft updates of the WG items soon. >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eve@xmlgrrl.com Sun Oct 7 11:05:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E5A21F86D8 for ; Sun, 7 Oct 2012 11:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMKq0wrXQwHl for ; Sun, 7 Oct 2012 11:05:30 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3C69321F86D6 for ; Sun, 7 Oct 2012 11:05:29 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q97I5SB2019040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 7 Oct 2012 11:05:28 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: Date: Sun, 7 Oct 2012 11:05:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2FA4048C-5AC4-4C0F-A649-785AB8368B31@xmlgrrl.com> References: To: Prabath Siriwardena X-Mailer: Apple Mail (2.1498) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 18:05:33 -0000 Hi Prabath, As far as I know, OAuth itself generally isn't used to let one human = resource owner delegate access to a different human resource owner. = However, UMA (which leverages OAuth) does strive to solve exactly this = use case, among other similar ones; we call this one "person-to-person = sharing", and you can read more about it here: = http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1 The UMA flow at run time still ends up being effectively = "client-initiated" (we would say requesting-party-initiated, using a = requester app) because the original resource owner (we call it an = authorizing party) is no longer around by then. The authz party would = set up policies at some point before going on vacation, and these = polices would enable the requesting party to "qualify in" for access at = run time, by supplying identity claims that get used in an authorization = check by the authz server (authz manager). We'll be walking through UMA flows and demoing an extensive use case at = a webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg Hope this helps, Eve On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena = wrote: > Hi folks, >=20 > I would like to know your thoughts on the $subject.. >=20 > For me it looks like a concrete use case where OAuth conceptually does > address - but protocol does not well defined.. >=20 > Please find [1] for further details... >=20 > [1]: = http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.h= tml >=20 > -- > Thanks & Regards, > Prabath >=20 > Mobile : +94 71 809 6732 >=20 > http://blog.facilelogin.com > http://RampartFAQ.com > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From prabath@wso2.com Sun Oct 7 17:08:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC921F86C2 for ; Sun, 7 Oct 2012 17:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax-PwQRsQaIV for ; Sun, 7 Oct 2012 17:08:17 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0426C21F8681 for ; Sun, 7 Oct 2012 17:08:16 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4266353vcb.31 for ; Sun, 07 Oct 2012 17:08:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=LK3UsisUgPOf3Ed8yMpEpwQX9qNBZtd/RlVverR5vZE=; b=J1YV/cQ9T9ybQT2HQiuQrOcL62W4Mui6fRQXkeXJUNP3qvKwDQRd5T5xeobWr1LQlp aLz1NmY6YGjlNDr5i5MeoTsMq+JX5inLI/VINrfdAPeXZd9JwcxHd/ZsXsEQJsGdLW47 fqGE6Jn0jmsypGbD0B6TbVirL37LdgS90GlA9cW9T33En9m79S/vGqFCqDCRZamGOkv4 5LQLHzpdEtoe9NJVm02zy4RTEiM+VdBAx/jGPhVVdlO79xVjqMmgkSw4XqL4+s7n39YD hMqpDyOr0/26zuI3t8TZeADHK2KdwpIqKMkrEq04M9VXtV4zNCNRtpxzOJzJCc1vc5dD 7pAQ== MIME-Version: 1.0 Received: by 10.52.92.11 with SMTP id ci11mr7085780vdb.7.1349654896072; Sun, 07 Oct 2012 17:08:16 -0700 (PDT) Received: by 10.59.0.129 with HTTP; Sun, 7 Oct 2012 17:08:16 -0700 (PDT) In-Reply-To: <2FA4048C-5AC4-4C0F-A649-785AB8368B31@xmlgrrl.com> References: <2FA4048C-5AC4-4C0F-A649-785AB8368B31@xmlgrrl.com> Date: Sun, 7 Oct 2012 17:08:16 -0700 Message-ID: From: Prabath Siriwardena To: Eve Maler Content-Type: multipart/alternative; boundary=20cf3071ce0aa6560c04cb81046e X-Gm-Message-State: ALoCoQlwPu+3UJNWUNZUDLHGkpGAvdTQ1h95OmgEDzpIvgRtGR1Px7+wqe5p/0q/TRumhsTAOLTw Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 00:08:18 -0000 --20cf3071ce0aa6560c04cb81046e Content-Type: text/plain; charset=ISO-8859-1 Hi Eve, Thanks for pointers.. I've been following the work done in UMA.. Sure.. will join the webinar... BTW .. I am not quite sure UMA addresses my use case. Even in the case of UMA it's client initiated or requestor initiated... Please correct me if I am wrong... but in OAuth specification there is no restrictions to identify the 'client' as a person, organization or as him self.. In my view - this is an extended grant type..which has two phases.. 1. Resource owner grants access to a selected a Client 2. Client requests the already available access token for him from the Authorization Server.[just like passing the refresh_token] WDYT ? Thanks & regards, -Prabath On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler wrote: > Hi Prabath, > > As far as I know, OAuth itself generally isn't used to let one human > resource owner delegate access to a different human resource owner. > However, UMA (which leverages OAuth) does strive to solve exactly this use > case, among other similar ones; we call this one "person-to-person > sharing", and you can read more about it here: > http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1 > > The UMA flow at run time still ends up being effectively > "client-initiated" (we would say requesting-party-initiated, using a > requester app) because the original resource owner (we call it an > authorizing party) is no longer around by then. The authz party would set > up policies at some point before going on vacation, and these polices would > enable the requesting party to "qualify in" for access at run time, by > supplying identity claims that get used in an authorization check by the > authz server (authz manager). > > We'll be walking through UMA flows and demoing an extensive use case at a > webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg > > Hope this helps, > > Eve > > On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena wrote: > > > Hi folks, > > > > I would like to know your thoughts on the $subject.. > > > > For me it looks like a concrete use case where OAuth conceptually does > > address - but protocol does not well defined.. > > > > Please find [1] for further details... > > > > [1]: > http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.html > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > > -- Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --20cf3071ce0aa6560c04cb81046e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Eve,

Thanks for pointers.. I've been following th= e work done in UMA.. Sure.. will join the webinar...

BTW .. I am not quite sure UMA addresses my use case. Even in the case o= f UMA it's client initiated or requestor initiated...

Please correct me if I am wrong... but in OAuth specifi= cation there is no restrictions to identify the 'client' as a perso= n, organization or as him self..=A0

In my view - t= his is an extended grant type..which has two phases..

1. Resource owner grants access to a selected a Client<= /div>
2. Client requests the already available access token for him fro= m the Authorization Server.[just like passing the refresh_token]

WDYT ?

Thanks & regards,
<= div>-Prabath=A0

On Sun, Oct 7, 201= 2 at 11:05 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Hi Prabath,

As far as I know, OAuth itself generally isn't used to let one human re= source owner delegate access to a different human resource owner. However, = UMA (which leverages OAuth) does strive to solve exactly this use case, amo= ng other similar ones; we call this one "person-to-person sharing"= ;, and you can read more about it here: http://docs.k= antarainitiative.org/uma/draft-uma-trust.html#anchor1

The UMA flow at run time still ends up being effectively "client-initi= ated" (we would say requesting-party-initiated, using a requester app)= because the original resource owner (we call it an authorizing party) is n= o longer around by then. The authz party would set up policies at some poin= t before going on vacation, and these polices would enable the requesting p= arty to "qualify in" for access at run time, by supplying identit= y claims that get used in an authorization check by the authz server (authz= manager).

We'll be walking through UMA flows and demoing an extensive use case at= a webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg

Hope this helps,

=A0 =A0 =A0 =A0 Eve

On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <prabath@wso2.com> wrote:

> Hi folks,
>
> I would like to know your thoughts on the $subject..
>
> For me it looks like a concrete use case where OAuth conceptually does=
> address - but protocol does not well defined..
>
> Please find [1] for further details...
>
> [1]: http://blog.facilelogin.com/2012= /10/ationwhat-oauth-lacks-resource-owner.html
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.= facilelogin.com
> http://RampartFAQ.= com
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


Eve Maler =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0http://www.xml= grrl.com/blog
+1 425 345 6= 756=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0http://www.twitter.com/xmlgrrl<= /a>





--
Thanks &= Regards,
Prabath


--20cf3071ce0aa6560c04cb81046e-- From zhou.sujing@zte.com.cn Sun Oct 7 18:24:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8E021F8736; Sun, 7 Oct 2012 18:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.49 X-Spam-Level: X-Spam-Status: No, score=-97.49 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg77gmgTpO05; Sun, 7 Oct 2012 18:24:43 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4D14E21F8735; Sun, 7 Oct 2012 18:24:43 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 348E91934134; Mon, 8 Oct 2012 09:24:38 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 21C9C183BBD1; Mon, 8 Oct 2012 09:21:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q981OVpY028919; Mon, 8 Oct 2012 09:24:31 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Prabath Siriwardena MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 8 Oct 2012 09:24:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-08 09:24:32, Serialize complete at 2012-10-08 09:24:32 Content-Type: multipart/alternative; boundary="=_alternative 0007D03B48257A91_=" X-MAIL: mse02.zte.com.cn q981OVpY028919 Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 01:24:44 -0000 This is a multipart message in MIME format. --=_alternative 0007D03B48257A91_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksICBQcmFiYQ0KDQogIEkgYW0gYWxzbyB0aGlua2luZyBvbiB0aGlzIHN1YmplY3QsIGFuZCBw dWJsaXNoZWQgYSBkcmFmdCBvbiBpdC4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC16 aG91LW9hdXRoLW93bmVyLWF1dGgtMDAudHh0DQogIEknZCBsaWtlIHRvIGhhdmUgeW91ciBvcGlu aW9uLg0KIA0KDQoNCg0KUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbT4gDQq3 orz+yMs6ICBvYXV0aC1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTEwLTA4IDA4OjA4DQoNCsrVvP7I yw0KRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb20+DQqzrcvNDQpvYXV0aEBpZXRmLm9yZw0K1vfM 4g0KUmU6IFtPQVVUSC1XR10gUmVzb3VyY2Ugb3duZXIgaW5pdGlhdGVkIE9BdXRoIGRlbGVnYXRp b24NCg0KDQoNCg0KDQoNCkhpIEV2ZSwNCg0KVGhhbmtzIGZvciBwb2ludGVycy4uIEkndmUgYmVl biBmb2xsb3dpbmcgdGhlIHdvcmsgZG9uZSBpbiBVTUEuLiBTdXJlLi4gDQp3aWxsIGpvaW4gdGhl IHdlYmluYXIuLi4NCg0KQlRXIC4uIEkgYW0gbm90IHF1aXRlIHN1cmUgVU1BIGFkZHJlc3NlcyBt eSB1c2UgY2FzZS4gRXZlbiBpbiB0aGUgY2FzZSBvZiANClVNQSBpdCdzIGNsaWVudCBpbml0aWF0 ZWQgb3IgcmVxdWVzdG9yIGluaXRpYXRlZC4uLg0KDQpQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFt IHdyb25nLi4uIGJ1dCBpbiBPQXV0aCBzcGVjaWZpY2F0aW9uIHRoZXJlIGlzIG5vIA0KcmVzdHJp Y3Rpb25zIHRvIGlkZW50aWZ5IHRoZSAnY2xpZW50JyBhcyBhIHBlcnNvbiwgb3JnYW5pemF0aW9u IG9yIGFzIGhpbSANCnNlbGYuLiANCg0KSW4gbXkgdmlldyAtIHRoaXMgaXMgYW4gZXh0ZW5kZWQg Z3JhbnQgdHlwZS4ud2hpY2ggaGFzIHR3byBwaGFzZXMuLg0KDQoxLiBSZXNvdXJjZSBvd25lciBn cmFudHMgYWNjZXNzIHRvIGEgc2VsZWN0ZWQgYSBDbGllbnQNCjIuIENsaWVudCByZXF1ZXN0cyB0 aGUgYWxyZWFkeSBhdmFpbGFibGUgYWNjZXNzIHRva2VuIGZvciBoaW0gZnJvbSB0aGUgDQpBdXRo b3JpemF0aW9uIFNlcnZlci5banVzdCBsaWtlIHBhc3NpbmcgdGhlIHJlZnJlc2hfdG9rZW5dDQoN CldEWVQgPw0KDQpUaGFua3MgJiByZWdhcmRzLA0KLVByYWJhdGggDQoNCk9uIFN1biwgT2N0IDcs IDIwMTIgYXQgMTE6MDUgQU0sIEV2ZSBNYWxlciA8ZXZlQHhtbGdycmwuY29tPiB3cm90ZToNCkhp IFByYWJhdGgsDQoNCkFzIGZhciBhcyBJIGtub3csIE9BdXRoIGl0c2VsZiBnZW5lcmFsbHkgaXNu J3QgdXNlZCB0byBsZXQgb25lIGh1bWFuIA0KcmVzb3VyY2Ugb3duZXIgZGVsZWdhdGUgYWNjZXNz IHRvIGEgZGlmZmVyZW50IGh1bWFuIHJlc291cmNlIG93bmVyLiANCkhvd2V2ZXIsIFVNQSAod2hp Y2ggbGV2ZXJhZ2VzIE9BdXRoKSBkb2VzIHN0cml2ZSB0byBzb2x2ZSBleGFjdGx5IHRoaXMgdXNl IA0KY2FzZSwgYW1vbmcgb3RoZXIgc2ltaWxhciBvbmVzOyB3ZSBjYWxsIHRoaXMgb25lICJwZXJz b24tdG8tcGVyc29uIA0Kc2hhcmluZyIsIGFuZCB5b3UgY2FuIHJlYWQgbW9yZSBhYm91dCBpdCBo ZXJlOiANCmh0dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLXRy dXN0Lmh0bWwjYW5jaG9yMQ0KDQpUaGUgVU1BIGZsb3cgYXQgcnVuIHRpbWUgc3RpbGwgZW5kcyB1 cCBiZWluZyBlZmZlY3RpdmVseSANCiJjbGllbnQtaW5pdGlhdGVkIiAod2Ugd291bGQgc2F5IHJl cXVlc3RpbmctcGFydHktaW5pdGlhdGVkLCB1c2luZyBhIA0KcmVxdWVzdGVyIGFwcCkgYmVjYXVz ZSB0aGUgb3JpZ2luYWwgcmVzb3VyY2Ugb3duZXIgKHdlIGNhbGwgaXQgYW4gDQphdXRob3Jpemlu ZyBwYXJ0eSkgaXMgbm8gbG9uZ2VyIGFyb3VuZCBieSB0aGVuLiBUaGUgYXV0aHogcGFydHkgd291 bGQgc2V0IA0KdXAgcG9saWNpZXMgYXQgc29tZSBwb2ludCBiZWZvcmUgZ29pbmcgb24gdmFjYXRp b24sIGFuZCB0aGVzZSBwb2xpY2VzIA0Kd291bGQgZW5hYmxlIHRoZSByZXF1ZXN0aW5nIHBhcnR5 IHRvICJxdWFsaWZ5IGluIiBmb3IgYWNjZXNzIGF0IHJ1biB0aW1lLCANCmJ5IHN1cHBseWluZyBp ZGVudGl0eSBjbGFpbXMgdGhhdCBnZXQgdXNlZCBpbiBhbiBhdXRob3JpemF0aW9uIGNoZWNrIGJ5 IA0KdGhlIGF1dGh6IHNlcnZlciAoYXV0aHogbWFuYWdlcikuDQoNCldlJ2xsIGJlIHdhbGtpbmcg dGhyb3VnaCBVTUEgZmxvd3MgYW5kIGRlbW9pbmcgYW4gZXh0ZW5zaXZlIHVzZSBjYXNlIGF0IGEg DQp3ZWJpbmFyIG9uIFdlZCwgT2N0IDE3LiBNb3JlIGluZm8gaXMgaGVyZTogaHR0cDovL3Rpbnl1 cmwuY29tL3VtYXdnDQoNCkhvcGUgdGhpcyBoZWxwcywNCg0KICAgICAgICBFdmUNCg0KT24gNiBP Y3QgMjAxMiwgYXQgMTA6MjkgQU0sIFByYWJhdGggU2lyaXdhcmRlbmEgPHByYWJhdGhAd3NvMi5j b20+IHdyb3RlOg0KDQo+IEhpIGZvbGtzLA0KPg0KPiBJIHdvdWxkIGxpa2UgdG8ga25vdyB5b3Vy IHRob3VnaHRzIG9uIHRoZSAkc3ViamVjdC4uDQo+DQo+IEZvciBtZSBpdCBsb29rcyBsaWtlIGEg Y29uY3JldGUgdXNlIGNhc2Ugd2hlcmUgT0F1dGggY29uY2VwdHVhbGx5IGRvZXMNCj4gYWRkcmVz cyAtIGJ1dCBwcm90b2NvbCBkb2VzIG5vdCB3ZWxsIGRlZmluZWQuLg0KPg0KPiBQbGVhc2UgZmlu ZCBbMV0gZm9yIGZ1cnRoZXIgZGV0YWlscy4uLg0KPg0KPiBbMV06IA0KaHR0cDovL2Jsb2cuZmFj aWxlbG9naW4uY29tLzIwMTIvMTAvYXRpb253aGF0LW9hdXRoLWxhY2tzLXJlc291cmNlLW93bmVy Lmh0bWwNCg0KPg0KPiAtLQ0KPiBUaGFua3MgJiBSZWdhcmRzLA0KPiBQcmFiYXRoDQo+DQo+IE1v YmlsZSA6ICs5NCA3MSA4MDkgNjczMg0KPg0KPiBodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20N Cj4gaHR0cDovL1JhbXBhcnRGQVEuY29tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KRXZl IE1hbGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cueG1sZ3Jy bC5jb20vYmxvZw0KKzEgNDI1IDM0NSA2NzU2ICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6 Ly93d3cudHdpdHRlci5jb20veG1sZ3JybA0KDQoNCg0KDQoNCi0tIA0KVGhhbmtzICYgUmVnYXJk cywNClByYWJhdGgNCg0KTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0KDQpodHRwOi8vYmxvZy5m YWNpbGVsb2dpbi5jb20NCmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbQ0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K DQo= --=_alternative 0007D03B48257A91_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPiZuYnNwO1ByYWJhPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgSSBhbSBhbHNvIHRoaW5raW5nIG9uIHRoaXMgc3ViamVjdCwNCmFuZCBw dWJsaXNoZWQgYSBkcmFmdCBvbiBpdC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC16aG91LW9hdXRoLW93bmVy LWF1dGgtMDAudHh0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgSSdkIGxpa2UgdG8gaGF2ZSB5b3VyIG9waW5pb24uPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlByYWJhdGggU2lyaXdhcmRlbmEgJmx0O3ByYWJh dGhAd3NvMi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj63orz+yMs6ICZuYnNwO29hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMC0wOCAwODowODwvZm9udD4NCjx0 ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5FdmUgTWFsZXIg Jmx0O2V2ZUB4bWxncnJsLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPm9hdXRoQGlldGYub3Jn PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW09BVVRILVdHXSBSZXNvdXJjZSBvd25lciBpbml0aWF0 ZWQNCk9BdXRoIGRlbGVnYXRpb248L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTM+SGkgRXZlLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+ VGhhbmtzIGZvciBwb2ludGVycy4uIEkndmUgYmVlbiBmb2xsb3dpbmcgdGhlIHdvcmsgZG9uZQ0K aW4gVU1BLi4gU3VyZS4uIHdpbGwgam9pbiB0aGUgd2ViaW5hci4uLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTM+QlRXIC4uIEkgYW0gbm90IHF1aXRlIHN1cmUgVU1BIGFkZHJlc3NlcyBt eSB1c2UgY2FzZS4NCkV2ZW4gaW4gdGhlIGNhc2Ugb2YgVU1BIGl0J3MgY2xpZW50IGluaXRpYXRl ZCBvciByZXF1ZXN0b3IgaW5pdGlhdGVkLi4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mz5QbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLi4uIGJ1dCBpbiBPQXV0aCBzcGVjaWZp Y2F0aW9uDQp0aGVyZSBpcyBubyByZXN0cmljdGlvbnMgdG8gaWRlbnRpZnkgdGhlICdjbGllbnQn IGFzIGEgcGVyc29uLCBvcmdhbml6YXRpb24NCm9yIGFzIGhpbSBzZWxmLi4mbmJzcDs8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkluIG15IHZpZXcgLSB0aGlzIGlzIGFuIGV4dGVuZGVk IGdyYW50IHR5cGUuLndoaWNoIGhhcw0KdHdvIHBoYXNlcy4uPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9Mz4xLiBSZXNvdXJjZSBvd25lciBncmFudHMgYWNjZXNzIHRvIGEgc2VsZWN0ZWQg YSBDbGllbnQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjIuIENsaWVudCByZXF1ZXN0cyB0aGUg YWxyZWFkeSBhdmFpbGFibGUgYWNjZXNzIHRva2VuDQpmb3IgaGltIGZyb20gdGhlIEF1dGhvcml6 YXRpb24gU2VydmVyLltqdXN0IGxpa2UgcGFzc2luZyB0aGUgcmVmcmVzaF90b2tlbl08L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPldEWVQgPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTM+VGhhbmtzICZhbXA7IHJlZ2FyZHMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4tUHJh YmF0aCZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+T24gU3VuLCBPY3QgNywg MjAxMiBhdCAxMTowNSBBTSwgRXZlIE1hbGVyICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZXZl QHhtbGdycmwuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+ZXZl QHhtbGdycmwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPiZndDsNCndyb3RlOjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTM+SGkgUHJhYmF0aCw8YnI+DQo8YnI+DQpBcyBmYXIgYXMgSSBr bm93LCBPQXV0aCBpdHNlbGYgZ2VuZXJhbGx5IGlzbid0IHVzZWQgdG8gbGV0IG9uZSBodW1hbiBy ZXNvdXJjZQ0Kb3duZXIgZGVsZWdhdGUgYWNjZXNzIHRvIGEgZGlmZmVyZW50IGh1bWFuIHJlc291 cmNlIG93bmVyLiBIb3dldmVyLCBVTUENCih3aGljaCBsZXZlcmFnZXMgT0F1dGgpIGRvZXMgc3Ry aXZlIHRvIHNvbHZlIGV4YWN0bHkgdGhpcyB1c2UgY2FzZSwgYW1vbmcNCm90aGVyIHNpbWlsYXIg b25lczsgd2UgY2FsbCB0aGlzIG9uZSAmcXVvdDtwZXJzb24tdG8tcGVyc29uIHNoYXJpbmcmcXVv dDssDQphbmQgeW91IGNhbiByZWFkIG1vcmUgYWJvdXQgaXQgaGVyZTogPC9mb250PjxhIGhyZWY9 Imh0dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLXRydXN0Lmh0 bWwjYW5jaG9yMSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5odHRw Oi8vZG9jcy5rYW50YXJhaW5pdGlhdGl2ZS5vcmcvdW1hL2RyYWZ0LXVtYS10cnVzdC5odG1sI2Fu Y2hvcjE8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KVGhlIFVNQSBmbG93 IGF0IHJ1biB0aW1lIHN0aWxsIGVuZHMgdXAgYmVpbmcgZWZmZWN0aXZlbHkgJnF1b3Q7Y2xpZW50 LWluaXRpYXRlZCZxdW90Ow0KKHdlIHdvdWxkIHNheSByZXF1ZXN0aW5nLXBhcnR5LWluaXRpYXRl ZCwgdXNpbmcgYSByZXF1ZXN0ZXIgYXBwKSBiZWNhdXNlDQp0aGUgb3JpZ2luYWwgcmVzb3VyY2Ug b3duZXIgKHdlIGNhbGwgaXQgYW4gYXV0aG9yaXppbmcgcGFydHkpIGlzIG5vIGxvbmdlcg0KYXJv dW5kIGJ5IHRoZW4uIFRoZSBhdXRoeiBwYXJ0eSB3b3VsZCBzZXQgdXAgcG9saWNpZXMgYXQgc29t ZSBwb2ludCBiZWZvcmUNCmdvaW5nIG9uIHZhY2F0aW9uLCBhbmQgdGhlc2UgcG9saWNlcyB3b3Vs ZCBlbmFibGUgdGhlIHJlcXVlc3RpbmcgcGFydHkNCnRvICZxdW90O3F1YWxpZnkgaW4mcXVvdDsg Zm9yIGFjY2VzcyBhdCBydW4gdGltZSwgYnkgc3VwcGx5aW5nIGlkZW50aXR5DQpjbGFpbXMgdGhh dCBnZXQgdXNlZCBpbiBhbiBhdXRob3JpemF0aW9uIGNoZWNrIGJ5IHRoZSBhdXRoeiBzZXJ2ZXIg KGF1dGh6DQptYW5hZ2VyKS48YnI+DQo8YnI+DQpXZSdsbCBiZSB3YWxraW5nIHRocm91Z2ggVU1B IGZsb3dzIGFuZCBkZW1vaW5nIGFuIGV4dGVuc2l2ZSB1c2UgY2FzZSBhdA0KYSB3ZWJpbmFyIG9u IFdlZCwgT2N0IDE3LiBNb3JlIGluZm8gaXMgaGVyZTogPC9mb250PjxhIGhyZWY9aHR0cDovL3Rp bnl1cmwuY29tL3VtYXdnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+ aHR0cDovL3Rpbnl1cmwuY29tL3VtYXdnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjxicj4N Cjxicj4NCkhvcGUgdGhpcyBoZWxwcyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgRXZlPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48YnI+DQpPbiA2IE9jdCAyMDEyLCBh dCAxMDoyOSBBTSwgUHJhYmF0aCBTaXJpd2FyZGVuYSAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRv OnByYWJhdGhAd3NvMi5jb20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+cHJhYmF0aEB3c28y LmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4mZ3Q7DQp3cm90ZTo8YnI+DQo8YnI+DQom Z3Q7IEhpIGZvbGtzLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgd291bGQgbGlrZSB0byBrbm93IHlv dXIgdGhvdWdodHMgb24gdGhlICRzdWJqZWN0Li48YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb3IgbWUg aXQgbG9va3MgbGlrZSBhIGNvbmNyZXRlIHVzZSBjYXNlIHdoZXJlIE9BdXRoIGNvbmNlcHR1YWxs eQ0KZG9lczxicj4NCiZndDsgYWRkcmVzcyAtIGJ1dCBwcm90b2NvbCBkb2VzIG5vdCB3ZWxsIGRl ZmluZWQuLjxicj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFzZSBmaW5kIFsxXSBmb3IgZnVydGhlciBk ZXRhaWxzLi4uPGJyPg0KJmd0Ozxicj4NCiZndDsgWzFdOiA8L2ZvbnQ+PGEgaHJlZj0iaHR0cDov L2Jsb2cuZmFjaWxlbG9naW4uY29tLzIwMTIvMTAvYXRpb253aGF0LW9hdXRoLWxhY2tzLXJlc291 cmNlLW93bmVyLmh0bWwiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+ aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tLzIwMTIvMTAvYXRpb253aGF0LW9hdXRoLWxhY2tz LXJlc291cmNlLW93bmVyLmh0bWw8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KJmd0 Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IFRoYW5rcyAmYW1wOyBSZWdhcmRzLDxicj4NCiZndDsg UHJhYmF0aDxicj4NCiZndDs8YnI+DQomZ3Q7IE1vYmlsZSA6IDwvZm9udD48YSBocmVmPXRlbDol MkI5NCUyMDcxJTIwODA5JTIwNjczMj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT4rOTQNCjcx IDgwOSA2NzMyPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjxicj4NCiZndDs8YnI+DQomZ3Q7 IDwvZm9udD48YSBocmVmPWh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbS8gdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5odHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KJmd0OyA8L2ZvbnQ+PGEgaHJlZj1odHRw Oi8vcmFtcGFydGZhcS5jb20vIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+ PHU+aHR0cDovL1JhbXBhcnRGQVEuY29tPC91PjwvZm9udD48L2E+DQo8YnI+PGZvbnQgc2l6ZT0z PiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPC9mb250PjxhIGhyZWY9bWFpbHRv Ok9BdXRoQGlldGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pk9BdXRoQGlldGYub3Jn PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjxicj4NCiZndDsgPC9mb250PjxhIGhyZWY9aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCB0YXJnZXQ9X2JsYW5rPjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KPGJyPg0K RXZlIE1hbGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy54bWxncnJsLmNvbS9ibG9n IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cDovL3d3dy54bWxn cnJsLmNvbS9ibG9nPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+PGJy Pg0KPC91PjwvZm9udD48YSBocmVmPXRlbDolMkIxJTIwNDI1JTIwMzQ1JTIwNjc1Nj48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZT48dT4rMQ0KNDI1IDM0NSA2NzU2PC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGEgaHJlZj1o dHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmwgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZT48dT5odHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmw8L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz48YnI+ DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPi0tIDxicj4NClRoYW5rcyAmYW1wOyBS ZWdhcmRzLDxicj4NClByYWJhdGg8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPk1vYmls ZSA6ICs5NCA3MSA4MDkgNjczMiZuYnNwOzxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4u Y29tLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHA6Ly9ibG9n LmZhY2lsZWxvZ2luLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1 Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vcmFtcGFydGZhcS5jb20vIHRhcmdldD1f Ymxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cDovL1JhbXBhcnRGQVEuY29tPC91 PjwvZm9udD48L2E+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCk9B dXRoQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0007D03B48257A91_=-- From prabath@wso2.com Sun Oct 7 18:50:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CD221F8712 for ; Sun, 7 Oct 2012 18:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1QYtVtSSEjH for ; Sun, 7 Oct 2012 18:50:35 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6524221F8650 for ; Sun, 7 Oct 2012 18:50:34 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so4190311vbb.31 for ; Sun, 07 Oct 2012 18:50:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ookQna9A7jfBLuQk5PYTH2ON0SOlgIRZBmRWqu/FOtA=; b=kObznEp1S7bSWAeu/TgDDnk6zS5svW7YhO7ozW1ZF+pmYYRUHf0ypId/NEON/vkL7F 4b4Q6RJ+SMz7n26YFr5C8+knotjCdGBcJswzsr6q3MUFL87AmPCCeW/8zVmlalZhKLkU c4nfyISptRBDRjSU2n2wW8DNZMx0XDj0ptpc62PyBKxuDwrSqLfenRJWAx62s/eQSa7+ MnG6C/rz/cKJbYUZsil+t39x9hzt/KTWvsdx+p5sknBKvfDonw84nooa3LTcYJ6GOplC dPpmVVXGbLV6JDo/kvW4gsN8MbcJBZZUTemN8zSpuH97PhYLoGFvQfiBQ8/3+fgRCzG6 uCUQ== MIME-Version: 1.0 Received: by 10.52.24.103 with SMTP id t7mr7350742vdf.84.1349661033606; Sun, 07 Oct 2012 18:50:33 -0700 (PDT) Received: by 10.59.0.129 with HTTP; Sun, 7 Oct 2012 18:50:33 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Oct 2012 18:50:33 -0700 Message-ID: From: Prabath Siriwardena To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=20cf3078133079afac04cb8272c3 X-Gm-Message-State: ALoCoQm6dJiG0WhveDacIvcrpT4VXOKjWtXvx+l5fYHTvzeXosPgFkKNkaKd0XEwhwCqmcZRoj7z Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 01:50:36 -0000 --20cf3078133079afac04cb8272c3 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Zhou, Nice to see some common interest on this. Sure I will go through your proposal. Please find my proposal here [1]. I've added there the complete token flow, introducing a new grant type. [1]: http://blog.facilelogin.com/2012/10/proposal-resource-owner-initiated.html Thanks & regards, -Prabath On Sun, Oct 7, 2012 at 6:24 PM, wrote: > > Hi, Praba > > I am also thinking on this subject, and published a draft on it. > http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt > I'd like to have your opinion. > > > > *Prabath Siriwardena * > =B7=A2=BC=FE=C8=CB: oauth-bounces@ietf.org > > 2012-10-08 08:08 > =CA=D5=BC=FE=C8=CB > Eve Maler > =B3=AD=CB=CD > oauth@ietf.org > =D6=F7=CC=E2 > Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > > > Hi Eve, > > Thanks for pointers.. I've been following the work done in UMA.. Sure.. > will join the webinar... > > BTW .. I am not quite sure UMA addresses my use case. Even in the case of > UMA it's client initiated or requestor initiated... > > Please correct me if I am wrong... but in OAuth specification there is no > restrictions to identify the 'client' as a person, organization or as him > self.. > > In my view - this is an extended grant type..which has two phases.. > > 1. Resource owner grants access to a selected a Client > 2. Client requests the already available access token for him from the > Authorization Server.[just like passing the refresh_token] > > WDYT ? > > Thanks & regards, > -Prabath > > On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <*eve@xmlgrrl.com*> > wrote: > Hi Prabath, > > As far as I know, OAuth itself generally isn't used to let one human > resource owner delegate access to a different human resource owner. > However, UMA (which leverages OAuth) does strive to solve exactly this us= e > case, among other similar ones; we call this one "person-to-person > sharing", and you can read more about it here: * > http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1* > > The UMA flow at run time still ends up being effectively > "client-initiated" (we would say requesting-party-initiated, using a > requester app) because the original resource owner (we call it an > authorizing party) is no longer around by then. The authz party would set > up policies at some point before going on vacation, and these polices wou= ld > enable the requesting party to "qualify in" for access at run time, by > supplying identity claims that get used in an authorization check by the > authz server (authz manager). > > We'll be walking through UMA flows and demoing an extensive use case at a > webinar on Wed, Oct 17. More info is here: *http://tinyurl.com/umawg* > > Hope this helps, > > Eve > > On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <*prabath@wso2.com*> > wrote: > > > Hi folks, > > > > I would like to know your thoughts on the $subject.. > > > > For me it looks like a concrete use case where OAuth conceptually does > > address - but protocol does not well defined.. > > > > Please find [1] for further details... > > > > [1]: * > http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.= html > * > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> > > > > *http://blog.facilelogin.com* > > *http://RampartFAQ.com* > > _______________________________________________ > > OAuth mailing list > > *OAuth@ietf.org* > > *https://www.ietf.org/mailman/listinfo/oauth* > > > Eve Maler *http://www.xmlgrrl.com/blog*<= http://www.xmlgrrl.com/blog> > * > **+1 425 345 6756* <%2B1%20425%20345%206756> * > http://www.twitter.com/xmlgrrl* > > > > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > * > **http://blog.facilelogin.com* * > **http://RampartFAQ.com* > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --20cf3078133079afac04cb8272c3 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Zhou,

Nice to see some common int= erest on this. Sure I will go through your proposal.

Please find my proposal her= e [1]. I've added there the complete token flow, introducing a new gran= t type.

[1]: http= ://blog.facilelogin.com/2012/10/proposal-resource-owner-initiated.html<= /div>

Thanks & regards,
=
-Prabath

On Sun, Oct 7, 2012 at 6:24 PM= , <zhou.sujing@zte.com.cn> wrote:

Hi,  Praba

  I am also thinking on this subject, and published a draft on it.
http://tools.ietf.org/id/draft= -zhou-oauth-owner-auth-00.txt
  I'd like to have your opinion.
 


Prabath Siriwarde= na <prabath@wso2.c= om>
=B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org=

2012-10-08 08:08

=CA=D5=BC=FE=C8= =CB
Eve Maler <eve@xmlgrrl.com>
=B3=AD=CB=CD
oauth@ietf.org
=D6=F7=CC=E2
Re: [OAUTH-WG] Resource owner= initiated OAuth delegation





Hi Eve,

Thanks for pointers.. I've been following the work= done in UMA.. Sure.. will join the webinar...

BTW .. I am not quite sure UMA addresses my use case. Even in the case of UMA it's client initiated or requestor initiated...=

Please correct me if I am wrong... but in OAuth specif= ication there is no restrictions to identify the 'client' as a person, orga= nization or as him self.. 

In my view - this is an extended grant type..which has two phases..

1. Resource owner grants access to a selected a Client=
2. Client requests the already available access token for him from the Authorization Server.[just like passing the refresh_token]=

WDYT ?

Thanks & regards,
-Prabath 

On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <= eve@xmlgrrl.com> wrote:
Hi Prabath,

As far as I know, OAuth itself generally isn't used to let one human re= source owner delegate access to a different human resource owner. However, UMA (which leverages OAuth) does strive to solve exactly this use case, among other similar ones; we call this one "person-to-person sharing", and you can read more about it here: http://docs.kantarainitiative.org/uma/draft-uma-t= rust.html#anchor1

The UMA flow at run time still ends up being effectively "client-initi= ated" (we would say requesting-party-initiated, using a requester app) because the original resource owner (we call it an authorizing party) is no longer around by then. The authz party would set up policies at some point before going on vacation, and these polices would enable the requesting party to "qualify in" for access at run time, by supplying identity claims that get used in an authorization check by the authz server (authz manager).

We'll be walking through UMA flows and demoing an extensive use case at a webinar on Wed, Oct 17. More info is here: http://t= inyurl.com/umawg

Hope this helps,

        Eve

On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <pr= abath@wso2.com> wrote:

> Hi folks,
>
> I would like to know your thoughts on the $subject..
>
> For me it looks like a concrete use case where OAuth conceptually does
> address - but protocol does not well defined..
>
> Please find [1] for further details...
>
> [1]: http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resourc= e-owner.html
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
> _______________________________________________ > OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman= /listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756        &nb= sp;                http://www.twitter.com/xmlgrrl



--
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732 

http://blog.facilelogin.com
http://RampartFAQ.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth



--
= Thanks & Regards,
Prabath


--20cf3078133079afac04cb8272c3-- From zhou.sujing@zte.com.cn Sun Oct 7 20:03:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3161E21F8453; Sun, 7 Oct 2012 20:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.501 X-Spam-Level: X-Spam-Status: No, score=-97.501 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar0-MPBWwqj0; Sun, 7 Oct 2012 20:03:24 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6830621F874A; Sun, 7 Oct 2012 20:03:23 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id B45761934780; Mon, 8 Oct 2012 11:03:19 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id BF420714566; Mon, 8 Oct 2012 11:00:03 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q98338jF061240; Mon, 8 Oct 2012 11:03:08 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Prabath Siriwardena MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 8 Oct 2012 11:03:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-08 11:03:09, Serialize complete at 2012-10-08 11:03:09 Content-Type: multipart/alternative; boundary="=_alternative 0010CF1648257A91_=" X-MAIL: mse02.zte.com.cn q98338jF061240 Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 03:03:25 -0000 This is a multipart message in MIME format. --=_alternative 0010CF1648257A91_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksUHJhYmF0aA0KDQogSSBoYXZlIHJlYWQgeW91ciBwcm9wb3NhbCwgYW5kIGhhdmUgc29tZSBx dWVzdGlvbnM6DQoNCiAgd2h5IFJTIG5lZWRzIHRvIGdldCBhY2Nlc3MgdG9rZW4gaW4gY2xpZW50 IHJlZ2lzdGVyIHN0YWdlOw0KICBhbmQgd2h5IFJTIG5lZWRzIHRvIGdldCBjbGllbnQtaWQgZnJv bSBBUyBieSBleGNoYW5naW5nIGFjY2VzcyB0b2tlbiANCihpc24ndCBjbGllbnQtaWQgcHVibGlj PykNCiANCg0KDQoNClByYWJhdGggU2lyaXdhcmRlbmEgPHByYWJhdGhAd3NvMi5jb20+IA0KMjAx Mi0xMC0wOCAwOTo1MA0KDQrK1bz+yMsNCnpob3Uuc3VqaW5nQHp0ZS5jb20uY24NCrOty80NCkV2 ZSBNYWxlciA8ZXZlQHhtbGdycmwuY29tPiwgb2F1dGhAaWV0Zi5vcmcsIG9hdXRoLWJvdW5jZXNA aWV0Zi5vcmcNCtb3zOINClJlOiBSZTogW09BVVRILVdHXSBSZXNvdXJjZSBvd25lciBpbml0aWF0 ZWQgT0F1dGggZGVsZWdhdGlvbg0KDQoNCg0KDQoNCg0KSGkgWmhvdSwNCg0KTmljZSB0byBzZWUg c29tZSBjb21tb24gaW50ZXJlc3Qgb24gdGhpcy4gU3VyZSBJIHdpbGwgZ28gdGhyb3VnaCB5b3Vy IA0KcHJvcG9zYWwuDQoNClBsZWFzZSBmaW5kIG15IHByb3Bvc2FsIGhlcmUgWzFdLiBJJ3ZlIGFk ZGVkIHRoZXJlIHRoZSBjb21wbGV0ZSB0b2tlbiANCmZsb3csIGludHJvZHVjaW5nIGEgbmV3IGdy YW50IHR5cGUuDQoNClsxXTogDQpodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20vMjAxMi8xMC9w cm9wb3NhbC1yZXNvdXJjZS1vd25lci1pbml0aWF0ZWQuaHRtbA0KDQpUaGFua3MgJiByZWdhcmRz LA0KLVByYWJhdGgNCg0KT24gU3VuLCBPY3QgNywgMjAxMiBhdCA2OjI0IFBNLCA8emhvdS5zdWpp bmdAenRlLmNvbS5jbj4gd3JvdGU6DQoNCkhpLCAgUHJhYmEgDQoNCiAgSSBhbSBhbHNvIHRoaW5r aW5nIG9uIHRoaXMgc3ViamVjdCwgYW5kIHB1Ymxpc2hlZCBhIGRyYWZ0IG9uIGl0LiANCmh0dHA6 Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC16aG91LW9hdXRoLW93bmVyLWF1dGgtMDAudHh0IA0K ICBJJ2QgbGlrZSB0byBoYXZlIHlvdXIgb3Bpbmlvbi4gDQogDQoNCg0KDQpQcmFiYXRoIFNpcml3 YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPiANCreivP7IyzogIG9hdXRoLWJvdW5jZXNAaWV0Zi5v cmcgDQoyMDEyLTEwLTA4IDA4OjA4IA0KDQoNCsrVvP7Iyw0KRXZlIE1hbGVyIDxldmVAeG1sZ3Jy bC5jb20+IA0Ks63LzQ0Kb2F1dGhAaWV0Zi5vcmcgDQrW98ziDQpSZTogW09BVVRILVdHXSBSZXNv dXJjZSBvd25lciBpbml0aWF0ZWQgT0F1dGggZGVsZWdhdGlvbg0KDQoNCg0KDQoNCg0KDQoNCkhp IEV2ZSwgDQoNClRoYW5rcyBmb3IgcG9pbnRlcnMuLiBJJ3ZlIGJlZW4gZm9sbG93aW5nIHRoZSB3 b3JrIGRvbmUgaW4gVU1BLi4gU3VyZS4uIA0Kd2lsbCBqb2luIHRoZSB3ZWJpbmFyLi4uIA0KDQpC VFcgLi4gSSBhbSBub3QgcXVpdGUgc3VyZSBVTUEgYWRkcmVzc2VzIG15IHVzZSBjYXNlLiBFdmVu IGluIHRoZSBjYXNlIG9mIA0KVU1BIGl0J3MgY2xpZW50IGluaXRpYXRlZCBvciByZXF1ZXN0b3Ig aW5pdGlhdGVkLi4uIA0KDQpQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLi4uIGJ1dCBp biBPQXV0aCBzcGVjaWZpY2F0aW9uIHRoZXJlIGlzIG5vIA0KcmVzdHJpY3Rpb25zIHRvIGlkZW50 aWZ5IHRoZSAnY2xpZW50JyBhcyBhIHBlcnNvbiwgb3JnYW5pemF0aW9uIG9yIGFzIGhpbSANCnNl bGYuLiANCg0KSW4gbXkgdmlldyAtIHRoaXMgaXMgYW4gZXh0ZW5kZWQgZ3JhbnQgdHlwZS4ud2hp Y2ggaGFzIHR3byBwaGFzZXMuLiANCg0KMS4gUmVzb3VyY2Ugb3duZXIgZ3JhbnRzIGFjY2VzcyB0 byBhIHNlbGVjdGVkIGEgQ2xpZW50IA0KMi4gQ2xpZW50IHJlcXVlc3RzIHRoZSBhbHJlYWR5IGF2 YWlsYWJsZSBhY2Nlc3MgdG9rZW4gZm9yIGhpbSBmcm9tIHRoZSANCkF1dGhvcml6YXRpb24gU2Vy dmVyLltqdXN0IGxpa2UgcGFzc2luZyB0aGUgcmVmcmVzaF90b2tlbl0gDQoNCldEWVQgPyANCg0K VGhhbmtzICYgcmVnYXJkcywgDQotUHJhYmF0aCANCg0KT24gU3VuLCBPY3QgNywgMjAxMiBhdCAx MTowNSBBTSwgRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb20+IHdyb3RlOiANCkhpIFByYWJhdGgs DQoNCkFzIGZhciBhcyBJIGtub3csIE9BdXRoIGl0c2VsZiBnZW5lcmFsbHkgaXNuJ3QgdXNlZCB0 byBsZXQgb25lIGh1bWFuIA0KcmVzb3VyY2Ugb3duZXIgZGVsZWdhdGUgYWNjZXNzIHRvIGEgZGlm ZmVyZW50IGh1bWFuIHJlc291cmNlIG93bmVyLiANCkhvd2V2ZXIsIFVNQSAod2hpY2ggbGV2ZXJh Z2VzIE9BdXRoKSBkb2VzIHN0cml2ZSB0byBzb2x2ZSBleGFjdGx5IHRoaXMgdXNlIA0KY2FzZSwg YW1vbmcgb3RoZXIgc2ltaWxhciBvbmVzOyB3ZSBjYWxsIHRoaXMgb25lICJwZXJzb24tdG8tcGVy c29uIA0Kc2hhcmluZyIsIGFuZCB5b3UgY2FuIHJlYWQgbW9yZSBhYm91dCBpdCBoZXJlOiANCmh0 dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLXRydXN0Lmh0bWwj YW5jaG9yMQ0KDQpUaGUgVU1BIGZsb3cgYXQgcnVuIHRpbWUgc3RpbGwgZW5kcyB1cCBiZWluZyBl ZmZlY3RpdmVseSANCiJjbGllbnQtaW5pdGlhdGVkIiAod2Ugd291bGQgc2F5IHJlcXVlc3Rpbmct cGFydHktaW5pdGlhdGVkLCB1c2luZyBhIA0KcmVxdWVzdGVyIGFwcCkgYmVjYXVzZSB0aGUgb3Jp Z2luYWwgcmVzb3VyY2Ugb3duZXIgKHdlIGNhbGwgaXQgYW4gDQphdXRob3JpemluZyBwYXJ0eSkg aXMgbm8gbG9uZ2VyIGFyb3VuZCBieSB0aGVuLiBUaGUgYXV0aHogcGFydHkgd291bGQgc2V0IA0K dXAgcG9saWNpZXMgYXQgc29tZSBwb2ludCBiZWZvcmUgZ29pbmcgb24gdmFjYXRpb24sIGFuZCB0 aGVzZSBwb2xpY2VzIA0Kd291bGQgZW5hYmxlIHRoZSByZXF1ZXN0aW5nIHBhcnR5IHRvICJxdWFs aWZ5IGluIiBmb3IgYWNjZXNzIGF0IHJ1biB0aW1lLCANCmJ5IHN1cHBseWluZyBpZGVudGl0eSBj bGFpbXMgdGhhdCBnZXQgdXNlZCBpbiBhbiBhdXRob3JpemF0aW9uIGNoZWNrIGJ5IA0KdGhlIGF1 dGh6IHNlcnZlciAoYXV0aHogbWFuYWdlcikuDQoNCldlJ2xsIGJlIHdhbGtpbmcgdGhyb3VnaCBV TUEgZmxvd3MgYW5kIGRlbW9pbmcgYW4gZXh0ZW5zaXZlIHVzZSBjYXNlIGF0IGEgDQp3ZWJpbmFy IG9uIFdlZCwgT2N0IDE3LiBNb3JlIGluZm8gaXMgaGVyZTogaHR0cDovL3Rpbnl1cmwuY29tL3Vt YXdnDQoNCkhvcGUgdGhpcyBoZWxwcywNCg0KICAgICAgICBFdmUgDQoNCk9uIDYgT2N0IDIwMTIs IGF0IDEwOjI5IEFNLCBQcmFiYXRoIFNpcml3YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPiB3cm90 ZToNCg0KPiBIaSBmb2xrcywNCj4NCj4gSSB3b3VsZCBsaWtlIHRvIGtub3cgeW91ciB0aG91Z2h0 cyBvbiB0aGUgJHN1YmplY3QuLg0KPg0KPiBGb3IgbWUgaXQgbG9va3MgbGlrZSBhIGNvbmNyZXRl IHVzZSBjYXNlIHdoZXJlIE9BdXRoIGNvbmNlcHR1YWxseSBkb2VzDQo+IGFkZHJlc3MgLSBidXQg cHJvdG9jb2wgZG9lcyBub3Qgd2VsbCBkZWZpbmVkLi4NCj4NCj4gUGxlYXNlIGZpbmQgWzFdIGZv ciBmdXJ0aGVyIGRldGFpbHMuLi4NCj4NCj4gWzFdOiANCmh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2lu LmNvbS8yMDEyLzEwL2F0aW9ud2hhdC1vYXV0aC1sYWNrcy1yZXNvdXJjZS1vd25lci5odG1sDQoN Cj4NCj4gLS0NCj4gVGhhbmtzICYgUmVnYXJkcywNCj4gUHJhYmF0aA0KPg0KPiBNb2JpbGUgOiAr OTQgNzEgODA5IDY3MzINCj4NCj4gaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tDQo+IGh0dHA6 Ly9SYW1wYXJ0RkFRLmNvbSANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpFdmUgTWFsZXIg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy54bWxncnJsLmNvbS9i bG9nDQorMSA0MjUgMzQ1IDY3NTYgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy50 d2l0dGVyLmNvbS94bWxncnJsDQoNCg0KDQoNCg0KLS0gDQpUaGFua3MgJiBSZWdhcmRzLA0KUHJh YmF0aCANCg0KTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0KDQpodHRwOi8vYmxvZy5mYWNpbGVs b2dpbi5jb20NCmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbSANCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoN Ci0tIA0KVGhhbmtzICYgUmVnYXJkcywNClByYWJhdGgNCg0KTW9iaWxlIDogKzk0IDcxIDgwOSA2 NzMyIA0KDQpodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCmh0dHA6Ly9SYW1wYXJ0RkFRLmNv bQ0KDQoNCg== --=_alternative 0010CF1648257A91_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+UHJhYmF0aDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7SSBoYXZlIHJlYWQgeW91ciBwcm9w b3NhbCwgYW5kDQpoYXZlIHNvbWUgcXVlc3Rpb25zOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IHdoeSBSUyBuZWVkcyB0byBnZXQgYWNjZXNz IHRva2VuDQppbiBjbGllbnQgcmVnaXN0ZXIgc3RhZ2U7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgYW5kIHdoeSBSUyBuZWVkcyB0byBnZXQgY2xpZW50 LWlkDQpmcm9tIEFTIGJ5IGV4Y2hhbmdpbmcgYWNjZXNzIHRva2VuIChpc24ndCBjbGllbnQtaWQg cHVibGljPyk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ UHJhYmF0aCBTaXJpd2FyZGVuYSAmbHQ7cHJhYmF0aEB3c28yLmNvbSZndDs8L2I+DQo8L2ZvbnQ+ DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMC0wOCAwOTo1MDwvZm9u dD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8 /sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj56aG91 LnN1amluZ0B6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5FdmUgTWFsZXIgJmx0O2V2ZUB4 bWxncnJsLmNvbSZndDssIG9hdXRoQGlldGYub3JnLA0Kb2F1dGgtYm91bmNlc0BpZXRmLm9yZzwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFJlOiBbT0FVVEgtV0ddIFJlc291cmNlIG93bmVyIGluaXRp YXRlZA0KT0F1dGggZGVsZWdhdGlvbjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFsIj5IaSBaaG91LDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+ TmljZSB0byBzZWUgc29tZSBjb21tb24gaW50ZXJlc3QNCm9uIHRoaXMuIFN1cmUgSSB3aWxsIGdv IHRocm91Z2ggeW91ciBwcm9wb3NhbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPlBsZWFzZSBmaW5kIG15IHByb3Bvc2FsIGhlcmUNClsx XS4gSSd2ZSBhZGRlZCB0aGVyZSB0aGUgY29tcGxldGUgdG9rZW4gZmxvdywgaW50cm9kdWNpbmcg YSBuZXcgZ3JhbnQNCnR5cGUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MjIyMjIyIGZhY2U9IkFyaWFsIj5bMV06IDwvZm9udD48YSBocmVmPSJodHRwOi8vYmxvZy5mYWNp bGVsb2dpbi5jb20vMjAxMi8xMC9wcm9wb3NhbC1yZXNvdXJjZS1vd25lci1pbml0aWF0ZWQuaHRt bCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9IzExNTVjYyBmYWNlPSJBcmlhbCI+ PHU+aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tLzIwMTIvMTAvcHJvcG9zYWwtcmVzb3VyY2Ut b3duZXItaW5pdGlhdGVkLmh0bWw8L3U+PC9mb250PjwvYT4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+VGhhbmtzICZhbXA7IHJlZ2FyZHMsPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFsIj4tUHJhYmF0aDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+T24gU3VuLCBP Y3QgNywgMjAxMiBhdCA2OjI0IFBNLCAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnpob3Uuc3Vq aW5nQHp0ZS5jb20uY24gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48dT56aG91LnN1amluZ0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDsNCndyb3RlOjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSGksICZuYnNwO1ByYWJhIDxicj4NCjxi cj4NCiAmbmJzcDtJIGFtIGFsc28gdGhpbmtpbmcgb24gdGhpcyBzdWJqZWN0LCBhbmQgcHVibGlz aGVkIGEgZHJhZnQgb24gaXQuDQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtemhvdS1vYXV0aC1vd25lci1hdXRoLTAwLnR4dCIgdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaWQvZHJhZnQtemhvdS1vYXV0aC1vd25lci1hdXRoLTAwLnR4dDwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCiAmbmJzcDtJJ2Qg bGlrZSB0byBoYXZlIHlvdXIgb3Bpbmlvbi4gPGJyPg0KICZuYnNwOzxicj4NCjxicj4NCjwvZm9u dD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD00 MiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlByYWJhdGggU2lyaXdhcmRlbmEg Jmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cHJhYmF0aEB3c28yLmNvbSB0YXJnZXQ9X2Js YW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PnByYWJh dGhAd3NvMi5jb208L3U+PC9iPjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPiZndDs8L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNwOzwvZm9udD48YSBocmVmPSJtYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29s b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMTAtMDggMDg6MDg8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTU3JT4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9OSU+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+ PC9kaXY+DQo8dGQgd2lkdGg9OTAlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5FdmUg TWFsZXIgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpldmVAeG1sZ3JybC5jb20gdGFyZ2V0PV9i bGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5ldmVAeG1s Z3JybC5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0 OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGEgaHJlZj1tYWlsdG86b2F1dGhAaWV0Zi5v cmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48dT5vYXV0aEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtPQVVUSC1XR10gUmVzb3VyY2Ugb3du ZXIgaW5pdGlhdGVkDQpPQXV0aCBkZWxlZ2F0aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0 ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQpIaSBFdmUsIDxicj4NCjxicj4NClRoYW5r cyBmb3IgcG9pbnRlcnMuLiBJJ3ZlIGJlZW4gZm9sbG93aW5nIHRoZSB3b3JrIGRvbmUgaW4gVU1B Li4gU3VyZS4uDQp3aWxsIGpvaW4gdGhlIHdlYmluYXIuLi4gPGJyPg0KPGJyPg0KQlRXIC4uIEkg YW0gbm90IHF1aXRlIHN1cmUgVU1BIGFkZHJlc3NlcyBteSB1c2UgY2FzZS4gRXZlbiBpbiB0aGUg Y2FzZQ0Kb2YgVU1BIGl0J3MgY2xpZW50IGluaXRpYXRlZCBvciByZXF1ZXN0b3IgaW5pdGlhdGVk Li4uIDxicj4NCjxicj4NClBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgYW0gd3JvbmcuLi4gYnV0IGlu IE9BdXRoIHNwZWNpZmljYXRpb24gdGhlcmUgaXMNCm5vIHJlc3RyaWN0aW9ucyB0byBpZGVudGlm eSB0aGUgJ2NsaWVudCcgYXMgYSBwZXJzb24sIG9yZ2FuaXphdGlvbiBvciBhcw0KaGltIHNlbGYu LiAmbmJzcDs8YnI+DQo8YnI+DQpJbiBteSB2aWV3IC0gdGhpcyBpcyBhbiBleHRlbmRlZCBncmFu dCB0eXBlLi53aGljaCBoYXMgdHdvIHBoYXNlcy4uIDxicj4NCjxicj4NCjEuIFJlc291cmNlIG93 bmVyIGdyYW50cyBhY2Nlc3MgdG8gYSBzZWxlY3RlZCBhIENsaWVudCA8YnI+DQoyLiBDbGllbnQg cmVxdWVzdHMgdGhlIGFscmVhZHkgYXZhaWxhYmxlIGFjY2VzcyB0b2tlbiBmb3IgaGltIGZyb20g dGhlDQpBdXRob3JpemF0aW9uIFNlcnZlci5banVzdCBsaWtlIHBhc3NpbmcgdGhlIHJlZnJlc2hf dG9rZW5dIDxicj4NCjxicj4NCldEWVQgPyA8YnI+DQo8YnI+DQpUaGFua3MgJmFtcDsgcmVnYXJk cywgPGJyPg0KLVByYWJhdGggJm5ic3A7PGJyPg0KPGJyPg0KT24gU3VuLCBPY3QgNywgMjAxMiBh dCAxMTowNSBBTSwgRXZlIE1hbGVyICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZXZlQHhtbGdy cmwuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z ZXJpZiI+PHU+ZXZlQHhtbGdycmwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsNCndyb3RlOiA8YnI+DQpIaSBQcmFiYXRoLDxicj4NCjxicj4NCkFz IGZhciBhcyBJIGtub3csIE9BdXRoIGl0c2VsZiBnZW5lcmFsbHkgaXNuJ3QgdXNlZCB0byBsZXQg b25lIGh1bWFuIHJlc291cmNlDQpvd25lciBkZWxlZ2F0ZSBhY2Nlc3MgdG8gYSBkaWZmZXJlbnQg aHVtYW4gcmVzb3VyY2Ugb3duZXIuIEhvd2V2ZXIsIFVNQQ0KKHdoaWNoIGxldmVyYWdlcyBPQXV0 aCkgZG9lcyBzdHJpdmUgdG8gc29sdmUgZXhhY3RseSB0aGlzIHVzZSBjYXNlLCBhbW9uZw0Kb3Ro ZXIgc2ltaWxhciBvbmVzOyB3ZSBjYWxsIHRoaXMgb25lICZxdW90O3BlcnNvbi10by1wZXJzb24g c2hhcmluZyZxdW90OywNCmFuZCB5b3UgY2FuIHJlYWQgbW9yZSBhYm91dCBpdCBoZXJlOiA8L2Zv bnQ+PGEgaHJlZj0iaHR0cDovL2RvY3Mua2FudGFyYWluaXRpYXRpdmUub3JnL3VtYS9kcmFmdC11 bWEtdHJ1c3QuaHRtbCNhbmNob3IxIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9y Zy91bWEvZHJhZnQtdW1hLXRydXN0Lmh0bWwjYW5jaG9yMTwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQpUaGUgVU1BIGZsb3cgYXQgcnVuIHRp bWUgc3RpbGwgZW5kcyB1cCBiZWluZyBlZmZlY3RpdmVseSAmcXVvdDtjbGllbnQtaW5pdGlhdGVk JnF1b3Q7DQood2Ugd291bGQgc2F5IHJlcXVlc3RpbmctcGFydHktaW5pdGlhdGVkLCB1c2luZyBh IHJlcXVlc3RlciBhcHApIGJlY2F1c2UNCnRoZSBvcmlnaW5hbCByZXNvdXJjZSBvd25lciAod2Ug Y2FsbCBpdCBhbiBhdXRob3JpemluZyBwYXJ0eSkgaXMgbm8gbG9uZ2VyDQphcm91bmQgYnkgdGhl bi4gVGhlIGF1dGh6IHBhcnR5IHdvdWxkIHNldCB1cCBwb2xpY2llcyBhdCBzb21lIHBvaW50IGJl Zm9yZQ0KZ29pbmcgb24gdmFjYXRpb24sIGFuZCB0aGVzZSBwb2xpY2VzIHdvdWxkIGVuYWJsZSB0 aGUgcmVxdWVzdGluZyBwYXJ0eQ0KdG8gJnF1b3Q7cXVhbGlmeSBpbiZxdW90OyBmb3IgYWNjZXNz IGF0IHJ1biB0aW1lLCBieSBzdXBwbHlpbmcgaWRlbnRpdHkNCmNsYWltcyB0aGF0IGdldCB1c2Vk IGluIGFuIGF1dGhvcml6YXRpb24gY2hlY2sgYnkgdGhlIGF1dGh6IHNlcnZlciAoYXV0aHoNCm1h bmFnZXIpLjxicj4NCjxicj4NCldlJ2xsIGJlIHdhbGtpbmcgdGhyb3VnaCBVTUEgZmxvd3MgYW5k IGRlbW9pbmcgYW4gZXh0ZW5zaXZlIHVzZSBjYXNlIGF0DQphIHdlYmluYXIgb24gV2VkLCBPY3Qg MTcuIE1vcmUgaW5mbyBpcyBoZXJlOiA8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vdGlueXVybC5jb20v dW1hd2cgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48dT5odHRwOi8vdGlueXVybC5jb20vdW1hd2c8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KSG9wZSB0aGlzIGhlbHBzLDxicj4NCjxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtFdmUgPGJyPg0KPGJyPg0KT24gNiBPY3Qg MjAxMiwgYXQgMTA6MjkgQU0sIFByYWJhdGggU2lyaXdhcmRlbmEgJmx0OzwvZm9udD48YSBocmVm PW1haWx0bzpwcmFiYXRoQHdzbzIuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+cHJhYmF0aEB3c28yLmNvbTwvdT48L2ZvbnQ+PC9h Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTo8YnI+DQo8YnI+DQom Z3Q7IEhpIGZvbGtzLDxicj4NCiZndDs8YnI+DQomZ3Q7IEkgd291bGQgbGlrZSB0byBrbm93IHlv dXIgdGhvdWdodHMgb24gdGhlICRzdWJqZWN0Li48YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb3IgbWUg aXQgbG9va3MgbGlrZSBhIGNvbmNyZXRlIHVzZSBjYXNlIHdoZXJlIE9BdXRoIGNvbmNlcHR1YWxs eQ0KZG9lczxicj4NCiZndDsgYWRkcmVzcyAtIGJ1dCBwcm90b2NvbCBkb2VzIG5vdCB3ZWxsIGRl ZmluZWQuLjxicj4NCiZndDs8YnI+DQomZ3Q7IFBsZWFzZSBmaW5kIFsxXSBmb3IgZnVydGhlciBk ZXRhaWxzLi4uPGJyPg0KJmd0Ozxicj4NCiZndDsgWzFdOiA8L2ZvbnQ+PGEgaHJlZj0iaHR0cDov L2Jsb2cuZmFjaWxlbG9naW4uY29tLzIwMTIvMTAvYXRpb253aGF0LW9hdXRoLWxhY2tzLXJlc291 cmNlLW93bmVyLmh0bWwiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tLzIwMTIvMTAvYXRp b253aGF0LW9hdXRoLWxhY2tzLXJlc291cmNlLW93bmVyLmh0bWw8L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQom Z3Q7IFRoYW5rcyAmYW1wOyBSZWdhcmRzLDxicj4NCiZndDsgUHJhYmF0aDxicj4NCiZndDs8YnI+ DQomZ3Q7IE1vYmlsZSA6IDwvZm9udD48YSBocmVmPXRlbDolMkI5NCUyMDcxJTIwODA5JTIwNjcz MiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pjx1Pis5NA0KNzEgODA5IDY3MzI8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+PGJyPg0KJmd0Ozxicj4NCiZndDsgPC9mb250PjxhIGhyZWY9aHR0cDovL2Jsb2cu ZmFjaWxlbG9naW4uY29tLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbTwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQomZ3Q7IDwvZm9udD48YSBo cmVmPWh0dHA6Ly9yYW1wYXJ0ZmFxLmNvbS8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vUmFtcGFydEZBUS5jb208L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQomZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDwvZm9udD48YSBocmVmPW1haWx0bzpPQXV0aEBpZXRm Lm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1Pk9BdXRoQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPjxicj4NCiZndDsgPC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aCB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPGJyPg0KPGJyPg0KRXZlIE1hbGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250PjxhIGhyZWY9aHR0cDovL3d3 dy54bWxncnJsLmNvbS9ibG9nIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUg ZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL3d3dy54bWxncnJsLmNvbS9ibG9nPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0K PC91PjwvZm9udD48YSBocmVmPXRlbDolMkIxJTIwNDI1JTIwMzQ1JTIwNjc1NiB0YXJnZXQ9X2Js YW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PisxDQo0MjUg MzQ1IDY3NTY8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3LnR3aXR0 ZXIuY29tL3htbGdycmwgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48dT5odHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmw8L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0KVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KUHJhYmF0 aCA8YnI+DQo8YnI+DQpNb2JpbGUgOiA8L2ZvbnQ+PGEgaHJlZj10ZWw6JTJCOTQlMjA3MSUyMDgw OSUyMDY3MzIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48dT4rOTQNCjcxIDgwOSA2NzMyPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fu cy1zZXJpZiI+PHU+PGJyPg0KPGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHA6Ly9ibG9nLmZh Y2lsZWxvZ2luLmNvbS8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48dT5odHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+ PC9mb250PjxhIGhyZWY9aHR0cDovL3JhbXBhcnRmYXEuY29tLyB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9SYW1wYXJ0RkFR LmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD48dHQ+PGZvbnQgc2l6ZT0zPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PC9mb250PjwvdHQ+PHR0Pjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PC90dD48YSBocmVmPW1h aWx0bzpPQXV0aEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjx0dD48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZT48dT5PQXV0aEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9 MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGggdGFyZ2V0PV9ibGFuaz48dHQ+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvdT48L2ZvbnQ+PC90dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4tLSA8YnI+ DQpUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+DQpQcmFiYXRoPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5Nb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgPGJy Pg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxi cj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20vIHRhcmdl dD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0 cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHA6 Ly9yYW1wYXJ0ZmFxLmNvbS8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBm YWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vUmFtcGFydEZBUS5jb208L3U+PC9mb250PjwvYT4N Cjxicj4NCjxicj4NCg== --=_alternative 0010CF1648257A91_=-- From prabath@wso2.com Sun Oct 7 21:00:40 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC9221F874C for ; Sun, 7 Oct 2012 21:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.133 X-Spam-Level: X-Spam-Status: No, score=-0.133 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLt3nd40NkhU for ; Sun, 7 Oct 2012 21:00:38 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A078221F8735 for ; Sun, 7 Oct 2012 21:00:38 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so4388193vcb.31 for ; Sun, 07 Oct 2012 21:00:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bgLvKujJzhn4RcjusGCytgjAvkH03NppRhS/WOSwxL8=; b=KlkOXUY3r+HSNzGUhZXJEW9w8hnYBoW6fM/qKJP3yS6H4qcexfK3s1DEg3wZk1Egoc gBZVzRtrgsnON1vdzgjesoim/n5bysPEEHA684WI0ymtw3KYSTQYD2sAUAqAQoLMoByF IMdygOa4t03x8s7MwXjG3m+hiJLpJwwoLMwQpKvelJeH8Aw97Qxs1G6tH5yklGYFlEZ2 kiUY4BAm0kRs+SuejiM8DMb9Fl6RcSnN60eJ5D6Sz4IAwlBk6OtAy0GhyT5+ODEePHqX MNweSc1INJUZez9aMDHuChiW9LjIOgYOY+twc4GaNX4ht+hLVHy4pbgjOOgu4GK+8DBd d1Sw== MIME-Version: 1.0 Received: by 10.52.37.103 with SMTP id x7mr5514490vdj.61.1349668837860; Sun, 07 Oct 2012 21:00:37 -0700 (PDT) Received: by 10.59.0.129 with HTTP; Sun, 7 Oct 2012 21:00:37 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Oct 2012 21:00:37 -0700 Message-ID: From: Prabath Siriwardena To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=20cf307811d0a525c004cb844335 X-Gm-Message-State: ALoCoQkjBPTwb8MiOU6ytBV0HORpPC50MzuvMEWkmpetgGrcmBuYmzH+EBSvTyHTtoOQjby6FaeY Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 04:00:40 -0000 --20cf307811d0a525c004cb844335 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Zhou, Even though client_id is public that needs to be passed from the Authorization Server to the Resource Server. This does not happen in the normal OAuth flow. It only returns back the access_token. Please let me know if you need any further clarifications... Thanks & regards, -Prabath On Sun, Oct 7, 2012 at 8:03 PM, wrote: > > Hi,Prabath > > I have read your proposal, and have some questions: > > why RS needs to get access token in client register stage; > and why RS needs to get client-id from AS by exchanging access token > (isn't client-id public?) > > > > *Prabath Siriwardena * > > 2012-10-08 09:50 > =CA=D5=BC=FE=C8=CB > zhou.sujing@zte.com.cn > =B3=AD=CB=CD > Eve Maler , oauth@ietf.org, oauth-bounces@ietf.org > =D6=F7=CC=E2 > Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > > > Hi Zhou, > > Nice to see some common interest on this. Sure I will go through your > proposal. > > Please find my proposal here [1]. I've added there the complete token > flow, introducing a new grant type. > > [1]: * > http://blog.facilelogin.com/2012/10/proposal-resource-owner-initiated.htm= l > * > > Thanks & regards, > -Prabath > > On Sun, Oct 7, 2012 at 6:24 PM, <*zhou.sujing@zte.com.cn*> > wrote: > > Hi, Praba > > I am also thinking on this subject, and published a draft on it. * > **http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt* > I'd like to have your opinion. > > > *Prabath Siriwardena <**prabath@wso2.com* *>* > =B7=A2=BC=FE=C8=CB: *oauth-bounces@ietf.org* > > 2012-10-08 08:08 > > =CA=D5=BC=FE=C8=CB > Eve Maler <*eve@xmlgrrl.com* > > =B3=AD=CB=CD > *oauth@ietf.org* > =D6=F7=CC=E2 > Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > > > > > Hi Eve, > > Thanks for pointers.. I've been following the work done in UMA.. Sure.. > will join the webinar... > > BTW .. I am not quite sure UMA addresses my use case. Even in the case of > UMA it's client initiated or requestor initiated... > > Please correct me if I am wrong... but in OAuth specification there is no > restrictions to identify the 'client' as a person, organization or as him > self.. > > In my view - this is an extended grant type..which has two phases.. > > 1. Resource owner grants access to a selected a Client > 2. Client requests the already available access token for him from the > Authorization Server.[just like passing the refresh_token] > > WDYT ? > > Thanks & regards, > -Prabath > > On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <*eve@xmlgrrl.com*> > wrote: > Hi Prabath, > > As far as I know, OAuth itself generally isn't used to let one human > resource owner delegate access to a different human resource owner. > However, UMA (which leverages OAuth) does strive to solve exactly this us= e > case, among other similar ones; we call this one "person-to-person > sharing", and you can read more about it here: * > http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1* > > The UMA flow at run time still ends up being effectively > "client-initiated" (we would say requesting-party-initiated, using a > requester app) because the original resource owner (we call it an > authorizing party) is no longer around by then. The authz party would set > up policies at some point before going on vacation, and these polices wou= ld > enable the requesting party to "qualify in" for access at run time, by > supplying identity claims that get used in an authorization check by the > authz server (authz manager). > > We'll be walking through UMA flows and demoing an extensive use case at a > webinar on Wed, Oct 17. More info is here: *http://tinyurl.com/umawg* > > Hope this helps, > > Eve > > On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <*prabath@wso2.com*> > wrote: > > > Hi folks, > > > > I would like to know your thoughts on the $subject.. > > > > For me it looks like a concrete use case where OAuth conceptually does > > address - but protocol does not well defined.. > > > > Please find [1] for further details... > > > > [1]: * > http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.= html > * > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> > > > > *http://blog.facilelogin.com* > > *http://RampartFAQ.com* > > _______________________________________________ > > OAuth mailing list > > *OAuth@ietf.org* > > *https://www.ietf.org/mailman/listinfo/oauth* > > > Eve Maler *http://www.xmlgrrl.com/blog*<= http://www.xmlgrrl.com/blog> > * > **+1 425 345 6756* <%2B1%20425%20345%206756> * > http://www.twitter.com/xmlgrrl* > > > > > > -- > Thanks & Regards, > Prabath > > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> * > > **http://blog.facilelogin.com* * > **http://RampartFAQ.com* > _______________________________________________ > OAuth mailing list* > **OAuth@ietf.org* * > **https://www.ietf.org/mailman/listinfo/oauth* > > > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > * > **http://blog.facilelogin.com* * > **http://RampartFAQ.com* > > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --20cf307811d0a525c004cb844335 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Zhou, 

Even though client_id is p= ublic that needs to be passed from the Authorization Server to the Resource= Server. This does not happen in the normal OAuth flow. It only returns bac= k the access_token.

Please let me know if= you need any further clarifications...

On Sun, O= ct 7, 2012 at 8:03 PM, <zhou.sujing@zte.com.cn> wrote:=

Hi,Prabath

 I have read your proposal, and have some questions:

  why RS needs to get access token in client register stage;
  and why RS needs to get client-id from AS by exchanging access token (isn't client-id public?)
 


Prabath Siriwarde= na <prabath@wso2.c= om>

2012-10-08 09:50

=CA=D5=BC=FE=C8= =CB
zhou.sujing@zte.com.cn
=B3=AD=CB=CD
Eve Maler <eve@xmlgrrl.com>, oauth@ietf.org, oauth-bounces@i= etf.org
=D6=F7=CC=E2
Re: Re: [OAUTH-WG] Resource o= wner initiated OAuth delegation





Hi Zhou,

Nice to see some common interest on this. Sure I will go through your proposal.

Please find my proposal here [1]. I've added there the complete token flow, introducing a new grant type.

[1]: http://blog.facilelog= in.com/2012/10/proposal-resource-owner-initiated.html

Thanks & regards,
-Prabath

On Sun, Oct 7, 2012 at 6:24 PM, &l= t;zhou.sujing@zte.com.cn= > wrote:

Hi,  Praba

 I am also thinking on this subject, and published a draft on it.
http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt
 I'd like to have your opinion.
 

Prabath Siriwarde= na <prabath@wso2.com= >
=B7=A2=BC=FE=C8=CB:  oa= uth-bounces@ietf.org

2012-10-08 08:08


=CA=D5=BC=FE=C8= =CB
Eve Maler <<= /font>eve@xmlgrrl.com>
=B3=AD=CB=CD
oauth@ietf.org
=D6=F7=CC=E2
Re: [OAUTH-WG] Resource owner= initiated OAuth delegation







Hi Eve,

Thanks for pointers.. I've been following the work done in UMA.. Sure.. will join the webinar...

BTW .. I am not quite sure UMA addresses my use case. Even in the case of UMA it's client initiated or requestor initiated...

Please correct me if I am wrong... but in OAuth specification there is no restrictions to identify the 'client' as a person, organization = or as him self..  

In my view - this is an extended grant type..which has two phases..

1. Resource owner grants access to a selected a Client
2. Client requests the already available access token for him from the Authorization Server.[just like passing the refresh_token]

WDYT ?

Thanks & regards,
-Prabath  

On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Hi Prabath,

As far as I know, OAuth itself generally isn't used to let one human re= source owner delegate access to a different human resource owner. However, UMA (which leverages OAuth) does strive to solve exactly this use case, among other similar ones; we call this one "person-to-person sharing", and you can read more about it here: http://docs.kantarainitiative= .org/uma/draft-uma-trust.html#anchor1

The UMA flow at run time still ends up being effectively "client-initi= ated" (we would say requesting-party-initiated, using a requester app) because the original resource owner (we call it an authorizing party) is no longer around by then. The authz party would set up policies at some point before going on vacation, and these polices would enable the requesting party to "qualify in" for access at run time, by supplying identity claims that get used in an authorization check by the authz server (authz manager).

We'll be walking through UMA flows and demoing an extensive use case at a webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg

Hope this helps,

       Eve

On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <prabath@wso2.com> wrote:

> Hi folks,
>
> I would like to know your thoughts on the $subject..
>
> For me it looks like a concrete use case where OAuth conceptually does
> address - but protocol does not well defined..
>
> Please find [1] for further details...
>
> [1]: http://blog.facilelogin.com/2012/10/ationwhat= -oauth-lacks-resource-owner.html
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.= com
> http://RampartFAQ.com
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<= font size=3D"3" face=3D"sans-serif">
> https://= www.ietf.org/mailman/listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756   &nb= sp;                     http://www.twitter.com/xmlgrrl=





--
Thanks & Regards,
Prabath

Mobile : <= font size=3D"3" color=3D"blue" face=3D"sans-serif">+94 71 809 6732

http://blog.facilelogin.c= om http://RampartFAQ.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth



--
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732=

http://blog.facilelogin.c= om http://RampartFAQ.com




--
Thank= s & Regards,
Prabath


--20cf307811d0a525c004cb844335-- From julian.reschke@gmx.de Mon Oct 8 04:45:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6822021F8682 for ; Mon, 8 Oct 2012 04:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zFjKqgrrh+t for ; Mon, 8 Oct 2012 04:45:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7598C21F86A2 for ; Mon, 8 Oct 2012 04:45:57 -0700 (PDT) Received: (qmail invoked by alias); 08 Oct 2012 11:45:56 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp016) with SMTP; 08 Oct 2012 13:45:56 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18K+ktyY/AKDk6Dy+Oy58N6mIg4K9eZCi5K69hR+U nsQTr8XL7fv4tE Message-ID: <5072BCEE.60807@gmx.de> Date: Mon, 08 Oct 2012 13:45:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Alexey Melnikov References: <4E1F6AAD24975D4BA5B16804296739436673769B@TK5EX14MBXC285.redmond.corp.microsoft.com> <5006A010.60408@isode.com> In-Reply-To: <5006A010.60408@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" , General Area Review Team , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , The IESG Subject: Re: [OAUTH-WG] [Gen-art] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-22.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:45:58 -0000 On 2012-07-18 13:37, Alexey Melnikov wrote: > On 17/07/2012 19:01, Mike Jones wrote: >> You should actually probably make that name change request to the >> HTTPbis working group. I suspect that if they decide to change the >> name, that we could direct the RFC editor to make the same name change >> as HTTPbis does. > It looks like the discussion of changing this in HTTPBIS is in progress > now. We made that change in HTTPbis, but bearer still seems to use "b64token". Can this be fixed in AUTH48??? Best regards, Julian From hannes.tschofenig@nsn.com Mon Oct 8 04:53:01 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FA321F8620 for ; Mon, 8 Oct 2012 04:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.45 X-Spam-Level: X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p+Z4S20SlC9Y for ; Mon, 8 Oct 2012 04:53:00 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D7A3D21F8681 for ; Mon, 8 Oct 2012 04:52:59 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q98Bqwr8002942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 8 Oct 2012 13:52:58 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q98Bqs9U012150 for ; Mon, 8 Oct 2012 13:52:58 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Oct 2012 13:52:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Oct 2012 14:52:54 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D01EF1504@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-oauth-revocation-01 Thread-Index: Ac2lS3NidSb/r8L/TnCirpO1Wu9nRQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 08 Oct 2012 11:52:55.0171 (UTC) FILETIME=[740C5D30:01CDA54B] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5538 X-purgate-ID: 151667::1349697178-000048BF-33C24044/0-0/0-0 Subject: [OAUTH-WG] draft-ietf-oauth-revocation-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:53:01 -0000 Hi all,=20 I went through draft-ietf-oauth-revocation-01 to what has changed between version -00 and -01.=20 A few minor comments: Title: maybe you should change it from "Token Revocation" to "Revocation of OAuth Access and Refresh Tokens" to make it a bit more informative. The abstract is also a bit too short to explain what the document does. The RFC Editor will at least demand 3 lines of abstract. You may, for example say that the specification covers revocation of access and refresh tokens. Important would also to highlight that the revocation is initiated by the client. You may also want to highlight that this is mainly used as a logout mechanism.=20 I you want to re-word the following sentence a bit: " A revocation request may discard the actual token as well as other tokens based on the same access grant and the access grant itself. "=20 For example: " A revocation request by the client includes the token that shall be revoked. Revoking a refresh token will, however, also revoke any access token created earlier via the presented refresh token. =20 " Introduction: I would not include RFC 2119 language in the introduction. I am also wondering why a specification shouldn't support the revocation of both tokens when requested.=20 You write that the specification supports the following use cases and you list two items. The issue, however, is that item #2 isn't what the specification deals with. Instead, the focus is on item #1 and the revocation feature is more a logout feature, as you describe it rather than a way to deal with stolen tokens.=20 o The end-user triggers revocation from within the client that sends the appropriate revocation request to the autorization server. The request causes the removal of the client's access grant the particular token refers to. From the end-user's perspective, this looks like a "logout" or "reset" function. This use case makes it even more comfortable to the end-user to revoke his access grant immediately via the client. o In contrast to revocation by a client, the authorization server (or a related entity) may offer its end-users a self-care portal to delete access grants given to clients independent of any token storing devices. Such a portal offers the possibility to an end- user to look at and revoke all access grants he once authorized. In cases the token storing device is not available, e.g. it is lost or stolen, revocation by a self-care portal is the only possibility to limit or avoid abuse. Terminology: I would include a Terminology section with the following content: " The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. " You write:=20 In the end, security, usability, and ease of use are increased by token revocation.=20 Could you explain this a bit? The specification does not help with stolen tokens. It also does not help with clients who behave unsupportive.=20 Example: I suggest to expand the example token a bit to avoid the impression that tokens are so short.=20 s/token=3D45ghiukldjahdnhzdauz&/token=3D45ghiukldj....ahdnhzdauz&/ I don't understand this note: "It is also conceivable to allow a dedicated user self-care portal to revoke all kinds of tokens." The self-care portal shouldn't have tokens and hence cannot really revoke them. As such, the self-care portal would be either at the authorization server or very closely related to it (for example with access to the same backend database).=20 Regarding: "=20 If the particular token is a refresh token and the authorization server supports the revocation of access tokens, then the authorization server SHOULD also invalidate all access tokens based on the same access grant. "=20 Why "SHOULD" and not MUST? Shouldn't this sentence say=20 If the presented token is a refresh token then the authorization server MUST invalidate all access tokens created by that refresh token."=20 Note that I=20 - clarified what gets deleted, and =20 - removed unnecessary options. You write:=20 "=20 Whether the revocation takes effect instantly or with some delay depends on the architecture of the particular deployment. The client MUST NOT make any assumptions about the timing and MUST NOT use the token again. "=20 This is an interesting aspect since one would wonder why it isn't sufficient for the client to just delete the tokens it has locally. Nobody else should have the same set of tokens since they are supposed to be minted on the fly for the different clients.=20 Then, wouldn't it be useful for a logout functionality that the revocation actually works instantly rather than at an unpredictable time later ?=20 Could you explain why the cross-origin support is needed?=20 You write:=20 "=20 unsupported_token_type: the client tried to revoke an access token on a server not supporting this feature. "=20 Does this mean that the server does not support the revocation specification at all or just not the ability to revoke access (refresh???) tokens? Security considerations: I would expect to see a discussion about what scenarios this revocation mechanism does not cover.=20 Ciao Hannes From hannes.tschofenig@nsn.com Mon Oct 8 05:12:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CF221F86A3 for ; Mon, 8 Oct 2012 05:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVoCCAkejDaK for ; Mon, 8 Oct 2012 05:12:51 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id BAEE121F855B for ; Mon, 8 Oct 2012 05:12:50 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q98CCiLY012461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 8 Oct 2012 14:12:46 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q98CCg0c008894 for ; Mon, 8 Oct 2012 14:12:44 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Oct 2012 14:12:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDA54E.37D9B20D" Date: Mon, 8 Oct 2012 15:12:42 +0300 Message-ID: <999913AB42CC9341B05A99BBF358718D01EF152F@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-oauth-assertions-06 Thread-Index: Ac2lTjeC5hTo8lQZRfqm39VCg/m1yw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 08 Oct 2012 12:12:43.0440 (UTC) FILETIME=[384FD300:01CDA54E] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6031 X-purgate-ID: 151667::1349698367-00006DFC-0D5A0939/0-0/0-0 Subject: [OAUTH-WG] draft-ietf-oauth-assertions-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 12:12:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CDA54E.37D9B20D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 I took a look at version -06 of the assertions draft to see whether some of the discussions had been reflected in this recent draft update.=20 I was hoping that there is a bit more explanation of the use case that motivates the work. Unfortunately, the update does not contain anything along these lines.=20 For example, the use cases could clarify the following aspects:=20 * Why we need these new client authentication mechanisms? This is not necessarily a way in which SAML is used (at least not to my knowledge). If I understood it correctly then the new client authentication mechanism is only used between the client and the authorization server but not with the resource server. Did I correctly read the document? =20 * Then, there is the assertion usage for authorization grants. There, one could argue that the use case is to interwork with existing SAML infrastructure. The same argument does not apply for the JSON based format since there is no transition need (IMHO at least). Ciao Hannes PS: For the shepherd write-up I have to attach information about the implementation and deployment experience. Is there anything I could mention? Has this specification been part of the OpenID Connect interop tests? If so, what specifically had been tested?=20 ------_=_NextPart_001_01CDA54E.37D9B20D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-oauth-assertions-06

Hi all, =

I took a look = at version -06 of the assertions draft to see whether some of the = discussions had been reflected in this recent draft update. =

I was hoping = that there is a bit more explanation of the use case that motivates the work. Unfortunately, the = update does not contain anything along these lines.

For example, = the use cases could clarify the following aspects:

·       = Why we need these new client authentication = mechanisms? This is not necessarily a way in which SAML is used = (at least not to my knowledge). If I understood it correctly then the new client = authentication mechanism is only used between the client and the = authorization server but not with the resource server. Did I correctly read the = document? 

·       Then, there is the assertion usage for = authorization grants. There, one could argue that the use case is to = interwork with existing SAML infrastructure. The same argument does not apply for the JSON based = format since = there is no transition need (IMHO at least).

Ciao
Hannes

PS: For the = shepherd write-up I have to attach information about the implementation = and deployment experience. Is there anything I could mention? Has this = specification been part of the OpenID Connect interop = tests? If so, what specifically had been tested? =

------_=_NextPart_001_01CDA54E.37D9B20D-- From eve@xmlgrrl.com Mon Oct 8 09:08:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561E121F881D for ; Mon, 8 Oct 2012 09:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Ya2S+GHaS-O for ; Mon, 8 Oct 2012 09:08:20 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 34A5121F881E for ; Mon, 8 Oct 2012 09:08:19 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q98G8Ixd025435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 8 Oct 2012 09:08:18 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_54B1DDAF-0B6B-43CE-BB84-B830BB68405C" From: Eve Maler In-Reply-To: Date: Mon, 8 Oct 2012 09:08:17 -0700 Message-Id: <1ED57829-EA1B-4EF9-BA29-AAD7FFDD4838@xmlgrrl.com> References: <2FA4048C-5AC4-4C0F-A649-785AB8368B31@xmlgrrl.com> To: Prabath Siriwardena X-Mailer: Apple Mail (2.1498) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 16:08:21 -0000 --Apple-Mail=_54B1DDAF-0B6B-43CE-BB84-B830BB68405C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 (I'm not seeing Zhou's responses to you on the list, so I don't have = the other proposal handy. Can Zhou or someone share the link?) Your proposal seems to require that the requester/client register with = the AS (through the RS) ahead of time as well as initiating the approach = to the resource at access-request run time. This seems quite similar = conceptually to UMA. The main difference, I think, is that = "three-legged" OAuth pretty much assumes (though it doesn't strictly = enforce) that the resource owner and the requesting party are the same = person by virtue of authenticating to both the client app and the AS in = a single virtual session (your step #1). UMA anticipates total separation between resource owner/authorizing user = Alice and requesting party/client operator Bob, and lets Alice set up = policies entirely without Bob's presence, requiring only that he present = claims at access-request time. It's more akin to enterprise access = control than authentication-based consent in enabling this separation. There's another example of cooking up an access token ahead of time: = This is one way OpenID Connect achieves the "distributed claims" effect. = If an OpenID Connect IdP isn't responsible for knowing a particular = attribute, but a third-party attribute provider has registered the = attribute's availability with this IdP, the IdP can let clients/RPs get = access to an interim resource that contains an attribute pointer and a = pre-cooked access token for using at the actual attribute provider. But = again, OpenID Connect implicitlly assumes the "same user" across clients = and sessions and web apps. My belief is that judiciously mixing UMA and OpenID Connect (and AXN) -- = each of them already mixes in a lot of OAuth! -- could get us to a = generically applicable claims-based authorization system for both = attributes and arbitrary API calls. Eve On 7 Oct 2012, at 5:08 PM, Prabath Siriwardena wrote: > Hi Eve, >=20 > Thanks for pointers.. I've been following the work done in UMA.. = Sure.. will join the webinar... >=20 > BTW .. I am not quite sure UMA addresses my use case. Even in the case = of UMA it's client initiated or requestor initiated... >=20 > Please correct me if I am wrong... but in OAuth specification there is = no restrictions to identify the 'client' as a person, organization or as = him self..=20 >=20 > In my view - this is an extended grant type..which has two phases.. >=20 > 1. Resource owner grants access to a selected a Client > 2. Client requests the already available access token for him from the = Authorization Server.[just like passing the refresh_token] >=20 > WDYT ? >=20 > Thanks & regards, > -Prabath=20 >=20 > On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler wrote: > Hi Prabath, >=20 > As far as I know, OAuth itself generally isn't used to let one human = resource owner delegate access to a different human resource owner. = However, UMA (which leverages OAuth) does strive to solve exactly this = use case, among other similar ones; we call this one "person-to-person = sharing", and you can read more about it here: = http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1 >=20 > The UMA flow at run time still ends up being effectively = "client-initiated" (we would say requesting-party-initiated, using a = requester app) because the original resource owner (we call it an = authorizing party) is no longer around by then. The authz party would = set up policies at some point before going on vacation, and these = polices would enable the requesting party to "qualify in" for access at = run time, by supplying identity claims that get used in an authorization = check by the authz server (authz manager). >=20 > We'll be walking through UMA flows and demoing an extensive use case = at a webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg >=20 > Hope this helps, >=20 > Eve >=20 > On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena = wrote: >=20 > > Hi folks, > > > > I would like to know your thoughts on the $subject.. > > > > For me it looks like a concrete use case where OAuth conceptually = does > > address - but protocol does not well defined.. > > > > Please find [1] for further details... > > > > [1]: = http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.h= tml > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : +94 71 809 6732 > > > > http://blog.facilelogin.com > > http://RampartFAQ.com > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 >=20 >=20 >=20 >=20 > --=20 > Thanks & Regards, > Prabath >=20 > Mobile : +94 71 809 6732=20 >=20 > http://blog.facilelogin.com > http://RampartFAQ.com >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_54B1DDAF-0B6B-43CE-BB84-B830BB68405C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

UMA anticipates total separation between = resource owner/authorizing user Alice and requesting party/client = operator Bob, and lets Alice set up policies entirely without Bob's = presence, requiring only that he present claims at access-request time. = It's more akin to enterprise access control than authentication-based = consent in enabling this separation.

There's = another example of cooking up an access token ahead of time: This is one = way OpenID Connect achieves the "distributed claims" effect. If an = OpenID Connect IdP isn't responsible for knowing a particular attribute, = but a third-party attribute provider has registered the attribute's = availability with this IdP, the IdP can let clients/RPs get access to an = interim resource that contains an attribute pointer and a pre-cooked = access token for using at the actual attribute provider. But again, = OpenID Connect implicitlly assumes the "same user" across clients and = sessions and web apps.

My belief is that = judiciously mixing UMA and OpenID Connect (and AXN) -- each of them = already mixes in a lot of OAuth! -- could get us to a generically = applicable claims-based authorization system for both attributes and = arbitrary API calls.

= Eve


Hi Eve,

Thanks for pointers.. I've been = following the work done in UMA.. Sure.. will join the = webinar...

BTW .. I am not quite sure UMA = addresses my use case. Even in the case of UMA it's client initiated or = requestor initiated...

Please correct me if I am wrong... but in OAuth = specification there is no restrictions to identify the 'client' as a = person, organization or as him self.. 

In = my view - this is an extended grant type..which has two phases..

1. Resource owner grants access to a selected a = Client
2. Client requests the already available access token = for him from the Authorization Server.[just like passing the = refresh_token]

WDYT ?

Thanks & = regards,
-Prabath 

On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Hi Prabath,

As far as I know, OAuth itself generally isn't used to let one human = resource owner delegate access to a different human resource owner. = However, UMA (which leverages OAuth) does strive to solve exactly this = use case, among other similar ones; we call this one "person-to-person = sharing", and you can read more about it here: http://docs.kantarainitiative.org/uma/draft-uma-trust.ht= ml#anchor1

The UMA flow at run time still ends up being effectively = "client-initiated" (we would say requesting-party-initiated, using a = requester app) because the original resource owner (we call it an = authorizing party) is no longer around by then. The authz party would = set up policies at some point before going on vacation, and these = polices would enable the requesting party to "qualify in" for access at = run time, by supplying identity claims that get used in an authorization = check by the authz server (authz manager).

We'll be walking through UMA flows and demoing an extensive use case at = a webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg

Hope this helps,

        Eve

On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <prabath@wso2.com> wrote:

> Hi folks,
>
> I would like to know your thoughts on the $subject..
>
> For me it looks like a concrete use case where OAuth conceptually = does
> address - but protocol does not well defined..
>
> Please find [1] for further details...
>
> [1]: http://blog.facilelogin.com/2012/10/ationwhat-oauth-lack= s-resource-owner.html
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.com
> http://RampartFAQ.com
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


Eve Maler                   =                http://www.xmlgrrl.com/blog
+1 425 = 345 6756                =          http://www.twitter.com/xmlgrrl





--
Thanks = & Regards,
Prabath




Eve Maler       =                     =        http://www.xmlgrrl.com/blog
+1= 425 345 6756                 =         http://www.twitter.com/xmlgrrl=


= --Apple-Mail=_54B1DDAF-0B6B-43CE-BB84-B830BB68405C-- From bcampbell@pingidentity.com Mon Oct 8 09:29:22 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD26421F86EC for ; Mon, 8 Oct 2012 09:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyxFhCPT8Z89 for ; Mon, 8 Oct 2012 09:29:21 -0700 (PDT) Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4175721F86DA for ; Mon, 8 Oct 2012 09:29:21 -0700 (PDT) Received: from mail-vc0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKUHL/YGVRBMXfSDJAaYQyp0x9OnBcYQJh@postini.com; Mon, 08 Oct 2012 09:29:21 PDT Received: by mail-vc0-f172.google.com with SMTP id fl11so5315480vcb.31 for ; Mon, 08 Oct 2012 09:29:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=r4CkJ+vBKyCDYesQ4XycLKkZAwNRv0ntL7mpxpQxMvc=; b=NeyibcpK8r9iqyLM7Wh8i74e3MKCoMBPVc/VS21ny37EQCQwyVhiKhwCDwrcrLMk/e XnZ46PVvgFyhC12BEjC4CefWl1QWGj4dHmI/EDvjdw1X7YcmwO9RVlldrCV1En6kL3nU wM0SH9u6G1HjfI0Tf+tCNf67pJ1UVlgfKuIsW5SyqShuqTCL9i6Xjl15z4vR20O1x8yx gCSdweTtOufMDUe5DozyxYzg0LiPfz68vBx8dXZUi+VB2LJuod+nlLexxXLNLTkqoJIQ qi6uf/BrZDHjTMy/kE4Zx5ah1fgSOKIjd4NYyKCGxmTBdMQ4+f9l0Q7UUQWpWJVCunjg ztEA== Received: by 10.220.150.16 with SMTP id w16mr9976608vcv.65.1349713759725; Mon, 08 Oct 2012 09:29:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.240 with HTTP; Mon, 8 Oct 2012 09:28:49 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436680231E@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20121004223020.94498B1E002@rfc-editor.org> <4E1F6AAD24975D4BA5B16804296739436680231E@TK5EX14MBXC284.redmond.corp.microsoft.com> From: Brian Campbell Date: Mon, 8 Oct 2012 10:28:49 -0600 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=f46d043890953267c204cb8eb91f X-Gm-Message-State: ALoCoQk6Nno4r6f9zf5ntPdosdJrhKzE9ZEU/qnGGHGX2KIiRnZGdAMAUnri7G0o8SGKrZBvRqZS Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] RFC 6755 on An IETF URN Sub-Namespace for OAuth X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 16:29:22 -0000 --f46d043890953267c204cb8eb91f Content-Type: text/plain; charset=ISO-8859-1 Thanks Mike! They say you never forget your first RFC... On Thu, Oct 4, 2012 at 5:04 PM, Mike Jones wrote: > Congratulations on completing the first OAuth working group RFC!!! > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > rfc-editor@rfc-editor.org > Sent: Thursday, October 04, 2012 3:30 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: oauth@ietf.org; rfc-editor@rfc-editor.org > Subject: [OAUTH-WG] RFC 6755 on An IETF URN Sub-Namespace for OAuth > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6755 > > Title: An IETF URN Sub-Namespace for > OAuth > Author: B. Campbell, H. Tschofenig > Status: Informational > Stream: IETF > Date: October 2012 > Mailbox: brian.d.campbell@gmail.com, > hannes.tschofenig@gmx.net > Pages: 5 > Characters: 8336 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-oauth-urn-sub-ns-06.txt > > URL: http://www.rfc-editor.org/rfc/rfc6755.txt > > This document establishes an IETF URN Sub-namespace for use with > OAuth-related specifications. This document is not an Internet Standards > Track specification; it is published for informational purposes. > > This document is a product of the Web Authorization Protocol Working Group > of the IETF. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html > . > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the author > of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for unlimited > distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --f46d043890953267c204cb8eb91f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Mike!

They say you never forget your first RFC...

On Thu, Oct 4, 2012 at 5:04 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
Congratulations on completing the first OAut= h working group RFC!!!

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

-----Original Message-----
From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org
Sent: Thursday, October 04, 2012 3:30 PM
To: ietf-announ= ce@ietf.org; rfc-dist@rfc-editor.org
Cc: oauth@ietf.org;= rfc-editor@= rfc-editor.org
Subject: [OAUTH-WG] RFC 6755 on An IETF URN Sub-Namespace for OAuth


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


=A0 =A0 =A0 =A0 RFC 6755

=A0 =A0 =A0 =A0 Title: =A0 =A0 =A0An IETF URN Sub-Namespace for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 OAuth
=A0 =A0 =A0 =A0 Author: =A0 =A0 B. Campbell, H. Tschofenig
=A0 =A0 =A0 =A0 Status: =A0 =A0 Informational
=A0 =A0 =A0 =A0 Stream: =A0 =A0 IETF
=A0 =A0 =A0 =A0 Date: =A0 =A0 =A0 October 2012
=A0 =A0 =A0 =A0 Mailbox: =A0 =A0brian.d.campbell@gmail.com,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hannes.tschofenig@gmx.net
=A0 =A0 =A0 =A0 Pages: =A0 =A0 =A05
=A0 =A0 =A0 =A0 Characters: 8336
=A0 =A0 =A0 =A0 Updates/Obsoletes/SeeAlso: =A0 None

=A0 =A0 =A0 =A0 I-D Tag: =A0 =A0draft-ietf-oauth-urn-sub-ns-06.txt

=A0 =A0 =A0 =A0 URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/rfc6755.txt<= /a>

This document establishes an IETF URN Sub-namespace for use with OAuth-rela= ted specifications. =A0This document is not an Internet Standards Track spe= cification; it is published for informational purposes.

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


INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this = memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=A0 http://www.ietf.org/mailman/listinfo/ietf-announce
=A0 http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist<= br>
For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.=
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

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

The RFC Editor Team
Association Management Solutions, LLC


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



--f46d043890953267c204cb8eb91f-- From torsten@lodderstedt.net Mon Oct 8 11:44:12 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C1B21F85A8 for ; Mon, 8 Oct 2012 11:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aRAWHLpKLVx for ; Mon, 8 Oct 2012 11:44:11 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 007AA21F852A for ; Mon, 8 Oct 2012 11:44:04 -0700 (PDT) Received: from [91.2.78.13] (helo=[192.168.71.42]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TLIJ8-0004ay-9d; Mon, 08 Oct 2012 20:44:02 +0200 Message-ID: <50731EF0.4010304@lodderstedt.net> Date: Mon, 08 Oct 2012 20:44:00 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <999913AB42CC9341B05A99BBF358718D01EF1504@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D01EF1504@FIESEXC035.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-01 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:44:12 -0000 Hi Hannes, thanks for your review and feedback. Please find my comments inline. Am 08.10.2012 13:52, schrieb Tschofenig, Hannes (NSN - FI/Espoo): > Hi all, > > I went through draft-ietf-oauth-revocation-01 to what has changed > between version -00 and -01. > > A few minor comments: > > Title: maybe you should change it from "Token Revocation" to "Revocation > of OAuth Access and Refresh Tokens" to make it a bit more informative. why not. What do other WG members think? > The abstract is also a bit too short to explain what the document does. > The RFC Editor will at least demand 3 lines of abstract. You may, for > example say that the specification covers revocation of access and > refresh tokens. Important would also to highlight that the revocation is > initiated by the client. You may also want to highlight that this is > mainly used as a logout mechanism. ok. > > I you want to re-word the following sentence a bit: > " > A revocation request may discard the actual token as well as other > tokens based on the same access grant and the access grant itself. > " > For example: > " > A revocation request by the client includes the token that shall be > revoked. Revoking a refresh token will, however, also revoke any access > token created earlier via the presented refresh token. I see the following issues with your proposal: - I assume not all authorization servers will support access token revocation (none of our servers does) - Access tokens belonging to the same access grant might have been created based on different refresh tokens, since refresh tokens can be rotated (we do this for refresh tokens issued to installed applications). see also http://www.ietf.org/mail-archive/web/oauth/current/msg09244.html That's why I suggested on the list to add the concept of an underlying access grant. This concept proved to be useful during discussions about the different token implementation philosophies at the last IIW. It also allows an authorization server to delete access grants underlying an access token even if it does not issue refresh tokens at all - some authorization servers manage permanent access grants internally and issue access tokens automatically in implicite and code grant type (auto-approval). I therefore would suggest the following wording: "A revocation request by the client includes the token that shall be revoked. Revoking a token may, however, also revoke other tokens based on the same access grant and the acces grant itself." > " > > Introduction: I would not include RFC 2119 language in the introduction. And put the compliance statement into another section? > I am also wondering why a specification shouldn't support the revocation > of both tokens when requested. The assumption is that not all authorization servers will support access token revocation because this comes at a cost. It either requires a lookup of the RS at the AS on every service request OR a push notification of the AS towards all relevant RS on revocation. > > You write that the specification supports the following use cases and > you list two items. The issue, however, is that item #2 isn't what the > specification deals with. Instead, the focus is on item #1 and the > revocation feature is more a logout feature, as you describe it rather > than a way to deal with stolen tokens. What about the self-care portal (see below)? > > o The end-user triggers revocation from within the client that sends > the appropriate revocation request to the autorization server. > The request causes the removal of the client's access grant the > particular token refers to. From the end-user's perspective, this > looks like a "logout" or "reset" function. This use case makes it > even more comfortable to the end-user to revoke his access grant > immediately via the client. > > o In contrast to revocation by a client, the authorization server > (or a related entity) may offer its end-users a self-care portal > to delete access grants given to clients independent of any token > storing devices. Such a portal offers the possibility to an end- > user to look at and revoke all access grants he once authorized. > In cases the token storing device is not available, e.g. it is > lost or stolen, revocation by a self-care portal is the only > possibility to limit or avoid abuse. > > > Terminology: I would include a Terminology section with the following > content: > " > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [RFC2119]. > " ok. > > You write: > > In the end, security, usability, and ease of use are increased by > token revocation. > > Could you explain this a bit? The specification does not help with > stolen tokens. What about the self-care portal? > It also does not help with clients who behave > unsupportive. I don't understand this statement. "unsupportive" with respective to token revocation? > > > Example: I suggest to expand the example token a bit to avoid the > impression that tokens are so short. > s/token=45ghiukldjahdnhzdauz&/token=45ghiukldj....ahdnhzdauz&/ I'm wondering why the core spec shows example tokens of roughly the same size. > > I don't understand this note: > > "It is also conceivable to allow a dedicated user self-care portal to > revoke all kinds of tokens." > The self-care portal shouldn't have tokens and hence cannot really > revoke them. As such, the self-care portal would be either at the > authorization server or very closely related to it (for example with > access to the same backend database). Yes, that's true. Such a portal must have access to the token database. It may be part of the authorization server or a general purpose portal, which access the token database via well-defined (internal) interfaces. We implemented the later pattern. > > > Regarding: > " > If the particular token is a refresh > token and the authorization server supports the revocation of access > tokens, then the authorization server SHOULD also invalidate all > access tokens based on the same access grant. > " > > Why "SHOULD" and not MUST? See above. > > Shouldn't this sentence say > > If the presented token is a refresh token then the authorization server > MUST invalidate all access tokens created by that refresh token." See above. "that refresh token" might not be meaningful in conjunction with refresh token rotation. > > Note that I > - clarified what gets deleted, and > - removed unnecessary options. > > > You write: > " > Whether the revocation takes effect instantly or with some delay > depends on the architecture of the particular deployment. The client > MUST NOT make any assumptions about the timing and MUST NOT use the > token again. > " > > This is an interesting aspect since one would wonder why it isn't > sufficient for the client to just delete the tokens it has locally. > Nobody else should have the same set of tokens since they are supposed > to be minted on the fly for the different clients. Basically, you are right. I'm wondering whether there could be issues in clustered environment, potentielly different nodes could use the same access token? > > Then, wouldn't it be useful for a logout functionality that the > revocation actually works instantly rather than at an unpredictable time > later ? Yes. > > Could you explain why the cross-origin support is needed? I think this is the only way for a user-agent based application to revoke tokens due to the same-origin policy. @Marius: Could you please shed some more light on this aspect? > > You write: > " > unsupported_token_type: the client > tried to revoke an access token on a server not supporting > this feature. > " > Does this mean that the server does not support the revocation > specification at all or just not the ability to revoke access > (refresh???) tokens? Revocation of access tokens is an optional feature > > Security considerations: I would expect to see a discussion about what > scenarios this revocation mechanism does not cover. I thought such a section was intended to discuss the security of the proposed protocol? Do you have specific scenarios in mind? regards, Torsten. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Mon Oct 8 17:05:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B28A21F85AC for ; Mon, 8 Oct 2012 17:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYX4M9hYeUrJ for ; Mon, 8 Oct 2012 17:05:31 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id D17A821F85A8 for ; Mon, 8 Oct 2012 17:05:30 -0700 (PDT) Received: from mail22-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE011.bigfish.com (10.7.40.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 9 Oct 2012 00:05:30 +0000 Received: from mail22-va3 (localhost [127.0.0.1]) by mail22-va3-R.bigfish.com (Postfix) with ESMTP id 1469B3A0063; Tue, 9 Oct 2012 00:05:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VS-22(zz9371Ic85fh14ffIzz1202h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh177df4hz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail22-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail22-va3 (localhost.localdomain [127.0.0.1]) by mail22-va3 (MessageSwitch) id 1349741127964232_2922; Tue, 9 Oct 2012 00:05:27 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.242]) by mail22-va3.bigfish.com (Postfix) with ESMTP id E801CC0045; Tue, 9 Oct 2012 00:05:27 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Oct 2012 00:05:27 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.129]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Tue, 9 Oct 2012 00:05:26 +0000 From: Mike Jones To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "oauth@ietf.org" Thread-Topic: draft-ietf-oauth-assertions-06 Thread-Index: Ac2lTjeC5hTo8lQZRfqm39VCg/m1ywAYqUxg Date: Tue, 9 Oct 2012 00:05:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436682A26D@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <999913AB42CC9341B05A99BBF358718D01EF152F@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D01EF152F@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436682A26DTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 00:05:32 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436682A26DTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, OpenID Connect uses the Assertions spec and the JWT Assertion Profile.= See uses of [OAuth.JWT] in http://openid.net/specs/openid-connect-message= s-1_0.html. It is used for both client_secret_jwt and private_key_jwt cli= ent authentication. Per http://osis.idcommons.net/wiki/Category:OC4_Soluti= on, there are a dozen publicly declared OpenID Connect implementations (adm= ittedly some incomplete), and substantial interop testing is under way, per= http://osis.idcommons.net/wiki/OC4:OpenID_Connect_Interop_4. Brian Campbell and Chuck Mortimore may be able to provide similar data for = use of the SAML Profile. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= schofenig, Hannes (NSN - FI/Espoo) Sent: Monday, October 08, 2012 5:13 AM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-assertions-06 Hi all, I took a look at version -06 of the assertions draft to see whether some of= the discussions had been reflected in this recent draft update. I was hoping that there is a bit more explanation of the use case that moti= vates the work. Unfortunately, the update does not contain anything along t= hese lines. For example, the use cases could clarify the following aspects: * Why we need these new client authentication mechanisms? This is not= necessarily a way in which SAML is used (at least not to my knowledge). If= I understood it correctly then the new client authentication mechanism is = only used between the client and the authorization server but not with the = resource server. Did I correctly read the document? * Then, there is the assertion usage for authorization grants. There,= one could argue that the use case is to interwork with existing SAML infra= structure. The same argument does not apply for the JSON based format since= there is no transition need (IMHO at least). Ciao Hannes PS: For the shepherd write-up I have to attach information about the implem= entation and deployment experience. Is there anything I could mention? Has = this specification been part of the OpenID Connect interop tests? If so, wh= at specifically had been tested? --_000_4E1F6AAD24975D4BA5B16804296739436682A26DTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-oauth-assertions-06

Yes, OpenID Connect uses = the Assertions spec and the JWT Assertion Profile.  See uses of [OAuth= .JWT] in http://openid.net/specs/openid-connect-messages-1_0.ht= ml.   It is used for both client_secret_jwt and private_key_j= wt client authentication.  Per http://osis.idcommons.net/wiki/Category:OC4_Solution, there are a dozen= publicly declared OpenID Connect implementations (admittedly some incomple= te), and substantial interop testing is under way, per htt= p://osis.idcommons.net/wiki/OC4:OpenID_Connect_Interop_4.

 <= /p>

Brian Campbell and Chuck = Mortimore may be able to provide similar data for use of the SAML Profile.<= o:p>

 <= /p>

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, October 08, 2012 5:13 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-assertions-06=

 

H= i all,

I= took a look at version -06 of the assertions draft to see whether some of = the discussions had been reflected in this recent draft update.

I= was hoping that there is a bit more expl= anation of the use case that motivates the work. Unfortunately, the update = does not contain anything along these lines.

F= or example, the use cases could clarify the following aspects:

·       Why = we need these new client authentication mechanisms? This is not necessarily a way in which SAML is used (at least not to my kno= wledge). If I= understood it correctly then the new client authentication mechanism is on= ly used between the client and the authorization server but not with the re= source server. Did = I correctly read the document? 

·       Then= , there is the assertion usage for authorization grants. There, one could argue that t= he use case is to interwork with existing SAML infrastructure. The same argu= ment does not apply for the JSON based format since there is no transition = need (IMHO at least).

C= iao
Hannes

P= S: For the shepherd write-up I have to attach information about the implementation and deployme= nt experience. Is there anything I could mention? Has this specification be= en part of the OpenID Connect interop tests? If so, what spec= ifically had been tested?

--_000_4E1F6AAD24975D4BA5B16804296739436682A26DTK5EX14MBXC284r_-- From cmortimore@salesforce.com Mon Oct 8 17:14:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6CC21F86E0 for ; Mon, 8 Oct 2012 17:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PocMSx84C75i for ; Mon, 8 Oct 2012 17:14:15 -0700 (PDT) Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by ietfa.amsl.com (Postfix) with SMTP id D719D21F87D1 for ; Mon, 8 Oct 2012 17:14:14 -0700 (PDT) Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKUHNsVoLPPRjBQ5T+PauDmHlHt4CMSEoy@postini.com; Mon, 08 Oct 2012 17:14:14 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Mon, 8 Oct 2012 17:14:13 -0700 From: Chuck Mortimore To: Mike Jones Date: Mon, 8 Oct 2012 17:14:12 -0700 Thread-Topic: [OAUTH-WG] draft-ietf-oauth-assertions-06 Thread-Index: Ac2lswLgzd2fPVmESumR42fJuuYe0A== Message-ID: <9F69CF75-53B5-4376-8430-E4289FFA625E@salesforce.com> References: <999913AB42CC9341B05A99BBF358718D01EF152F@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739436682A26D@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436682A26D@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9F69CF7553B543768430E4289FFA625Esalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 00:14:16 -0000 --_000_9F69CF7553B543768430E4289FFA625Esalesforcecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Our use-cases are pretty straightforward - customers want to perform server= to server integration tasks without passwords. We use the SAML and JWT assertion profiles to enable them to authenticate t= o our system without having a password for the service principal they're tr= ying to act as. Sometimes this is for security purposes ( customer doesn'= t want to use passwords ), and sometimes it's for scale purposes ( customer= is building some sort of hub-spoke integration architecture where password= s and their associated distribution and maintenance simple won't scale ) While SAML is predominantly used for Web SSO today, it is used and quite ap= plicable in these types of scenarios. The easy way to picture what we're = doing is deploying a Security Token Service similar to WS-Trust, but withou= t all the baggage of WS-Trust....you can simply post Assertions to our Toke= n Endpoint and we can exchange that for oauth access tokens. -cmort On Oct 8, 2012, at 5:05 PM, Mike Jones wrote: Yes, OpenID Connect uses the Assertions spec and the JWT Assertion Profile.= See uses of [OAuth.JWT] in http://openid.net/specs/openid-connect-message= s-1_0.html. It is used for both client_secret_jwt and private_key_jwt cli= ent authentication. Per http://osis.idcommons.net/wiki/Category:OC4_Soluti= on, there are a dozen publicly declared OpenID Connect implementations (adm= ittedly some incomplete), and substantial interop testing is under way, per= http://osis.idcommons.net/wiki/OC4:OpenID_Connect_Interop_4. Brian Campbell and Chuck Mortimore may be able to provide similar data for = use of the SAML Profile. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, October 08, 2012 5:13 AM To: oauth@ietf.org Subject: [OAUTH-WG] draft-ietf-oauth-assertions-06 Hi all, I took a look at version -06 of the assertions draft to see whether some of= the discussions had been reflected in this recent draft update. I was hoping that there is a bit more explanation of the use case that moti= vates the work. Unfortunately, the update does not contain anything along t= hese lines. For example, the use cases could clarify the following aspects: * Why we need these new client authentication mechanisms? This is not= necessarily a way in which SAML is used (at least not to my knowledge). If= I understood it correctly then the new client authentication mechanism is = only used between the client and the authorization server but not with the = resource server. Did I correctly read the document? * Then, there is the assertion usage for authorization grants. There,= one could argue that the use case is to interwork with existing SAML infra= structure. The sameargument does not apply for the JSON based format since = there is no transition need (IMHO at least). Ciao Hannes PS: For the shepherd write-up I have to attach information about the implem= entation and deployment experience. Is there anything I could mention? Has = this specification been part of the OpenID Connect interop tests? If so, wh= at specifically had been tested? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_9F69CF7553B543768430E4289FFA625Esalesforcecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes, OpenID Connec= t uses the Assertions spec and the JWT Assertion Profile.  See uses of= [OAuth.JWT] in http://openid.n= et/specs/openid-connect-messages-1_0.html.   It is used for b= oth client_secret_jwt and private_key_jwt client authentication.  Per<= span class=3D"Apple-converted-space"> http://osis.idcommons.net/wiki/Category:OC4_Solution, = there are a dozen publicly declared OpenID Connect implementations (admitte= dly some incomplete), and substantial interop testing is under way, per http://osis.idcommons.net/wiki/OC4:OpenID_Connect_Inte= rop_4.
 =
Brian Campbell and Chuck Mortimore may be able to pr= ovide similar data for use of the SAML Profile.
 
  &nb= sp;            =             &nb= sp;            =             &nb= sp;           -- Mike
 
Fro= m: = oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]&nbs= p;On Behalf Of = Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, October 08, 2012 5:13 AM
To: oauth@ietf.= org
Subject: [OAUTH-WG] draft-ietf-oauth-assertions-06
 

Hi all,

= I took a look at version -06 of the assertions draft to see whether some of= the discussions had been reflected in this recent draft update.

I was hoping that there is a bit more explanation of the use case that motivates the work. Unfort= unately, the update does not contain anything along these lines.

For example, the use cases could clarify the following a= spects:

=B7       W= hy we need these <= span style=3D"font-family: Calibri, sans-serif; ">new client authentication= mechanisms? This is not necessarily a way= in which SAML is used (at least not to my knowledge). If I understood it correctly then the new client authenticatio= n mechanism is only used between the client and the authorization server bu= t not with the resource server. Did I corr= ectly read the document? 

=B7       Then, there is the a= ssertion usage for authorization grants. There, one could argue that the us= e case is to interwork with existing SAML infrastructure. The sameargument does not apply fo= r the JSON based format since there is no transition need (IMHO at least).<= /span>

Ciao
Hannes

= PS: For the shepherd write-up I have to at= tach information about the implementation and deployment experience. Is the= re anything I could mention? Has this specification been part of the OpenID= Connect interop tests? If so, what specif= ically had been tested?

________________________= _______________________
OAuth mailing list
OAuth@ietf.org<= /a>
https://www.ietf.org/mailman/listin= fo/oauth

= --_000_9F69CF7553B543768430E4289FFA625Esalesforcecom_-- From zhou.sujing@zte.com.cn Mon Oct 8 18:32:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5804A1F0420; Mon, 8 Oct 2012 18:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.048 X-Spam-Level: X-Spam-Status: No, score=-96.048 tagged_above=-999 required=5 tests=[AWL=1.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phlwBpKNQNwF; Mon, 8 Oct 2012 18:32:19 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF7321F87E3; Mon, 8 Oct 2012 18:32:18 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 082751250B53; Tue, 9 Oct 2012 09:24:46 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q991OFXm078845; Tue, 9 Oct 2012 09:24:15 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Prabath Siriwardena MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 9 Oct 2012 09:24:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-09 09:24:13, Serialize complete at 2012-10-09 09:24:13 Content-Type: multipart/alternative; boundary="=_alternative 0007C9ED48257A92_=" X-MAIL: mse01.zte.com.cn q991OFXm078845 Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 01:32:21 -0000 This is a multipart message in MIME format. --=_alternative 0007C9ED48257A92_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrCBQcmFiYXRoDQogDQogIE15IHF1ZXN0aW9uIGlzIHNpbmNlIGNsaWVudC1pZCBpcyBwdWJs aWMsIHRoZW4gaXQgaXMgYSB3YXN0ZSB0byBnZXQgaXQgDQpieSBncmFudGluZyBhbiBhY2Nlc3Mt dG9rZW4uDQogIEFuZCBpbiBzdGVwIDIuIlJlc291cmNlIE93bmVyIGdyYW50cyBhY2Nlc3MgdG8g YSBzZWxlY3RlZCBDbGllbnQiLCBSTyANCmxvZ2lucyBpbiB0byBzZWxlY3QgY2xpZW50cyB0byBi ZSBkZWxlZ2F0ZWQsDQogYW5kIFJTIHJlZGlyZWN0cyBSTyB0byBBUyB0byBncmFudCBhY2Nlc3Mg dG9rZW4gdG8gY2xpZW50LCB0byBteSANCnVuZGVyc3RhbmRpbmcsIGluIHRoaXMgcHJvY2VzcyBS TyBuZWVkcyB0byBhdXRoZW50aWNhdGUgdG8gUlMgYW5kIHRoZW4gDQphdXRoZW50aWNhdGUNCnRv IEFTLCBpdCBpcyBhIGJpdCBjb21wbGljYXRlZC4NCg0KICBJIHdvbmRlciBpZiB0aGUgZm9sbG93 aW5nIHR3byBwcm9jZXNzZXMgY291bGQgc2F0aXNmeSB5b3VyIGNhc2U6DQoNClByb2Nlc3MgT25l Og0KMS4gUmVzb3VyY2UgT3duZXIgcmVnaXN0ZXJzIHRvLWJlLWRlbGVnYXRlZCBjbGllbnRzIGFu ZCBjb3JyZXNwb25kaW5nIFJTcyANCmF0IEFTLCBpLmUuLCBhIGxvbmcgdGVybSBkZWxlZ2F0aW9u IGNvbnRyYWN0IGlzIHN0b3JlZCBhdCBBUyANCg0KMi4gV2hlbiBSZXNvdXJjZSBPd25lciByZXF1 ZXN0cyBDbGllbnQgdG8gYWNjZXNzIGl0cyByZXNvdXJjZSBhdCBSUywgDQpDbGllbnQgaXMgZGly ZWN0ZWQgYnkgUlMgdG8gQVMgdG8gb2J0YWluIGFjY2Vzcy10b2tlbg0KMy4gQ2xpZW50IGFjY2Vz c2VzIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2Ugb24gYmVoYWxmIG9mIHRoZSBSZXNvdXJjZSBPd25l ci4NCg0KUHJvY2VzcyBUd286DQoxLiBSTyByZWdpc3RlcnMgdG8tYmUtZGVsZWdhdGVkIGNsaWVu dHMgYXQgUlMsIGkuZS4sIGEgbG9uZyB0ZXJtIA0KZGVsZWdhdGlvbiBjb250cmFjdCBpcyBzdG9y ZWQgYXQgUlMgDQoyLiBXaGVuIFJlc291cmNlIE93bmVyIHJlcXVlc3RzIENsaWVudCB0byBhY2Nl c3MgaXRzIHJlc291cmNlIGF0IFJTLCANCkNsaWVudCBpcyBkaXJlY3RlZCBieSBSUyB0byBBUyB0 byBvYnRhaW4gYWNjZXNzLXRva2VuLEFTIG1heSByZXF1ZXN0IFJPIHRvIA0KYXV0aGVudGljYXRl IGFuZCBjb25maXJtIHRoZSANCmFjY2Vzcy10b2tlbiByZXF1ZXN0DQozLiBDbGllbnQgYWNjZXNz ZXMgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBvbiBiZWhhbGYgb2YgdGhlIFJlc291cmNlIE93bmVy LiANCiANCg0KDQoNCg0KUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbT4gDQoy MDEyLTEwLTA4IDEyOjAwDQoNCsrVvP7Iyw0KemhvdS5zdWppbmdAenRlLmNvbS5jbg0Ks63LzQ0K RXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb20+LCBvYXV0aEBpZXRmLm9yZywgb2F1dGgtYm91bmNl c0BpZXRmLm9yZw0K1vfM4g0KUmU6IFJlOiBSZTogW09BVVRILVdHXSBSZXNvdXJjZSBvd25lciBp bml0aWF0ZWQgT0F1dGggZGVsZWdhdGlvbg0KDQoNCg0KDQoNCg0KSGkgWmhvdSwgDQoNCkV2ZW4g dGhvdWdoIGNsaWVudF9pZCBpcyBwdWJsaWMgdGhhdCBuZWVkcyB0byBiZSBwYXNzZWQgZnJvbSB0 aGUgDQpBdXRob3JpemF0aW9uIFNlcnZlciB0byB0aGUgUmVzb3VyY2UgU2VydmVyLiBUaGlzIGRv ZXMgbm90IGhhcHBlbiBpbiB0aGUgDQpub3JtYWwgT0F1dGggZmxvdy4gSXQgb25seSByZXR1cm5z IGJhY2sgdGhlIGFjY2Vzc190b2tlbi4NCg0KUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBuZWVk IGFueSBmdXJ0aGVyIGNsYXJpZmljYXRpb25zLi4uDQoNClRoYW5rcyAmIHJlZ2FyZHMsDQotUHJh YmF0aA0KDQpPbiBTdW4sIE9jdCA3LCAyMDEyIGF0IDg6MDMgUE0sIDx6aG91LnN1amluZ0B6dGUu Y29tLmNuPiB3cm90ZToNCg0KSGksUHJhYmF0aCANCg0KIEkgaGF2ZSByZWFkIHlvdXIgcHJvcG9z YWwsIGFuZCBoYXZlIHNvbWUgcXVlc3Rpb25zOiANCg0KICB3aHkgUlMgbmVlZHMgdG8gZ2V0IGFj Y2VzcyB0b2tlbiBpbiBjbGllbnQgcmVnaXN0ZXIgc3RhZ2U7IA0KICBhbmQgd2h5IFJTIG5lZWRz IHRvIGdldCBjbGllbnQtaWQgZnJvbSBBUyBieSBleGNoYW5naW5nIGFjY2VzcyB0b2tlbiANCihp c24ndCBjbGllbnQtaWQgcHVibGljPykgDQogDQoNCg0KDQpQcmFiYXRoIFNpcml3YXJkZW5hIDxw cmFiYXRoQHdzbzIuY29tPiANCjIwMTItMTAtMDggMDk6NTAgDQoNCg0KytW8/sjLDQp6aG91LnN1 amluZ0B6dGUuY29tLmNuIA0Ks63LzQ0KRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb20+LCBvYXV0 aEBpZXRmLm9yZywgb2F1dGgtYm91bmNlc0BpZXRmLm9yZyANCtb3zOINClJlOiBSZTogW09BVVRI LVdHXSBSZXNvdXJjZSBvd25lciBpbml0aWF0ZWQgT0F1dGggZGVsZWdhdGlvbg0KDQoNCg0KDQoN Cg0KDQoNCkhpIFpob3UsIA0KDQpOaWNlIHRvIHNlZSBzb21lIGNvbW1vbiBpbnRlcmVzdCBvbiB0 aGlzLiBTdXJlIEkgd2lsbCBnbyB0aHJvdWdoIHlvdXIgDQpwcm9wb3NhbC4gDQoNClBsZWFzZSBm aW5kIG15IHByb3Bvc2FsIGhlcmUgWzFdLiBJJ3ZlIGFkZGVkIHRoZXJlIHRoZSBjb21wbGV0ZSB0 b2tlbiANCmZsb3csIGludHJvZHVjaW5nIGEgbmV3IGdyYW50IHR5cGUuIA0KDQpbMV06IA0KaHR0 cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tLzIwMTIvMTAvcHJvcG9zYWwtcmVzb3VyY2Utb3duZXIt aW5pdGlhdGVkLmh0bWwgDQoNCg0KVGhhbmtzICYgcmVnYXJkcywgDQotUHJhYmF0aCANCg0KT24g U3VuLCBPY3QgNywgMjAxMiBhdCA2OjI0IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbj4gd3Jv dGU6IA0KDQpIaSwgIFByYWJhIA0KDQogSSBhbSBhbHNvIHRoaW5raW5nIG9uIHRoaXMgc3ViamVj dCwgYW5kIHB1Ymxpc2hlZCBhIGRyYWZ0IG9uIGl0LiANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC16aG91LW9hdXRoLW93bmVyLWF1dGgtMDAudHh0IA0KIEknZCBsaWtlIHRvIGhhdmUg eW91ciBvcGluaW9uLiANCiANCg0KDQpQcmFiYXRoIFNpcml3YXJkZW5hIDxwcmFiYXRoQHdzbzIu Y29tPiANCreivP7IyzogIG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgDQoyMDEyLTEwLTA4IDA4OjA4 IA0KDQoNCsrVvP7Iyw0KRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb20+IA0Ks63LzQ0Kb2F1dGhA aWV0Zi5vcmcgDQrW98ziDQpSZTogW09BVVRILVdHXSBSZXNvdXJjZSBvd25lciBpbml0aWF0ZWQg T0F1dGggZGVsZWdhdGlvbg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpIaSBFdmUsIA0KDQpUaGFua3Mg Zm9yIHBvaW50ZXJzLi4gSSd2ZSBiZWVuIGZvbGxvd2luZyB0aGUgd29yayBkb25lIGluIFVNQS4u IFN1cmUuLiANCndpbGwgam9pbiB0aGUgd2ViaW5hci4uLiANCg0KQlRXIC4uIEkgYW0gbm90IHF1 aXRlIHN1cmUgVU1BIGFkZHJlc3NlcyBteSB1c2UgY2FzZS4gRXZlbiBpbiB0aGUgY2FzZSBvZiAN ClVNQSBpdCdzIGNsaWVudCBpbml0aWF0ZWQgb3IgcmVxdWVzdG9yIGluaXRpYXRlZC4uLiANCg0K UGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy4uLiBidXQgaW4gT0F1dGggc3BlY2lmaWNh dGlvbiB0aGVyZSBpcyBubyANCnJlc3RyaWN0aW9ucyB0byBpZGVudGlmeSB0aGUgJ2NsaWVudCcg YXMgYSBwZXJzb24sIG9yZ2FuaXphdGlvbiBvciBhcyBoaW0gDQpzZWxmLi4gDQoNCkluIG15IHZp ZXcgLSB0aGlzIGlzIGFuIGV4dGVuZGVkIGdyYW50IHR5cGUuLndoaWNoIGhhcyB0d28gcGhhc2Vz Li4gDQoNCjEuIFJlc291cmNlIG93bmVyIGdyYW50cyBhY2Nlc3MgdG8gYSBzZWxlY3RlZCBhIENs aWVudCANCjIuIENsaWVudCByZXF1ZXN0cyB0aGUgYWxyZWFkeSBhdmFpbGFibGUgYWNjZXNzIHRv a2VuIGZvciBoaW0gZnJvbSB0aGUgDQpBdXRob3JpemF0aW9uIFNlcnZlci5banVzdCBsaWtlIHBh c3NpbmcgdGhlIHJlZnJlc2hfdG9rZW5dIA0KDQpXRFlUID8gDQoNClRoYW5rcyAmIHJlZ2FyZHMs IA0KLVByYWJhdGggDQoNCk9uIFN1biwgT2N0IDcsIDIwMTIgYXQgMTE6MDUgQU0sIEV2ZSBNYWxl ciA8ZXZlQHhtbGdycmwuY29tPiB3cm90ZTogDQpIaSBQcmFiYXRoLA0KDQpBcyBmYXIgYXMgSSBr bm93LCBPQXV0aCBpdHNlbGYgZ2VuZXJhbGx5IGlzbid0IHVzZWQgdG8gbGV0IG9uZSBodW1hbiAN CnJlc291cmNlIG93bmVyIGRlbGVnYXRlIGFjY2VzcyB0byBhIGRpZmZlcmVudCBodW1hbiByZXNv dXJjZSBvd25lci4gDQpIb3dldmVyLCBVTUEgKHdoaWNoIGxldmVyYWdlcyBPQXV0aCkgZG9lcyBz dHJpdmUgdG8gc29sdmUgZXhhY3RseSB0aGlzIHVzZSANCmNhc2UsIGFtb25nIG90aGVyIHNpbWls YXIgb25lczsgd2UgY2FsbCB0aGlzIG9uZSAicGVyc29uLXRvLXBlcnNvbiANCnNoYXJpbmciLCBh bmQgeW91IGNhbiByZWFkIG1vcmUgYWJvdXQgaXQgaGVyZTogDQpodHRwOi8vZG9jcy5rYW50YXJh aW5pdGlhdGl2ZS5vcmcvdW1hL2RyYWZ0LXVtYS10cnVzdC5odG1sI2FuY2hvcjENCg0KVGhlIFVN QSBmbG93IGF0IHJ1biB0aW1lIHN0aWxsIGVuZHMgdXAgYmVpbmcgZWZmZWN0aXZlbHkgDQoiY2xp ZW50LWluaXRpYXRlZCIgKHdlIHdvdWxkIHNheSByZXF1ZXN0aW5nLXBhcnR5LWluaXRpYXRlZCwg dXNpbmcgYSANCnJlcXVlc3RlciBhcHApIGJlY2F1c2UgdGhlIG9yaWdpbmFsIHJlc291cmNlIG93 bmVyICh3ZSBjYWxsIGl0IGFuIA0KYXV0aG9yaXppbmcgcGFydHkpIGlzIG5vIGxvbmdlciBhcm91 bmQgYnkgdGhlbi4gVGhlIGF1dGh6IHBhcnR5IHdvdWxkIHNldCANCnVwIHBvbGljaWVzIGF0IHNv bWUgcG9pbnQgYmVmb3JlIGdvaW5nIG9uIHZhY2F0aW9uLCBhbmQgdGhlc2UgcG9saWNlcyANCndv dWxkIGVuYWJsZSB0aGUgcmVxdWVzdGluZyBwYXJ0eSB0byAicXVhbGlmeSBpbiIgZm9yIGFjY2Vz cyBhdCBydW4gdGltZSwgDQpieSBzdXBwbHlpbmcgaWRlbnRpdHkgY2xhaW1zIHRoYXQgZ2V0IHVz ZWQgaW4gYW4gYXV0aG9yaXphdGlvbiBjaGVjayBieSANCnRoZSBhdXRoeiBzZXJ2ZXIgKGF1dGh6 IG1hbmFnZXIpLg0KDQpXZSdsbCBiZSB3YWxraW5nIHRocm91Z2ggVU1BIGZsb3dzIGFuZCBkZW1v aW5nIGFuIGV4dGVuc2l2ZSB1c2UgY2FzZSBhdCBhIA0Kd2ViaW5hciBvbiBXZWQsIE9jdCAxNy4g TW9yZSBpbmZvIGlzIGhlcmU6IGh0dHA6Ly90aW55dXJsLmNvbS91bWF3Zw0KDQpIb3BlIHRoaXMg aGVscHMsDQoNCiAgICAgICBFdmUgDQoNCk9uIDYgT2N0IDIwMTIsIGF0IDEwOjI5IEFNLCBQcmFi YXRoIFNpcml3YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPiB3cm90ZToNCg0KPiBIaSBmb2xrcywN Cj4NCj4gSSB3b3VsZCBsaWtlIHRvIGtub3cgeW91ciB0aG91Z2h0cyBvbiB0aGUgJHN1YmplY3Qu Lg0KPg0KPiBGb3IgbWUgaXQgbG9va3MgbGlrZSBhIGNvbmNyZXRlIHVzZSBjYXNlIHdoZXJlIE9B dXRoIGNvbmNlcHR1YWxseSBkb2VzDQo+IGFkZHJlc3MgLSBidXQgcHJvdG9jb2wgZG9lcyBub3Qg d2VsbCBkZWZpbmVkLi4NCj4NCj4gUGxlYXNlIGZpbmQgWzFdIGZvciBmdXJ0aGVyIGRldGFpbHMu Li4NCj4NCj4gWzFdOiANCmh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbS8yMDEyLzEwL2F0aW9u d2hhdC1vYXV0aC1sYWNrcy1yZXNvdXJjZS1vd25lci5odG1sDQoNCj4NCj4gLS0NCj4gVGhhbmtz ICYgUmVnYXJkcywNCj4gUHJhYmF0aA0KPg0KPiBNb2JpbGUgOiArOTQgNzEgODA5IDY3MzINCj4N Cj4gaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tDQo+IGh0dHA6Ly9SYW1wYXJ0RkFRLmNvbSAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1 dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpFdmUgTWFsZXIgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaHR0cDovL3d3dy54bWxncnJsLmNvbS9ibG9nDQorMSA0MjUgMzQ1IDY3 NTYgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy50d2l0dGVyLmNvbS94bWxncnJs DQoNCg0KDQoNCg0KLS0gDQpUaGFua3MgJiBSZWdhcmRzLA0KUHJhYmF0aCANCg0KTW9iaWxlIDog Kzk0IDcxIDgwOSA2NzMyIA0KDQpodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCmh0dHA6Ly9S YW1wYXJ0RkFRLmNvbSANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoNCi0tIA0KVGhhbmtzICYgUmVn YXJkcywNClByYWJhdGggDQoNCk1vYmlsZSA6ICs5NCA3MSA4MDkgNjczMiANCg0KaHR0cDovL2Js b2cuZmFjaWxlbG9naW4uY29tDQpodHRwOi8vUmFtcGFydEZBUS5jb20gDQoNCg0KDQoNCi0tIA0K VGhhbmtzICYgUmVnYXJkcywNClByYWJhdGgNCg0KTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0K DQpodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbQ0KDQoN Cg== --=_alternative 0007C9ED48257A92_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6wgUHJhYmF0aDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IE15IHF1ZXN0aW9uIGlzIHNpbmNl IGNsaWVudC1pZA0KaXMgcHVibGljLCB0aGVuIGl0IGlzIGEgd2FzdGUgdG8gZ2V0IGl0IGJ5IGdy YW50aW5nIGFuIGFjY2Vzcy10b2tlbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyBBbmQgaW4gc3RlcCAyPC9mb250Pjxmb250IHNpemU9Mz4uJnF1b3Q7 UmVzb3VyY2UNCk93bmVyIGdyYW50cyBhY2Nlc3MgdG8gYSBzZWxlY3RlZCBDbGllbnQ8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OywNClJPICZuYnNwO2xvZ2lucyBp biB0byBzZWxlY3QgY2xpZW50cyB0byBiZSBkZWxlZ2F0ZWQsPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDthbmQgUlMgcmVkaXJlY3RzIFJPIHRvIEFTIHRv IGdyYW50DQphY2Nlc3MgdG9rZW4gdG8gY2xpZW50LCB0byBteSB1bmRlcnN0YW5kaW5nLCBpbiB0 aGlzIHByb2Nlc3MgUk8gbmVlZHMgdG8NCmF1dGhlbnRpY2F0ZSB0byBSUyBhbmQgdGhlbiBhdXRo ZW50aWNhdGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnRvIEFT LCBpdCBpcyBhIGJpdCBjb21wbGljYXRlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJIHdvbmRlciBpZiB0aGUgZm9sbG93aW5nIHR3bw0K cHJvY2Vzc2VzIGNvdWxkIHNhdGlzZnkgeW91ciBjYXNlOjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UHJvY2VzcyBPbmU6PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBSZXNvdXJjZSBPd25lciByZWdpc3RlcnMgdG8t YmUtZGVsZWdhdGVkDQpjbGllbnRzIGFuZCBjb3JyZXNwb25kaW5nIFJTcyBhdCBBUywgaS5lLiwg YSBsb25nIHRlcm0gZGVsZWdhdGlvbiBjb250cmFjdA0KaXMgc3RvcmVkIGF0IEFTIDwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4gV2hlbiBSZXNvdXJj ZSBPd25lciByZXF1ZXN0cyBDbGllbnQNCnRvIGFjY2VzcyBpdHMgcmVzb3VyY2UgYXQgUlMsIENs aWVudCBpcyBkaXJlY3RlZCBieSBSUyB0byBBUyB0byBvYnRhaW4NCmFjY2Vzcy10b2tlbjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+My4gQ2xpZW50IGFjY2Vzc2Vz IHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UNCm9uIGJlaGFsZiBvZiB0aGUgUmVzb3VyY2UgT3duZXIu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Qcm9jZXNz IFR3bzo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEuIFJPIHJl Z2lzdGVycyB0by1iZS1kZWxlZ2F0ZWQgY2xpZW50cw0KYXQgUlMsIGkuZS4sIGEgbG9uZyB0ZXJt IGRlbGVnYXRpb24gY29udHJhY3QgaXMgc3RvcmVkIGF0IFJTIDwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4gV2hlbiBSZXNvdXJjZSBPd25lciByZXF1ZXN0cyBD bGllbnQNCnRvIGFjY2VzcyBpdHMgcmVzb3VyY2UgYXQgUlMsIENsaWVudCBpcyBkaXJlY3RlZCBi eSBSUyB0byBBUyB0byBvYnRhaW4NCmFjY2Vzcy10b2tlbixBUyBtYXkgcmVxdWVzdCBSTyB0byBh dXRoZW50aWNhdGUgYW5kIGNvbmZpcm0gdGhlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+YWNjZXNzLXRva2VuIHJlcXVlc3Q8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuIENsaWVudCBhY2Nlc3NlcyB0aGUgcHJvdGVjdGVkIHJl c291cmNlDQpvbiBiZWhhbGYgb2YgdGhlIFJlc291cmNlIE93bmVyLiAmbmJzcDsgPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlByYWJh dGggU2lyaXdhcmRlbmEgJmx0O3ByYWJhdGhAd3NvMi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMTAtMDggMTI6MDA8L2ZvbnQ+DQo8 dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7Iyzwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+emhvdS5zdWpp bmdAenRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1y aWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+RXZlIE1hbGVyICZsdDtldmVAeG1sZ3Jy bC5jb20mZ3Q7LCBvYXV0aEBpZXRmLm9yZywNCm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPlJlOiBSZTogUmU6IFtPQVVUSC1XR10gUmVzb3VyY2Ugb3duZXINCmluaXRp YXRlZCBPQXV0aCBkZWxlZ2F0aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPkhpIFpob3UsIDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+ RXZlbiB0aG91Z2ggY2xpZW50X2lkIGlzIHB1YmxpYw0KdGhhdCBuZWVkcyB0byBiZSBwYXNzZWQg ZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gdGhlIFJlc291cmNlIFNlcnZlci4NClRo aXMgZG9lcyBub3QgaGFwcGVuIGluIHRoZSBub3JtYWwgT0F1dGggZmxvdy4gSXQgb25seSByZXR1 cm5zIGJhY2sgdGhlDQphY2Nlc3NfdG9rZW4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MyBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFsIj5QbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IG5l ZWQNCmFueSBmdXJ0aGVyIGNsYXJpZmljYXRpb25zLi4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MyBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFsIj5UaGFua3MgJmFtcDsgcmVnYXJkcyw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPi1QcmFi YXRoPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5PbiBT dW4sIE9jdCA3LCAyMDEyIGF0IDg6MDMgUE0sICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhv dS5zdWppbmdAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1Pnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0Kd3JvdGU6PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpIaSw8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPlByYWJhdGg8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPGJyPg0KIEkgaGF2ZSByZWFkIHlvdXIgcHJvcG9z YWwsIGFuZCBoYXZlIHNvbWUgcXVlc3Rpb25zOiA8YnI+DQo8YnI+DQogJm5ic3A7d2h5IFJTIG5l ZWRzIHRvIGdldCBhY2Nlc3MgdG9rZW4gaW4gY2xpZW50IHJlZ2lzdGVyIHN0YWdlOyA8YnI+DQog Jm5ic3A7YW5kIHdoeSBSUyBuZWVkcyB0byBnZXQgY2xpZW50LWlkIGZyb20gQVMgYnkgZXhjaGFu Z2luZyBhY2Nlc3MgdG9rZW4NCihpc24ndCBjbGllbnQtaWQgcHVibGljPykgPGJyPg0KICZuYnNw Ozxicj4NCjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZCB3aWR0aD0zNyU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlBy YWJhdGggU2lyaXdhcmRlbmEgJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cHJhYmF0aEB3 c28yLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMt c2VyaWYiPjxiPjx1PnByYWJhdGhAd3NvMi5jb208L3U+PC9iPjwvZm9udD48L2E+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMC0wOCAwOTo1MDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NjIlPg0KPGJyPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD04JT4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4N Cjx0ZCB3aWR0aD05MSU+PGEgaHJlZj1tYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbiB0YXJn ZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pnpo b3Uuc3VqaW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkV2ZSBNYWxlciAmbHQ7PC9mb250PjxhIGhy ZWY9bWFpbHRvOmV2ZUB4bWxncnJsLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xv cj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PmV2ZUB4bWxncnJsLmNvbTwvdT48L2ZvbnQ+PC9h Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7LA0KPC9mb250PjxhIGhyZWY9bWFp bHRvOm9hdXRoQGlldGYub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUg ZmFjZT0ic2Fucy1zZXJpZiI+PHU+b2F1dGhAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+LA0KPC9mb250PjxhIGhyZWY9Im1haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPjx1Pm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3 zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBS ZTogW09BVVRILVdHXSBSZXNvdXJjZSBvd25lciBpbml0aWF0ZWQNCk9BdXRoIGRlbGVnYXRpb248 L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9u dD48Zm9udCBzaXplPTMgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+PGJyPg0KSGkgWmhvdSw8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPjxicj4NCk5pY2UgdG8gc2VlIHNvbWUg Y29tbW9uIGludGVyZXN0IG9uIHRoaXMuIFN1cmUgSSB3aWxsIGdvIHRocm91Z2ggeW91ciBwcm9w b3NhbC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250 Pjxmb250IHNpemU9MyBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFsIj48YnI+DQpQbGVhc2UgZmlu ZCBteSBwcm9wb3NhbCBoZXJlIFsxXS4gSSd2ZSBhZGRlZCB0aGVyZSB0aGUgY29tcGxldGUgdG9r ZW4gZmxvdywNCmludHJvZHVjaW5nIGEgbmV3IGdyYW50IHR5cGUuPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMjIy MjIyIGZhY2U9IkFyaWFsIj48YnI+DQpbMV06IDwvZm9udD48YSBocmVmPSJodHRwOi8vYmxvZy5m YWNpbGVsb2dpbi5jb20vMjAxMi8xMC9wcm9wb3NhbC1yZXNvdXJjZS1vd25lci1pbml0aWF0ZWQu aHRtbCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9IzExNTVjYyBmYWNlPSJBcmlh bCI+PHU+aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tLzIwMTIvMTAvcHJvcG9zYWwtcmVzb3Vy Y2Utb3duZXItaW5pdGlhdGVkLmh0bWw8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMyMjIyMjIgZmFj ZT0iQXJpYWwiPjxicj4NClRoYW5rcyAmYW1wOyByZWdhcmRzLDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzIyMjIyMiBmYWNl PSJBcmlhbCI+PGJyPg0KLVByYWJhdGg8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiA8YnI+DQo8YnI+DQpPbiBTdW4sIE9jdCA3LCAyMDEyIGF0IDY6MjQgUE0sICZsdDs8L2Zv bnQ+PGEgaHJlZj1tYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pnpob3Uuc3VqaW5nQHp0 ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0 Ow0Kd3JvdGU6IDxicj4NCjxicj4NCkhpLCAmbmJzcDtQcmFiYSA8YnI+DQo8YnI+DQogSSBhbSBh bHNvIHRoaW5raW5nIG9uIHRoaXMgc3ViamVjdCwgYW5kIHB1Ymxpc2hlZCBhIGRyYWZ0IG9uIGl0 LiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJy Pg0KPC91PjwvZm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtemhv dS1vYXV0aC1vd25lci1hdXRoLTAwLnR4dCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJh ZnQtemhvdS1vYXV0aC1vd25lci1hdXRoLTAwLnR4dDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCiBJJ2QgbGlrZSB0byBoYXZlIHlvdXIgb3Bpbmlv bi4gPGJyPg0KIDxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD00MiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi PlByYWJhdGggU2lyaXdhcmRlbmEgJmx0OzwvYj48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cHJhYmF0 aEB3c28yLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNh bnMtc2VyaWYiPjxiPjx1PnByYWJhdGhAd3NvMi5jb208L3U+PC9iPjwvZm9udD48L2E+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZndDs8L2I+DQo8YnI+DQq3orz+yMs6ICZuYnNw OzwvZm9udD48YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9i bGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5vYXV0aC1i b3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMTAt MDggMDg6MDg8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0K PHRkIHdpZHRoPTU3JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9OSU+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQgd2lkdGg9OTAlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5FdmUgTWFsZXIgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpldmVA eG1sZ3JybC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJz YW5zLXNlcmlmIj48dT5ldmVAeG1sZ3JybC5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGEgaHJl Zj1tYWlsdG86b2F1dGhAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5vYXV0aEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM 4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtP QVVUSC1XR10gUmVzb3VyY2Ugb3duZXIgaW5pdGlhdGVkDQpPQXV0aCBkZWxlZ2F0aW9uPC9mb250 PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9u dD4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCkhpIEV2ZSwgPGJy Pg0KPGJyPg0KVGhhbmtzIGZvciBwb2ludGVycy4uIEkndmUgYmVlbiBmb2xsb3dpbmcgdGhlIHdv cmsgZG9uZSBpbiBVTUEuLiBTdXJlLi4NCndpbGwgam9pbiB0aGUgd2ViaW5hci4uLiA8YnI+DQo8 YnI+DQpCVFcgLi4gSSBhbSBub3QgcXVpdGUgc3VyZSBVTUEgYWRkcmVzc2VzIG15IHVzZSBjYXNl LiBFdmVuIGluIHRoZSBjYXNlDQpvZiBVTUEgaXQncyBjbGllbnQgaW5pdGlhdGVkIG9yIHJlcXVl c3RvciBpbml0aWF0ZWQuLi4gPGJyPg0KPGJyPg0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSBhbSB3 cm9uZy4uLiBidXQgaW4gT0F1dGggc3BlY2lmaWNhdGlvbiB0aGVyZSBpcw0Kbm8gcmVzdHJpY3Rp b25zIHRvIGlkZW50aWZ5IHRoZSAnY2xpZW50JyBhcyBhIHBlcnNvbiwgb3JnYW5pemF0aW9uIG9y IGFzDQpoaW0gc2VsZi4uICZuYnNwOzxicj4NCjxicj4NCkluIG15IHZpZXcgLSB0aGlzIGlzIGFu IGV4dGVuZGVkIGdyYW50IHR5cGUuLndoaWNoIGhhcyB0d28gcGhhc2VzLi4gPGJyPg0KPGJyPg0K MS4gUmVzb3VyY2Ugb3duZXIgZ3JhbnRzIGFjY2VzcyB0byBhIHNlbGVjdGVkIGEgQ2xpZW50IDxi cj4NCjIuIENsaWVudCByZXF1ZXN0cyB0aGUgYWxyZWFkeSBhdmFpbGFibGUgYWNjZXNzIHRva2Vu IGZvciBoaW0gZnJvbSB0aGUNCkF1dGhvcml6YXRpb24gU2VydmVyLltqdXN0IGxpa2UgcGFzc2lu ZyB0aGUgcmVmcmVzaF90b2tlbl0gPGJyPg0KPGJyPg0KV0RZVCA/IDxicj4NCjxicj4NClRoYW5r cyAmYW1wOyByZWdhcmRzLCA8YnI+DQotUHJhYmF0aCAmbmJzcDs8YnI+DQo8YnI+DQpPbiBTdW4s IE9jdCA3LCAyMDEyIGF0IDExOjA1IEFNLCBFdmUgTWFsZXIgJmx0OzwvZm9udD48YSBocmVmPW1h aWx0bzpldmVAeG1sZ3JybC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5ldmVAeG1sZ3JybC5jb208L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0Kd3JvdGU6IDxicj4NCkhpIFByYWJhdGgs PGJyPg0KPGJyPg0KQXMgZmFyIGFzIEkga25vdywgT0F1dGggaXRzZWxmIGdlbmVyYWxseSBpc24n dCB1c2VkIHRvIGxldCBvbmUgaHVtYW4gcmVzb3VyY2UNCm93bmVyIGRlbGVnYXRlIGFjY2VzcyB0 byBhIGRpZmZlcmVudCBodW1hbiByZXNvdXJjZSBvd25lci4gSG93ZXZlciwgVU1BDQood2hpY2gg bGV2ZXJhZ2VzIE9BdXRoKSBkb2VzIHN0cml2ZSB0byBzb2x2ZSBleGFjdGx5IHRoaXMgdXNlIGNh c2UsIGFtb25nDQpvdGhlciBzaW1pbGFyIG9uZXM7IHdlIGNhbGwgdGhpcyBvbmUgJnF1b3Q7cGVy c29uLXRvLXBlcnNvbiBzaGFyaW5nJnF1b3Q7LA0KYW5kIHlvdSBjYW4gcmVhZCBtb3JlIGFib3V0 IGl0IGhlcmU6IDwvZm9udD48YSBocmVmPSJodHRwOi8vZG9jcy5rYW50YXJhaW5pdGlhdGl2ZS5v cmcvdW1hL2RyYWZ0LXVtYS10cnVzdC5odG1sI2FuY2hvcjEiIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL2RvY3Mua2FudGFy YWluaXRpYXRpdmUub3JnL3VtYS9kcmFmdC11bWEtdHJ1c3QuaHRtbCNhbmNob3IxPC91PjwvZm9u dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NClRoZSBVTUEg ZmxvdyBhdCBydW4gdGltZSBzdGlsbCBlbmRzIHVwIGJlaW5nIGVmZmVjdGl2ZWx5ICZxdW90O2Ns aWVudC1pbml0aWF0ZWQmcXVvdDsNCih3ZSB3b3VsZCBzYXkgcmVxdWVzdGluZy1wYXJ0eS1pbml0 aWF0ZWQsIHVzaW5nIGEgcmVxdWVzdGVyIGFwcCkgYmVjYXVzZQ0KdGhlIG9yaWdpbmFsIHJlc291 cmNlIG93bmVyICh3ZSBjYWxsIGl0IGFuIGF1dGhvcml6aW5nIHBhcnR5KSBpcyBubyBsb25nZXIN CmFyb3VuZCBieSB0aGVuLiBUaGUgYXV0aHogcGFydHkgd291bGQgc2V0IHVwIHBvbGljaWVzIGF0 IHNvbWUgcG9pbnQgYmVmb3JlDQpnb2luZyBvbiB2YWNhdGlvbiwgYW5kIHRoZXNlIHBvbGljZXMg d291bGQgZW5hYmxlIHRoZSByZXF1ZXN0aW5nIHBhcnR5DQp0byAmcXVvdDtxdWFsaWZ5IGluJnF1 b3Q7IGZvciBhY2Nlc3MgYXQgcnVuIHRpbWUsIGJ5IHN1cHBseWluZyBpZGVudGl0eQ0KY2xhaW1z IHRoYXQgZ2V0IHVzZWQgaW4gYW4gYXV0aG9yaXphdGlvbiBjaGVjayBieSB0aGUgYXV0aHogc2Vy dmVyIChhdXRoeg0KbWFuYWdlcikuPGJyPg0KPGJyPg0KV2UnbGwgYmUgd2Fsa2luZyB0aHJvdWdo IFVNQSBmbG93cyBhbmQgZGVtb2luZyBhbiBleHRlbnNpdmUgdXNlIGNhc2UgYXQNCmEgd2ViaW5h ciBvbiBXZWQsIE9jdCAxNy4gTW9yZSBpbmZvIGlzIGhlcmU6IDwvZm9udD48YSBocmVmPWh0dHA6 Ly90aW55dXJsLmNvbS91bWF3ZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly90aW55dXJsLmNvbS91bWF3ZzwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQpIb3BlIHRoaXMg aGVscHMsPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7IEV2ZSA8YnI+DQo8YnI+DQpP biA2IE9jdCAyMDEyLCBhdCAxMDoyOSBBTSwgUHJhYmF0aCBTaXJpd2FyZGVuYSAmbHQ7PC9mb250 PjxhIGhyZWY9bWFpbHRvOnByYWJhdGhAd3NvMi5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5wcmFiYXRoQHdzbzIuY29tPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZndDsNCndyb3RlOjxicj4N Cjxicj4NCiZndDsgSGkgZm9sa3MsPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB3b3VsZCBsaWtlIHRv IGtub3cgeW91ciB0aG91Z2h0cyBvbiB0aGUgJHN1YmplY3QuLjxicj4NCiZndDs8YnI+DQomZ3Q7 IEZvciBtZSBpdCBsb29rcyBsaWtlIGEgY29uY3JldGUgdXNlIGNhc2Ugd2hlcmUgT0F1dGggY29u Y2VwdHVhbGx5DQpkb2VzPGJyPg0KJmd0OyBhZGRyZXNzIC0gYnV0IHByb3RvY29sIGRvZXMgbm90 IHdlbGwgZGVmaW5lZC4uPGJyPg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIGZpbmQgWzFdIGZvciBm dXJ0aGVyIGRldGFpbHMuLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBbMV06IDwvZm9udD48YSBocmVm PSJodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20vMjAxMi8xMC9hdGlvbndoYXQtb2F1dGgtbGFj a3MtcmVzb3VyY2Utb3duZXIuaHRtbCIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20vMjAx Mi8xMC9hdGlvbndoYXQtb2F1dGgtbGFja3MtcmVzb3VyY2Utb3duZXIuaHRtbDwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQomZ3Q7PGJyPg0KJmd0OyAt LTxicj4NCiZndDsgVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KJmd0OyBQcmFiYXRoPGJyPg0K Jmd0Ozxicj4NCiZndDsgTW9iaWxlIDogPC9mb250PjxhIGhyZWY9dGVsOiUyQjk0JTIwNzElMjA4 MDklMjA2NzMyIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fu cy1zZXJpZiI+PHU+Kzk0DQo3MSA4MDkgNjczMjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQomZ3Q7PGJyPg0KJmd0OyA8L2ZvbnQ+PGEgaHJlZj1odHRw Oi8vYmxvZy5mYWNpbGVsb2dpbi5jb20vIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiZndDsgPC9m b250PjxhIGhyZWY9aHR0cDovL3JhbXBhcnRmYXEuY29tLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9SYW1wYXJ0RkFRLmNv bTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPC9mb250PjxhIGhyZWY9bWFpbHRvOk9B dXRoQGlldGYub3JnIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+PHU+T0F1dGhAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KJmd0OyA8L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQpFdmUgTWFsZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGEgaHJlZj1o dHRwOi8vd3d3LnhtbGdycmwuY29tL2Jsb2cgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vd3d3LnhtbGdycmwuY29tL2Jsb2c8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48 dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9dGVsOiUyQjElMjA0MjUlMjAzNDUlMjA2NzU2IHRh cmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ KzENCjQyNSAzNDUgNjc1NjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4gJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48YSBocmVmPWh0dHA6Ly93 d3cudHdpdHRlci5jb20veG1sZ3JybCB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly93d3cudHdpdHRlci5jb20veG1sZ3JybDwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQpUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+ DQpQcmFiYXRoIDxicj4NCjxicj4NCk1vYmlsZSA6IDwvZm9udD48YSBocmVmPXRlbDolMkI5NCUy MDcxJTIwODA5JTIwNjczMiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPjx1Pis5NA0KNzEgODA5IDY3MzI8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBm YWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cDov L2Jsb2cuZmFjaWxlbG9naW4uY29tLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbTwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxi cj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vcmFtcGFydGZhcS5jb20vIHRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL1Jh bXBhcnRGQVEuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi Pg0KPC9mb250Pjx0dD48Zm9udCBzaXplPTM+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PC90 dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+ PC9mb250PjxhIGhyZWY9bWFpbHRvOk9BdXRoQGlldGYub3JnIHRhcmdldD1fYmxhbms+PHR0Pjxm b250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pk9BdXRoQGlldGYub3JnPC91PjwvZm9udD48L3R0Pjwv YT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+ PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCB0YXJnZXQ9X2JsYW5rPjx0dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC91PjwvZm9udD48L3R0PjwvYT48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K LS0gPGJyPg0KVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KUHJhYmF0aCA8YnI+DQo8YnI+DQpN b2JpbGUgOiA8L2ZvbnQ+PGEgaHJlZj10ZWw6JTJCOTQlMjA3MSUyMDgwOSUyMDY3MzIgdGFyZ2V0 PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT4rOTQN CjcxIDgwOSA2NzMyPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJy Pg0KPGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbS8g dGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48 dT5odHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9 aHR0cDovL3JhbXBhcnRmYXEuY29tLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbTwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD4NCjxwPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi0tIDxicj4NClRoYW5rcyAmYW1wOyBSZWdhcmRz LDxicj4NClByYWJhdGg8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPk1vYmlsZSA6ICs5NCA3MSA4MDkgNjczMiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVm PWh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbS8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5j b208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cDovL3JhbXBhcnRmYXEuY29tLyB0YXJn ZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0 dHA6Ly9SYW1wYXJ0RkFRLmNvbTwvdT48L2ZvbnQ+PC9hPg0KPGJyPg0KPGJyPg0K --=_alternative 0007C9ED48257A92_=-- From prabath@wso2.com Tue Oct 9 05:35:59 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB4B21F88A1 for ; Tue, 9 Oct 2012 05:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-0.579, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJImITSG8DmN for ; Tue, 9 Oct 2012 05:35:58 -0700 (PDT) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0C15621F8894 for ; Tue, 9 Oct 2012 05:35:57 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id 56so1237163yhq.31 for ; Tue, 09 Oct 2012 05:35:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DOVk7JaZZB9OCrKKAPc2F1ZAzdQZYqgdtaN4jq1CkqY=; b=jjHyQhmL2CicNRB6LDZOTkZM42Yzh434057DKaqTBJ0By2DNYMbP+3vOebAlpwP19Q 7S2lOj6neyDNjAc8Pgp6sDZ5E3d+5RYVF7Du9xiBrnyQE88ipHMxwmSKSHGtPgjT1cT3 3MZbziGVwW9k6SID3pVM9rNbmtMKjPa2ZOJehiZfU5mxvYT/5z5TBJFp6LWZm9l8F+Zu 3K2+8unQ7JYREcyBjRycHZ2xQkkkrO1noXM7s3S/aPi+sX3QHAvhEgh9Y4ne52RnBk7v o9OZKypGNBBXJNR3Iy0fZs4FeAtgJqq1isoryiiWOizXN2p7BTdwYkWBM3FixQZPlW04 oeMA== MIME-Version: 1.0 Received: by 10.58.94.44 with SMTP id cz12mr12204127veb.34.1349786156896; Tue, 09 Oct 2012 05:35:56 -0700 (PDT) Received: by 10.59.0.129 with HTTP; Tue, 9 Oct 2012 05:35:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Oct 2012 05:35:56 -0700 Message-ID: From: Prabath Siriwardena To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=047d7b6dcaf06792ff04cb9f94d2 X-Gm-Message-State: ALoCoQkJmIm8RVFEZnAJMcYRJ4/cSHDkXDbc924dN5WtjAE6PNtp5KNeReSi30AciUeindMZXCTx Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 12:35:59 -0000 --047d7b6dcaf06792ff04cb9f94d2 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On Mon, Oct 8, 2012 at 6:24 PM, wrote: > > Hi=A3=AC Prabath > > My question is since client-id is public, then it is a waste to get it > by granting an access-token. > And in step 2."Resource Owner grants access to a selected Client", RO > logins in to select clients to be delegated, > and RS redirects RO to AS to grant access token to client, to my > understanding, in this process RO needs to authenticate to RS and then > authenticate > to AS, it is a bit complicated. > In fact I did not want to disturb normal OAuth flow.. BTW yes.. it adds some overhead.. So - I would like to modify it - where the Resource Server sends the resource_owner_initiated as the scope - and based on the scope AS returns back client_id together with the access_token it self. > > I wonder if the following two processes could satisfy your case: > > Process One: > 1. Resource Owner registers to-be-delegated clients and corresponding RSs > at AS, i.e., a long term delegation contract is stored at AS > > 2. When Resource Owner requests Client to access its resource at RS, > Client is directed by RS to AS to obtain access-token > 3. Client accesses the protected resource on behalf of the Resource Owner= . > > Process Two: > 1. RO registers to-be-delegated clients at RS, i.e., a long term > delegation contract is stored at RS > 2. When Resource Owner requests Client to access its resource at RS, > Client is directed by RS to AS to obtain access-token,AS may request RO t= o > authenticate and confirm the > access-token request > 3. Client accesses the protected resource on behalf of the Resource Owner= . > > > There needs to be an step to facilitate client registration. Thanks & regards, -Prabath > > > *Prabath Siriwardena * > > 2012-10-08 12:00 > =CA=D5=BC=FE=C8=CB > zhou.sujing@zte.com.cn > =B3=AD=CB=CD > Eve Maler , oauth@ietf.org, oauth-bounces@ietf.org > =D6=F7=CC=E2 > Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > > > Hi Zhou, > > Even though client_id is public that needs to be passed from the > Authorization Server to the Resource Server. This does not happen in the > normal OAuth flow. It only returns back the access_token. > > Please let me know if you need any further clarifications... > > Thanks & regards, > -Prabath > > On Sun, Oct 7, 2012 at 8:03 PM, <*zhou.sujing@zte.com.cn*> > wrote: > > Hi,Prabath > > I have read your proposal, and have some questions: > > why RS needs to get access token in client register stage; > and why RS needs to get client-id from AS by exchanging access token > (isn't client-id public?) > > > *Prabath Siriwardena <**prabath@wso2.com* *>* > > 2012-10-08 09:50 > > =CA=D5=BC=FE=C8=CB > *zhou.sujing@zte.com.cn* > =B3=AD=CB=CD > Eve Maler <*eve@xmlgrrl.com* >, *oauth@ietf.org*, > *oauth-bounces@ietf.org* > =D6=F7=CC=E2 > Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > > > > > Hi Zhou, > > Nice to see some common interest on this. Sure I will go through your > proposal. > > Please find my proposal here [1]. I've added there the complete token > flow, introducing a new grant type. > > [1]: * > http://blog.facilelogin.com/2012/10/proposal-resource-owner-initiated.htm= l > * > > Thanks & regards, > -Prabath > > On Sun, Oct 7, 2012 at 6:24 PM, <*zhou.sujing@zte.com.cn*> > wrote: > > Hi, Praba > > I am also thinking on this subject, and published a draft on it. * > **http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt* > I'd like to have your opinion. > > *Prabath Siriwardena <**prabath@wso2.com* *>* > =B7=A2=BC=FE=C8=CB: *oauth-bounces@ietf.org* > > 2012-10-08 08:08 > > =CA=D5=BC=FE=C8=CB > Eve Maler <*eve@xmlgrrl.com* > > =B3=AD=CB=CD > *oauth@ietf.org* > =D6=F7=CC=E2 > Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > > > > > > > Hi Eve, > > Thanks for pointers.. I've been following the work done in UMA.. Sure.. > will join the webinar... > > BTW .. I am not quite sure UMA addresses my use case. Even in the case of > UMA it's client initiated or requestor initiated... > > Please correct me if I am wrong... but in OAuth specification there is no > restrictions to identify the 'client' as a person, organization or as him > self.. > > In my view - this is an extended grant type..which has two phases.. > > 1. Resource owner grants access to a selected a Client > 2. Client requests the already available access token for him from the > Authorization Server.[just like passing the refresh_token] > > WDYT ? > > Thanks & regards, > -Prabath > > On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <*eve@xmlgrrl.com*> > wrote: > Hi Prabath, > > As far as I know, OAuth itself generally isn't used to let one human > resource owner delegate access to a different human resource owner. > However, UMA (which leverages OAuth) does strive to solve exactly this us= e > case, among other similar ones; we call this one "person-to-person > sharing", and you can read more about it here: * > http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1* > > The UMA flow at run time still ends up being effectively > "client-initiated" (we would say requesting-party-initiated, using a > requester app) because the original resource owner (we call it an > authorizing party) is no longer around by then. The authz party would set > up policies at some point before going on vacation, and these polices wou= ld > enable the requesting party to "qualify in" for access at run time, by > supplying identity claims that get used in an authorization check by the > authz server (authz manager). > > We'll be walking through UMA flows and demoing an extensive use case at a > webinar on Wed, Oct 17. More info is here: *http://tinyurl.com/umawg* > > Hope this helps, > > Eve > > On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <*prabath@wso2.com*> > wrote: > > > Hi folks, > > > > I would like to know your thoughts on the $subject.. > > > > For me it looks like a concrete use case where OAuth conceptually does > > address - but protocol does not well defined.. > > > > Please find [1] for further details... > > > > [1]: * > http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-owner.= html > * > > > > -- > > Thanks & Regards, > > Prabath > > > > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> > > > > *http://blog.facilelogin.com* > > *http://RampartFAQ.com* > > _______________________________________________ > > OAuth mailing list > > *OAuth@ietf.org* > > *https://www.ietf.org/mailman/listinfo/oauth* > > > Eve Maler *http://www.xmlgrrl.com/blog*<= http://www.xmlgrrl.com/blog> > * > **+1 425 345 6756* <%2B1%20425%20345%206756> * > http://www.twitter.com/xmlgrrl* > > > > > > -- > Thanks & Regards, > Prabath > > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> * > > **http://blog.facilelogin.com* * > **http://RampartFAQ.com* > _______________________________________________ > OAuth mailing list* > **OAuth@ietf.org* * > **https://www.ietf.org/mailman/listinfo/oauth* > > > > > -- > Thanks & Regards, > Prabath > > Mobile : *+94 71 809 6732* <%2B94%2071%20809%206732> * > > **http://blog.facilelogin.com* * > **http://RampartFAQ.com* > > > > > -- > Thanks & Regards, > Prabath > > Mobile : +94 71 809 6732 > * > **http://blog.facilelogin.com* * > **http://RampartFAQ.com* > > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --047d7b6dcaf06792ff04cb9f94d2 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Thanks
Pedro

--f46d0401fa290429ce04cbb53b5d-- From internet-drafts@ietf.org Wed Oct 10 08:45:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3793421F87DC; Wed, 10 Oct 2012 08:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBFp0OlOirMR; Wed, 10 Oct 2012 08:45:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F0E21F87E0; Wed, 10 Oct 2012 08:45:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121010154551.811.70513.idtracker@ietfa.amsl.com> Date: Wed, 10 Oct 2012 08:45:51 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-use-cases-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 15:45:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth Use Cases Author(s) : George Fletcher Torsten Lodderstedt Zachary Zeltsan Filename : draft-ietf-oauth-use-cases-02.txt Pages : 24 Date : 2012-10-10 Abstract: This document lists the OAuth use cases. The provided list is based on the Internet Drafts of the OAUTH working group and discussions on the group's mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-use-cases-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-use-cases-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zachary.zeltsan@alcatel-lucent.com Wed Oct 10 09:30:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3981F0429 for ; Wed, 10 Oct 2012 09:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.748 X-Spam-Level: X-Spam-Status: No, score=-9.748 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YPGTEsQiN6z for ; Wed, 10 Oct 2012 09:30:36 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3AE1F041F for ; Wed, 10 Oct 2012 09:30:34 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9AGPErc019851 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 10 Oct 2012 18:30:29 +0200 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Oct 2012 18:29:49 +0200 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.198]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 10 Oct 2012 12:29:46 -0400 From: "Zeltsan, Zachary (Zachary)" To: "'oauth@ietf.org WG'" Thread-Topic: New Version Notification for draft-ietf-oauth-use-cases-02.txt Thread-Index: AQHNpv5xJEF7Wxnzw0GCnFwqwEoZMpeyru/A Date: Wed, 10 Oct 2012 16:29:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_F5B2863BFA782C4E8866941363AE88E8C6B890US70TWXCHMBA09zam_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:30:37 -0000 --_000_F5B2863BFA782C4E8866941363AE88E8C6B890US70TWXCHMBA09zam_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gYmVoYWxmIG9mIHRoZSBjby1hdXRob3JzIEkgaGF2ZSBwb3N0ZWQgdGhlIGRyYWZ0Lg0KDQpU aGUgbWFpbiBjaGFuZ2VzIGluIHRoZSAtMDIgdmVyc2lvbiBhcmUgdGhlIGZvbGxvd2luZzoNCg0K DQoNCsK3ICAgICAgICAgUmVtb3ZhbCBvZiB0aGUgdXNlIGNhc2Ugb24gcmUtZGVsZWdhdGlvbi4g KFRoZSBjYXNlIGlzIHRvbyBmYXIgZnJvbSB0aGUgcHJlc2VudCBPQXV0aCAyLjApDQoNCsK3ICAg ICAgICAgQ2xhcmlmaWNhdGlvbiBvZiB0aGUgdXNlIGNhc2UgRGV2aWNlDQoNCsK3ICAgICAgICAg QWRkaXRpb24gb2YgYSBub3RlIGZvciBlYWNoIHVzZSBjYXNlIHRoYXQgaW5kaWNhdGVzIHdoZXRo ZXIgdGhlIHVzZSBjYXNlIHN1cHBvcnRlZCBieSBPQXV0aCAyLjANCg0KwrcgICAgICAgICBVcGRh dGUgb2YgdGhlIHJlZmVyZW5jZXMNCg0KwrcgICAgICAgICBJbmNsdXNpb24gb2YgdGhlIHJlZmVy ZW5jZXMgdG8gdGhlIFdHIHNlY3VyaXR5IGRvY3VtZW50cyBpbiB0aGUgU2VjdXJpdHkgQ29uc2lk ZXJhdGlvbiBzZWN0aW9uDQoNCg0KDQpZb3VyIGNvbW1lbnRzIGFyZSB3ZWxjb21lZC4NCg0KUGFy dGljdWxhcmx5LCB0aGUgYXV0aG9ycyBhcmUgbG9va2luZyBmb3IgYWR2aWNlIHdpdGggdGhlIHVz ZSBvZiB0aGUgZXhhbXBsZSBVUkxzLiBGb2xsb3dpbmcgdGhlIGd1aWRhbmNlIG9mIFJGQyAyNjA2 LA0KDQp3ZSBoYXZlIHVzZWQg4oCcZXhhbXBsZeKAnSBhcyB0aGUgdG9wIGxldmVsIGRvbWFpbiBu YW1lIChlLmcuLCBleGFtcGxlLmNvbSkuIFRoaXMgbWF5IG1pc2xlYWQgcmVhZGVycyBpbnRvIHRo aW5raW5nIHRoYXQgYWxsIFVSTHMgYmVsb25nIHRvIHRoZSBzYW1lIG9yZ2FuaXphdGlvbi4gQSBn ZW5lcmFsIG5vdGUsIHN0YXRpbmcgdGhhdCBhbGwgc2l0ZXMgZW5kaW5nIHdpdGgg4oCcZXhhbXBs ZS5jb23igJ0gZG8gbm90IG5lY2Vzc2FyaWx5IGJlbG9uZyB0byB0aGUgc2FtZSBvcmdhbml6YXRp b24sIGlzIG5vdCBzdWZmaWNpZW50IChhY2NvcmRpbmcgdG8gc29tZSByZWFkZXJzKS4gSG93IHRv IGF2b2lkIHRoZSBjb25mdXNpb24/DQoNCg0KDQpaYWNoYXJ5DQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIwMTIgMTE6 NDYgQU0NClRvOiBaZWx0c2FuLCBaYWNoYXJ5IChaYWNoYXJ5KQ0KQ2M6IHRvcnN0ZW5AbG9kZGVy c3RlZHQubmV0OyBnZmZsZXRjaEBhb2wuY29tDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAyLnR4dA0KDQoNCg0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW9hdXRoLXVzZS1jYXNlcy0wMi50eHQNCg0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBaYWNoYXJ5IFplbHRzYW4gYW5kIHBv c3RlZCB0byB0aGUNCg0KSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KRmlsZW5hbWU6ICAgICAgICBk cmFmdC1pZXRmLW9hdXRoLXVzZS1jYXNlcw0KDQpSZXZpc2lvbjogICAgICAgICAgMDINCg0KVGl0 bGU6ICAgICAgICAgICAgICAgT0F1dGggVXNlIENhc2VzDQoNCkNyZWF0aW9uIGRhdGU6IDIwMTIt MTAtMTANCg0KV0cgSUQ6ICAgICAgICAgICAgIG9hdXRoDQoNCk51bWJlciBvZiBwYWdlczogMjQN Cg0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLW9hdXRoLXVzZS1jYXNlcy0wMi50eHQNCg0KU3RhdHVzOiAgICAgICAgICBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzDQoN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1v YXV0aC11c2UtY2FzZXMtMDINCg0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW9hdXRoLXVzZS1jYXNlcy0wMg0KDQoNCg0KQWJzdHJh Y3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQgbGlzdHMgdGhlIE9BdXRoIHVzZSBjYXNlcy4gIFRoZSBw cm92aWRlZCBsaXN0IGlzIGJhc2VkDQoNCiAgIG9uIHRoZSBJbnRlcm5ldCBEcmFmdHMgb2YgdGhl IE9BVVRIIHdvcmtpbmcgZ3JvdXAgYW5kIGRpc2N1c3Npb25zIG9uDQoNCiAgIHRoZSBncm91cCdz IG1haWxpbmcgbGlzdC4NCg0KDQoNCg0KDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoN Cg0K --_000_F5B2863BFA782C4E8866941363AE88E8C6B890US70TWXCHMBA09zam_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxh aW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsN Cglmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1Nzk2MjkwODY7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODQwOTg3NTg0IC02MTIxOTIyNjIg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDow Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+T24gYmVoYWxmIG9mIHRoZSBjby1hdXRob3JzIEkgaGF2ZSBwb3N0ZWQgdGhlIGRy YWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIG1haW4gY2hh bmdlcyBpbiB0aGUgLTAyIHZlcnNpb24gYXJlIHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7C tzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+UmVtb3ZhbCBvZiB0aGUgdXNlIGNhc2Ugb24gcmUtZGVsZWdh dGlvbi4gKFRoZSBjYXNlIGlzIHRvbyBmYXIgZnJvbSB0aGUgcHJlc2VudCBPQXV0aCAyLjApPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkNsYXJpZmljYXRpb24g b2YgdGhlIHVzZSBjYXNlIERldmljZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5BZGRpdGlvbiBvZiBhIG5vdGUgZm9yIGVhY2ggdXNlIGNhc2UgdGhhdCBpbmRp Y2F0ZXMgd2hldGhlciB0aGUgdXNlIGNhc2Ugc3VwcG9ydGVkIGJ5IE9BdXRoIDIuMA0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp bjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlVwZGF0ZSBvZiB0aGUgcmVm ZXJlbmNlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JbmNs dXNpb24gb2YgdGhlIHJlZmVyZW5jZXMgdG8gdGhlIFdHIHNlY3VyaXR5IGRvY3VtZW50cyBpbiB0 aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBzZWN0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+WW91ciBjb21tZW50cyBhcmUgd2VsY29t ZWQuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGFydGljdWxhcmx5 LCB0aGUgYXV0aG9ycyBhcmUgbG9va2luZyBmb3IgYWR2aWNlIHdpdGggdGhlIHVzZSBvZiB0aGUg ZXhhbXBsZSBVUkxzLiBGb2xsb3dpbmcgdGhlIGd1aWRhbmNlIG9mIFJGQyAyNjA2LDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+d2UgaGF2ZSB1c2VkIOKAnGV4YW1wbGXi gJ0gYXMgdGhlIHRvcCBsZXZlbCBkb21haW4gbmFtZSAoZS5nLiwgZXhhbXBsZS5jb20pLiBUaGlz IG1heSBtaXNsZWFkIHJlYWRlcnMgaW50byB0aGlua2luZyB0aGF0IGFsbCBVUkxzIGJlbG9uZyB0 byB0aGUgc2FtZSBvcmdhbml6YXRpb24uIEEgZ2VuZXJhbCBub3RlLCBzdGF0aW5nIHRoYXQgYWxs IHNpdGVzIGVuZGluZyB3aXRoIOKAnGV4YW1wbGUuY29t4oCdIGRvIG5vdCBuZWNlc3NhcmlseQ0K IGJlbG9uZyB0byB0aGUgc2FtZSBvcmdhbml6YXRpb24sIGlzIG5vdCBzdWZmaWNpZW50IChhY2Nv cmRpbmcgdG8gc29tZSByZWFkZXJzKS4gSG93IHRvIGF2b2lkIHRoZSBjb25mdXNpb24/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlphY2hhcnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSA8 YnI+DQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIwMTIgMTE6NDYgQU08YnI+DQpUbzog WmVsdHNhbiwgWmFjaGFyeSAoWmFjaGFyeSk8YnI+DQpDYzogdG9yc3RlbkBsb2RkZXJzdGVkdC5u ZXQ7IGdmZmxldGNoQGFvbC5jb208YnI+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAyLnR4dDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLW9hdXRoLXVzZS1jYXNlcy0wMi50 eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgWmFjaGFyeSBaZWx0c2FuIGFuZCBwb3N0ZWQgdG8gdGhlPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JRVRGIHJlcG9zaXRvcnkuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkZpbGVuYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1pZXRmLW9hdXRoLXVzZS1jYXNlczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAyPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaXRsZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgT0F1dGggVXNlIENhc2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5DcmVhdGlvbiBkYXRlOiAyMDEyLTEwLTEwPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij5XRyBJRDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2F1dGg8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPk51bWJlciBvZiBwYWdlczogMjQ8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlVSTDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC11c2UtY2Fz ZXMtMDIudHh0Ij4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtb2F1dGgtdXNlLWNhc2VzLTAyLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlN0YXR1czombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLW9hdXRoLXVzZS1jYXNlcyI+DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAyIj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+RGlmZjombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vYXV0aC11c2UtY2FzZXMtMDIiPg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vYXV0aC11c2UtY2FzZXMtMDI8L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9jdW1lbnQgbGlzdHMg dGhlIE9BdXRoIHVzZSBjYXNlcy4mbmJzcDsgVGhlIHByb3ZpZGVkIGxpc3QgaXMgYmFzZWQ8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBvbiB0aGUg SW50ZXJuZXQgRHJhZnRzIG9mIHRoZSBPQVVUSCB3b3JraW5nIGdyb3VwIGFuZCBkaXNjdXNzaW9u cyBvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 IHRoZSBncm91cCdzIG1haWxpbmcgbGlzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBJ RVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F5B2863BFA782C4E8866941363AE88E8C6B890US70TWXCHMBA09zam_-- From Michael.Jones@microsoft.com Wed Oct 10 09:36:50 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1208D21F8607 for ; Wed, 10 Oct 2012 09:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.286 X-Spam-Level: X-Spam-Status: No, score=-3.286 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsAgVbHVIh5b for ; Wed, 10 Oct 2012 09:36:49 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id C4C0D21F8606 for ; Wed, 10 Oct 2012 09:36:48 -0700 (PDT) Received: from BL2FFO11FD001.protection.gbl (10.173.161.200) by BL2FFO11HUB022.protection.gbl (10.173.161.46) with Microsoft SMTP Server (TLS) id 15.0.516.0; Wed, 10 Oct 2012 16:37:49 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.21) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Wed, 10 Oct 2012 16:37:49 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.129]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Wed, 10 Oct 2012 16:36:35 +0000 From: Mike Jones To: "Zeltsan, Zachary (Zachary)" , "'oauth@ietf.org WG'" Thread-Topic: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt Thread-Index: AQHNpv5xJEF7Wxnzw0GCnFwqwEoZMpeyru/AgAAM1AA= Date: Wed, 10 Oct 2012 16:36:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436682D1E3@TK5EX14MBXC284.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436682D1E3TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(13464001)(5343645001)(74502001)(3846001)(8716001)(306001)(16826001)(5343655001)(74662001)(20776001)(46102001)(5343635001)(16696001)(51856001)(4396001)(4196001)(47446002)(49866001)(47976001)(2666001)(1076001)(47736001)(31966008)(512874001)(15202345001)(44976002)(16406001)(50986001)(33656001)(42186003)(316001)(3556001)(550254004)(3746001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0630013541 Subject: Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:36:50 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436682D1E3TK5EX14MBXC284r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGNhbiB1c2UgZXhhbXBsZS5jb20sIGV4YW1wbGUub3JnLCBhbmQgZXhhbXBsZS5uZXQsIGlm IHlvdSB0aGluayB0aGF0IHdvdWxkIGhlbHAuICBXZSBkbyB0aGF0IGluIHRoZSBPcGVuSUQgQ29u bmVjdCBzcGVjaWZpY2F0aW9ucy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBvYXV0aC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFpl bHRzYW4sIFphY2hhcnkgKFphY2hhcnkpDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIw MTIgOTozMCBBTQ0KVG86ICdvYXV0aEBpZXRmLm9yZyBXRycNClN1YmplY3Q6IFtPQVVUSC1XR10g Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1vYXV0aC11c2UtY2Fz ZXMtMDIudHh0DQoNCg0KT24gYmVoYWxmIG9mIHRoZSBjby1hdXRob3JzIEkgaGF2ZSBwb3N0ZWQg dGhlIGRyYWZ0Lg0KDQpUaGUgbWFpbiBjaGFuZ2VzIGluIHRoZSAtMDIgdmVyc2lvbiBhcmUgdGhl IGZvbGxvd2luZzoNCg0KDQoNCsK3ICAgICAgICBSZW1vdmFsIG9mIHRoZSB1c2UgY2FzZSBvbiBy ZS1kZWxlZ2F0aW9uLiAoVGhlIGNhc2UgaXMgdG9vIGZhciBmcm9tIHRoZSBwcmVzZW50IE9BdXRo IDIuMCkNCg0KwrcgICAgICAgIENsYXJpZmljYXRpb24gb2YgdGhlIHVzZSBjYXNlIERldmljZQ0K DQrCtyAgICAgICAgQWRkaXRpb24gb2YgYSBub3RlIGZvciBlYWNoIHVzZSBjYXNlIHRoYXQgaW5k aWNhdGVzIHdoZXRoZXIgdGhlIHVzZSBjYXNlIHN1cHBvcnRlZCBieSBPQXV0aCAyLjANCg0Kwrcg ICAgICAgIFVwZGF0ZSBvZiB0aGUgcmVmZXJlbmNlcw0KDQrCtyAgICAgICAgSW5jbHVzaW9uIG9m IHRoZSByZWZlcmVuY2VzIHRvIHRoZSBXRyBzZWN1cml0eSBkb2N1bWVudHMgaW4gdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb24gc2VjdGlvbg0KDQoNCg0KWW91ciBjb21tZW50cyBhcmUgd2VsY29t ZWQuDQoNClBhcnRpY3VsYXJseSwgdGhlIGF1dGhvcnMgYXJlIGxvb2tpbmcgZm9yIGFkdmljZSB3 aXRoIHRoZSB1c2Ugb2YgdGhlIGV4YW1wbGUgVVJMcy4gRm9sbG93aW5nIHRoZSBndWlkYW5jZSBv ZiBSRkMgMjYwNiwNCg0Kd2UgaGF2ZSB1c2VkIOKAnGV4YW1wbGXigJ0gYXMgdGhlIHRvcCBsZXZl bCBkb21haW4gbmFtZSAoZS5nLiwgZXhhbXBsZS5jb20pLiBUaGlzIG1heSBtaXNsZWFkIHJlYWRl cnMgaW50byB0aGlua2luZyB0aGF0IGFsbCBVUkxzIGJlbG9uZyB0byB0aGUgc2FtZSBvcmdhbml6 YXRpb24uIEEgZ2VuZXJhbCBub3RlLCBzdGF0aW5nIHRoYXQgYWxsIHNpdGVzIGVuZGluZyB3aXRo IOKAnGV4YW1wbGUuY29t4oCdIGRvIG5vdCBuZWNlc3NhcmlseSBiZWxvbmcgdG8gdGhlIHNhbWUg b3JnYW5pemF0aW9uLCBpcyBub3Qgc3VmZmljaWVudCAoYWNjb3JkaW5nIHRvIHNvbWUgcmVhZGVy cykuIEhvdyB0byBhdm9pZCB0aGUgY29uZnVzaW9uPw0KDQoNCg0KWmFjaGFyeQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnXTxtYWlsdG86W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddPg0KU2VudDogV2Vk bmVzZGF5LCBPY3RvYmVyIDEwLCAyMDEyIDExOjQ2IEFNDQpUbzogWmVsdHNhbiwgWmFjaGFyeSAo WmFjaGFyeSkNCkNjOiB0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldDxtYWlsdG86dG9yc3RlbkBsb2Rk ZXJzdGVkdC5uZXQ+OyBnZmZsZXRjaEBhb2wuY29tPG1haWx0bzpnZmZsZXRjaEBhb2wuY29tPg0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLW9hdXRoLXVz ZS1jYXNlcy0wMi50eHQNCg0KDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0 Zi1vYXV0aC11c2UtY2FzZXMtMDIudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgWmFjaGFyeSBaZWx0c2FuIGFuZCBwb3N0ZWQgdG8gdGhlDQoNCklFVEYgcmVwb3NpdG9y eS4NCg0KDQoNCkZpbGVuYW1lOiAgICAgICAgZHJhZnQtaWV0Zi1vYXV0aC11c2UtY2FzZXMNCg0K UmV2aXNpb246ICAgICAgICAgIDAyDQoNClRpdGxlOiAgICAgICAgICAgICAgIE9BdXRoIFVzZSBD YXNlcw0KDQpDcmVhdGlvbiBkYXRlOiAyMDEyLTEwLTEwDQoNCldHIElEOiAgICAgICAgICAgICBv YXV0aA0KDQpOdW1iZXIgb2YgcGFnZXM6IDI0DQoNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0aC11c2UtY2FzZXMtMDIu dHh0DQoNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLW9hdXRoLXVzZS1jYXNlcw0KDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAyDQoNCkRpZmY6ICAg ICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vYXV0 aC11c2UtY2FzZXMtMDINCg0KDQoNCkFic3RyYWN0Og0KDQogICBUaGlzIGRvY3VtZW50IGxpc3Rz IHRoZSBPQXV0aCB1c2UgY2FzZXMuICBUaGUgcHJvdmlkZWQgbGlzdCBpcyBiYXNlZA0KDQogICBv biB0aGUgSW50ZXJuZXQgRHJhZnRzIG9mIHRoZSBPQVVUSCB3b3JraW5nIGdyb3VwIGFuZCBkaXNj dXNzaW9ucyBvbg0KDQogICB0aGUgZ3JvdXAncyBtYWlsaW5nIGxpc3QuDQoNCg0KDQoNCg0KDQoN Cg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== --_000_4E1F6AAD24975D4BA5B16804296739436682D1E3TK5EX14MBXC284r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQgTVMiOw0KCXBhbm9zZS0xOjIgMTEg NiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1Bs YWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQt ZmFtaWx5OiJUcmVidWNoZXQgTVMiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFp biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRyZWJ1Y2hldCBNUyIsInNhbnMtc2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTU3OTYyOTA4NjsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4NDA5ODc1 ODQgLTYxMjE5MjI2MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5Zb3UgY2FuIHVzZSBleGFtcGxlLmNvbSwgZXhhbXBsZS5vcmcsIGFu ZCBleGFtcGxlLm5ldCwgaWYgeW91IHRoaW5rIHRoYXQgd291bGQgaGVscC4mbmJzcDsgV2UgZG8g dGhhdCBpbiB0aGUgT3BlbklEIENvbm5lY3Qgc3BlY2lmaWNhdGlvbnMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG9hdXRoLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5aZWx0c2FuLCBaYWNoYXJ5IChaYWNoYXJ5KTxicj4NCjxiPlNlbnQ6PC9iPiBX ZWRuZXNkYXksIE9jdG9iZXIgMTAsIDIwMTIgOTozMCBBTTxicj4NCjxiPlRvOjwvYj4gJ29hdXRo QGlldGYub3JnIFdHJzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAyLnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk9uIGJlaGFs ZiBvZiB0aGUgY28tYXV0aG9ycyBJIGhhdmUgcG9zdGVkIHRoZSBkcmFmdC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBtYWluIGNoYW5nZXMgaW4gdGhlIC0wMiB2 ZXJzaW9uIGFyZSB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlJl bW92YWwgb2YgdGhlIHVzZSBjYXNlIG9uIHJlLWRlbGVnYXRpb24uIChUaGUgY2FzZSBpcyB0b28g ZmFyIGZyb20gdGhlIHByZXNlbnQgT0F1dGggMi4wKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT5DbGFyaWZpY2F0aW9uIG9mIHRoZSB1c2UgY2FzZSBEZXZpY2U8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QWRkaXRpb24gb2YgYSBub3RlIGZvciBl YWNoIHVzZSBjYXNlIHRoYXQgaW5kaWNhdGVzIHdoZXRoZXIgdGhlIHVzZSBjYXNlIHN1cHBvcnRl ZCBieSBPQXV0aCAyLjANCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxl dmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5V cGRhdGUgb2YgdGhlIHJlZmVyZW5jZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+SW5jbHVzaW9uIG9mIHRoZSByZWZlcmVuY2VzIHRvIHRoZSBXRyBzZWN1cml0eSBkb2N1 bWVudHMgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb24gc2VjdGlvbjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPllvdXIgY29tbWVudHMg YXJlIHdlbGNvbWVkLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBh cnRpY3VsYXJseSwgdGhlIGF1dGhvcnMgYXJlIGxvb2tpbmcgZm9yIGFkdmljZSB3aXRoIHRoZSB1 c2Ugb2YgdGhlIGV4YW1wbGUgVVJMcy4gRm9sbG93aW5nIHRoZSBndWlkYW5jZSBvZiBSRkMgMjYw Niw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPndlIGhhdmUgdXNlZCDi gJxleGFtcGxl4oCdIGFzIHRoZSB0b3AgbGV2ZWwgZG9tYWluIG5hbWUgKGUuZy4sIGV4YW1wbGUu Y29tKS4gVGhpcyBtYXkgbWlzbGVhZCByZWFkZXJzIGludG8gdGhpbmtpbmcgdGhhdCBhbGwgVVJM cyBiZWxvbmcgdG8gdGhlIHNhbWUgb3JnYW5pemF0aW9uLiBBIGdlbmVyYWwgbm90ZSwgc3RhdGlu ZyB0aGF0IGFsbCBzaXRlcyBlbmRpbmcgd2l0aCDigJxleGFtcGxlLmNvbeKAnSBkbyBub3QgbmVj ZXNzYXJpbHkNCiBiZWxvbmcgdG8gdGhlIHNhbWUgb3JnYW5pemF0aW9uLCBpcyBub3Qgc3VmZmlj aWVudCAoYWNjb3JkaW5nIHRvIHNvbWUgcmVhZGVycykuIEhvdyB0byBhdm9pZCB0aGUgY29uZnVz aW9uPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5aYWNoYXJ5PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IDxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXSI+DQpbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ108L2E+IDxi cj4NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMCwgMjAxMiAxMTo0NiBBTTxicj4NClRvOiBa ZWx0c2FuLCBaYWNoYXJ5IChaYWNoYXJ5KTxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86dG9yc3Rl bkBsb2RkZXJzdGVkdC5uZXQiPnRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PC9hPjsgPGEgaHJlZj0i bWFpbHRvOmdmZmxldGNoQGFvbC5jb20iPg0KZ2ZmbGV0Y2hAYW9sLmNvbTwvYT48YnI+DQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtb2F1dGgtdXNlLWNh c2VzLTAyLnR4dDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1pZXRmLW9hdXRoLXVzZS1jYXNlcy0wMi50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWmFjaGFyeSBa ZWx0c2FuIGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5JRVRGIHJlcG9zaXRvcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkZp bGVuYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmFmdC1p ZXRmLW9hdXRoLXVzZS1jYXNlczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+UmV2aXNpb246Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDAyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaXRs ZTombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT0F1dGggVXNlIENhc2VzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DcmVhdGlvbiBkYXRlOiAyMDEyLTEwLTEwPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XRyBJRDombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgb2F1dGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk51bWJlciBv ZiBwYWdlczogMjQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlVSTDom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1vYXV0aC11c2UtY2FzZXMtMDIudHh0Ij4NCmh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAyLnR4dDwvYT48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlN0YXR1czombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLXVzZS1jYXNlcyI+ DQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtdXNlLWNh c2VzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SHRtbGl6ZWQ6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAyIj4NCmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdXNlLWNhc2VzLTAyPC9h PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+RGlmZjombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1vYXV0 aC11c2UtY2FzZXMtMDIiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1vYXV0aC11c2UtY2FzZXMtMDI8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7 Jm5ic3A7IFRoaXMgZG9jdW1lbnQgbGlzdHMgdGhlIE9BdXRoIHVzZSBjYXNlcy4mbmJzcDsgVGhl IHByb3ZpZGVkIGxpc3QgaXMgYmFzZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOyZuYnNwOyBvbiB0aGUgSW50ZXJuZXQgRHJhZnRzIG9mIHRoZSBPQVVUSCB3 b3JraW5nIGdyb3VwIGFuZCBkaXNjdXNzaW9ucyBvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHRoZSBncm91cCdzIG1haWxpbmcgbGlzdC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBJRVRGIFNlY3JldGFyaWF0PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B16804296739436682D1E3TK5EX14MBXC284r_-- From barryleiba.mailing.lists@gmail.com Wed Oct 10 09:46:02 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CC121F8697 for ; Wed, 10 Oct 2012 09:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWVAj3yngLDz for ; Wed, 10 Oct 2012 09:46:02 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE8B321F8686 for ; Wed, 10 Oct 2012 09:46:01 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so675786lbo.31 for ; Wed, 10 Oct 2012 09:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=y52MRyCLxNBb24nRpQd30VbEcIx/uLOyN8LmiJj+7vw=; b=W5eBj2WgH5JuNNQ9NMKXHCyLqBD5etD2NXqte4L2IAfXJ0Z12udKlAhsp6wYvUmn6P yRx3/P7J4uIdYIlKQKjmYKsu7W1qIA1+egM/KNJbFdfpS5GWUmL+olOnQFCoLM9Bxv9p 4P2JLebzUXWmmgHtYerMqFgXht8TWkE15oeBpE56uS4X8ii+Cp3Wqwy30EmEn2m7ZSA4 E0aiOWqIxwAlyjIriT/AyvHsF44NGykw443HNxC+MifDhljRodcDhohczNM1CRQdngyk YgX5+PsLNKkwlUykC/1xUvrc0p0OxjfwrpvN4gh08+7wBUB3zwCyUUfgfAd+bIc2ixSe vCQA== MIME-Version: 1.0 Received: by 10.112.102.196 with SMTP id fq4mr9547411lbb.125.1349887560739; Wed, 10 Oct 2012 09:46:00 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.150.194 with HTTP; Wed, 10 Oct 2012 09:46:00 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Oct 2012 12:46:00 -0400 X-Google-Sender-Auth: _0fXpekt9JY2-CMVDjpnyNP6WYA Message-ID: From: Barry Leiba To: "Zeltsan, Zachary (Zachary)" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:46:02 -0000 > Particularly, the authors are looking for advice with the use of the exam= ple > URLs. Following the guidance of RFC 2606, > > we have used =93example=94 as the top level domain name (e.g., example.co= m). > This may mislead readers into thinking that all URLs belong to the same > organization. A general note, stating that all sites ending with > =93example.com=94 do not necessarily belong to the same organization, is = not > sufficient (according to some readers). How to avoid the confusion? You're not using it as the top level domain name. You're using it as the second level domain name. See below. As Mike says, you can use .net and .org as well as .com. You can also use "example" truly as the top level domain (TLD). You can use "company1.example" and "company2.example" and "big-university.example", and so on. Barry From zachary.zeltsan@alcatel-lucent.com Wed Oct 10 09:57:15 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0560321F8715 for ; Wed, 10 Oct 2012 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx3juTG8ll4j for ; Wed, 10 Oct 2012 09:57:14 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFAA21F8712 for ; Wed, 10 Oct 2012 09:57:13 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9AGussT011272 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Oct 2012 18:57:00 +0200 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 10 Oct 2012 18:56:59 +0200 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.198]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Wed, 10 Oct 2012 12:56:56 -0400 From: "Zeltsan, Zachary (Zachary)" To: "'Barry Leiba'" , "'Mike Jones'" Thread-Topic: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt Thread-Index: AQHNpv5xJEF7Wxnzw0GCnFwqwEoZMpeyru/AgABTlgD//75lgA== Date: Wed, 10 Oct 2012 16:56:56 +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: [135.5.27.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "'oauth@ietf.org WG'" Subject: Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-use-cases-02.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 16:57:15 -0000 Thank you, Barry and Mike: I will make changes for the next version. Zachary -----Original Message----- From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@g= mail.com] On Behalf Of Barry Leiba Sent: Wednesday, October 10, 2012 12:46 PM To: Zeltsan, Zachary (Zachary) Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] FW: New Version Notification for draft-ietf-oauth-u= se-cases-02.txt > Particularly, the authors are looking for advice with the use of the exam= ple > URLs. Following the guidance of RFC 2606, > > we have used "example" as the top level domain name (e.g., example.com). > This may mislead readers into thinking that all URLs belong to the same > organization. A general note, stating that all sites ending with > "example.com" do not necessarily belong to the same organization, is not > sufficient (according to some readers). How to avoid the confusion? You're not using it as the top level domain name. You're using it as the second level domain name. See below. As Mike says, you can use .net and .org as well as .com. You can also use "example" truly as the top level domain (TLD). You can use "company1.example" and "company2.example" and "big-university.example", and so on. Barry From hardjono@mit.edu Wed Oct 10 13:10:15 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECCE21F859F for ; Wed, 10 Oct 2012 13:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8vdoxTsS92E for ; Wed, 10 Oct 2012 13:10:14 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 979F521F8582 for ; Wed, 10 Oct 2012 13:10:09 -0700 (PDT) X-AuditID: 1209190d-b7f906d0000008de-3b-5075d620e23a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 68.5B.02270.026D5705; Wed, 10 Oct 2012 16:10:08 -0400 (EDT) Received: from outgoing-exchange-2.mit.edu (OUTGOING-EXCHANGE-2.MIT.EDU [18.9.28.16]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q9AKA8iN026027; Wed, 10 Oct 2012 16:10:08 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (OC11EXEDGE4.EXCHANGE.MIT.EDU [18.9.3.27]) by outgoing-exchange-2.mit.edu (8.13.8/8.12.4) with ESMTP id q9AKA7EF029925; Wed, 10 Oct 2012 16:10:07 -0400 Received: from W92EXHUB15.exchange.mit.edu (18.7.73.26) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 10 Oct 2012 16:09:19 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.236]) by W92EXHUB15.exchange.mit.edu ([18.7.73.26]) with mapi id 14.02.0309.002; Wed, 10 Oct 2012 16:10:07 -0400 From: Thomas Hardjono To: "'oauth@ietf.org WG'" Thread-Topic: UMA Webinar on Oct 17th Thread-Index: Ac2nIzuRiMzIER+hTVOdMxMD0+y0ow== Date: Wed, 10 Oct 2012 20:10:06 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A108CB081@OC11EXPO24.exchange.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [18.111.117.127] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHKsWRmVeSWpSXmKPExsUixCmqrKtwrTTA4Ps8HYulO++xWpx8+4rN gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYvf4Te8F5sYr+VbYNjOuFuxg5OSQETCQe HHzMBGGLSVy4t56ti5GLQ0hgH6PE7xV7WSGcA4wSi3q2MEI4VxkldjY8YYdwtjNKvDr1Eqpn NaPE3rf7WUCGsQloSJz7vZcdxBYR0JJofnGWuYuRg4NZIFDi6OU8kLCwgILE+gOHmCFKVCVe t0yDKteT2Pf7ElicBSh+++4eMJtXIEhiRetBMJsR6Nbvp9aA3c0sIC5x68l8qB8EJRbNhqgH +effrodsIGslBJQknt4qgyjXkViw+xMbhK0tsWzha6jxghInZz5hmcAoPgvJ1FlIWmYhaZmF pGUBI8sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwSvdSU0k2M4EiT5N3B+O6g0iFGAQ5G JR7eHztLA4RYE8uKK3MPMUpyMCmJ8jZcBArxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4eU7DZTj TUmsrEotyodJSXOwKInzXkm56S8kkJ5YkpqdmlqQWgSTleHgUJLgbbsK1ChYlJqeWpGWmVOC kGbi4AQZzgM0/OsVkOHFBYm5xZnpEPlTjMYce//OfcjIsf3FwoeMQix5+XmpUuK81SDjBEBK M0rz4KbBkuUrRnGg54R5rUGqeICJFm7eK6BVTECrZCaVgKwqSURISTUw2qnN6H2wfnGqxu76 yynv66pFnHhUD3gk1SRvajcS+Cw15aDNfvYPdTym2xhmOG/g7Y3ekGO+kula0gQzz+q/1cYH OrbZHu+61/Yso3Fm7UTPgFom5f0H1h2pVdsc9OtT963qpImJOybZ2G3zP75W8+37yM+79609 xPjIrqtt+1pzgeUdxtE1SizFGYmGWsxFxYkAIRPInHEDAAA= Subject: [OAUTH-WG] UMA Webinar on Oct 17th X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 20:10:15 -0000 FYI folks, There will be a free webinar on UMA in Higher Education on October 17th 2012. Info below. /thomas/ ------------------------------------ Webinar on UMA and Higher Education on Wednesday, October 17 Our next webinar is scheduled for Oct 17 at 8am PT! The topic is UMA and Hi= gher Education. We'll show an extensive demo of how students can manage acc= ess by a variety of prospective employers to distributed, trusted informati= on about their educational achievements. Join us (details on our calendar),= and follow @UMAWG and hashtag #UMAedu for news. ------------------------------------------------------- Meeting information ------------------------------------------------------- Topic: Webinar: UMA and Higher Education #UMAedu Date: Wednesday, October 17, 2012 Time: 10:30 am, Eastern Daylight Time (New York, GMT-04:00) Meeting Number:= 252 418 084 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To start or join the online meeting ------------------------------------------------------- Go to https://ieeemeetings.webex.com/ieeemeetings/j.php?ED=3D191340043&UID= =3D498898617&RT=3DMiMxMQ%3D%3D ------------------------------------------------------- Teleconference information ------------------------------------------------------- Provide your phone number when you join the meeting to receive a call back.= Alternatively, you can call: Call-in toll-free number: 1-866-2030920 (US) Call-in number: 1-206-4450056= (US) Show global numbers: https://www.tcconline.com/offSite/OffSiteContro= ller.jpf?cc=3D5423695925 Leader PIN: 99171 Conference Code: 542 369 5925 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ieeemeetings.webex.com/ieeemeetings/mc 2. On the left navigation bar, click "Support". To update this meeting to your calendar program (for example Microsoft Outl= ook), click this link: https://ieeemeetings.webex.com/ieeemeetings/j.php?ED=3D191340043&UID=3D4988= 98617&ICS=3DMIU&LD=3D1&RD=3D2&ST=3D1&SHA2=3DKyYnWEkDkzKfKYJ3FDZUoQ8Cow2pBr8= UPws0/py9/R0=3D To check whether you have the appropriate players installed for UCF (Univer= sal Communications Format) rich media files, go to https://ieeemeetings.web= ex.com/ieeemeetings/systemdiagnosis.php http://www.webex.com CCM:+12064450056x99171# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. You should inform all meeting attendees prior to recording= if you intend to record the meeting. Please note that any such recordings = may be subject to discovery in the event of litigation. more details> copy to my calendar> From torsten@lodderstedt.net Wed Oct 10 14:07:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4663E21F854C for ; Wed, 10 Oct 2012 14:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weKcfzaCuOnL for ; Wed, 10 Oct 2012 14:07:08 -0700 (PDT) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.104]) by ietfa.amsl.com (Postfix) with ESMTP id 76C8821F8543 for ; Wed, 10 Oct 2012 14:07:08 -0700 (PDT) Received: from [79.253.28.173] (helo=[192.168.71.42]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TM3Ug-0003Ov-LH; Wed, 10 Oct 2012 23:07:06 +0200 Message-ID: <5075E379.7000502@lodderstedt.net> Date: Wed, 10 Oct 2012 23:07:05 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Pedro Felix References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020109030101040009070307" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Out-of-band code delivery and alternate redirect_uri schemes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 21:07:09 -0000 This is a multi-part message in MIME format. --------------020109030101040009070307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pedro, Am 10.10.2012 16:25, schrieb Pedro Felix: > 1) Out-of-band code transmission > > Currently Google OAuth2 implementation uses the special > "urn:ietf:wg:oauth:2.0:oob" to signal the Authorization Endpoint to > return an HTML page with the code, instead of a redirect. At first > sight, it seems a good idea, however it isn't in the OAuth 2 RFC. > a) What is the reason for the absence in the spec? > b) Is there any security problem associated with this usage? > > 2) Alternative "redirect_uri" schemes > > I'm also considering the use of alternative schemes on the > "redirect_uri". For instance, a client app could use the "mailto:" > scheme to instruct the Authorization Endpoint to send the code via > email. I know that a naive implementation can be subject to fixation > attacks, however > a) Weren't these scenarios considered by the working group? > b) Is there a major security flaw on this usage? What address should the authorization server send an e-mail to and how would the app acquire this code? regards, Torsten. > > Thanks > Pedro > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020109030101040009070307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Pedro,

Am 10.10.2012 16:25, schrieb Pedro Felix:
1) Out-of-band code transmission

Currently Google OAuth2 implementation uses the special "urn:ietf:wg:oauth:2.0:oob" to signal the Authorization Endpoint to return an HTML page with the code, instead of a redirect. At first sight, it seems a good idea, however it isn't in the OAuth 2 RFC. 
  a) What is the reason for the absence in the spec? 
  b) Is there any security problem associated with this usage?

2) Alternative "redirect_uri" schemes

I'm also considering the use of alternative schemes on the "redirect_uri". For instance, a client app could use the "mailto:" scheme to instruct the Authorization Endpoint to send the code via email. I know that a naive implementation can be subject to fixation attacks, however
  a) Weren't these scenarios considered by the working group? 
  b) Is there a major security flaw on this usage?

What address should the authorization server send an e-mail to and how would the app acquire this code?

regards,
Torsten.

Thanks
Pedro



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

--------------020109030101040009070307-- From eve@xmlgrrl.com Wed Oct 10 15:20:16 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BCE21F862A for ; Wed, 10 Oct 2012 15:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[AWL=-2.432, BAYES_40=-0.185, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVEdbCdQvjRZ for ; Wed, 10 Oct 2012 15:20:15 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4A11A21F8645 for ; Wed, 10 Oct 2012 15:20:15 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q9AMKDv3019605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Oct 2012 15:20:13 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_D0425988-02D4-422F-9761-1E94962EC6F3" From: Eve Maler In-Reply-To: Date: Wed, 10 Oct 2012 15:20:12 -0700 Message-Id: References: To: zhou.sujing@zte.com.cn X-Mailer: Apple Mail (2.1499) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 22:20:16 -0000 --Apple-Mail=_D0425988-02D4-422F-9761-1E94962EC6F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 There are a number of implicit actions happening here that ideally = should be accounted for. If Alice is the RO and Bob is operating the = client, then when Bob accesses the protected resource it may not just be = "on Alice's behalf" -- think of how people share calendar read/write = access with other people today. Those with delegated access act on their = own behalf, with the RO's permission. So the tuple represented by the = access token is actually quite a bit bigger than usual. Since OAuth makes a simplifying assumption that gets it entirely out of = this sort of business, the process of trying to shoehorn this use case = into a single plain OAuth flow may end badly. Better would be an = explicit recognition of the symmetry of Alice (with her user agent) on = one side, and bob with his client on the other side. Not to sound like a = broken record, but the UMA model takes this fully into account and has = even gone a fair way down the path of considering the contractual and = legal implications of such authorization. Since the client (along with its operator) has to register on the AS = side anyway, having a clean model where it can do that without the RO's = synchronous presence would be ideal. Otherwise I suspect it's = impractical in normal use.=20 Eve On 9 Oct 2012, at 6:49 PM, zhou.sujing@zte.com.cn wrote: >=20 > Hi=A3=ACPrabath=20 >=20 >=20 > Prabath Siriwardena > 2012-10-09 20:35 >=20 > =CA=D5=BC=FE=C8=CB > zhou.sujing@zte.com.cn > =B3=AD=CB=CD > Eve Maler , oauth@ietf.org, oauth-bounces@ietf.org > =D6=F7=CC=E2 > Re: Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Oct 8, 2012 at 6:24 PM, wrote:=20 >=20 > Hi=A3=AC Prabath=20 > =20 > My question is since client-id is public, then it is a waste to get = it by granting an access-token.=20 > And in step 2."Resource Owner grants access to a selected Client", RO = logins in to select clients to be delegated,=20 > and RS redirects RO to AS to grant access token to client, to my = understanding, in this process RO needs to authenticate to RS and then = authenticate=20 > to AS, it is a bit complicated.=20 >=20 > In fact I did not want to disturb normal OAuth flow.. BTW yes.. it = adds some overhead.. So - I would like to modify it - where the Resource = Server sends the resource_owner_initiated as the scope - and based on = the scope AS returns back client_id together with the access_token it = self.=20 > =20 >=20 > I wonder if the following two processes could satisfy your case:=20 >=20 > Process One:=20 > 1. Resource Owner registers to-be-delegated clients and corresponding = RSs at AS, i.e., a long term delegation contract is stored at AS=20 >=20 > 2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token=20 > 3. Client accesses the protected resource on behalf of the Resource = Owner.=20 >=20 > Process Two:=20 > 1. RO registers to-be-delegated clients at RS, i.e., a long term = delegation contract is stored at RS=20 > 2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token,AS may request RO = to authenticate and confirm the=20 > access-token request=20 > 3. Client accesses the protected resource on behalf of the Resource = Owner. =20 >=20 >=20 > There needs to be an step to facilitate client registration.=20 > Client could have registered at AS.=20 > RO just select clients from available clients list.=20 > This facilitating step still needed?=20 >=20 > Thanks & regards,=20 > -Prabath=20 > =20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_D0425988-02D4-422F-9761-1E94962EC6F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312

Since OAuth makes a simplifying = assumption that gets it entirely out of this sort of business, the = process of trying to shoehorn this use case into a single plain OAuth = flow may end badly. Better would be an explicit recognition of the = symmetry of Alice (with her user agent) on one side, and bob with his = client on the other side. Not to sound like a broken record, but the UMA = model takes this fully into account and has even gone a fair way down = the path of considering the contractual and legal implications of such = authorization.

Since the client (along with its = operator) has to register on the AS side anyway, having a clean model = where it can do that without the RO's synchronous presence would be = ideal. Otherwise I suspect it's impractical in normal = use. 

Eve

On 9 Oct = 2012, at 6:49 PM, zhou.sujing@zte.com.cn = wrote:


Hi=A3=ACPrabath


Prabath = Siriwardena <prabath@wso2.com>

2012-10-09 20:35

=CA=D5=BC=FE=C8=CB
zhou.sujing@zte.com.cn
=B3=AD=CB=CD
Eve Maler <eve@xmlgrrl.com>, oauth@ietf.org, oauth-bounces@ietf.org
=D6=F7=CC=E2
Re: Re: Re: Re: [OAUTH-WG] = Resource owner initiated OAuth delegation
On Mon, Oct 8, 2012 at 6:24 PM, = <zhou.sujing@zte.com.cn> wrote:

Hi=A3=AC Prabath
 
 My question is since client-id is public, then it is a waste to get it by granting an access-token.
 And in step 2."Resource Owner grants access to a selected = Client", RO  logins in to select clients to be delegated,
and RS redirects RO to AS to grant access token to client, to my = understanding, in this process RO needs to authenticate to RS and then authenticate =
to AS, it is a bit complicated.

In fact I did not want to = disturb normal OAuth flow.. BTW yes.. it adds some overhead.. So - I would like to = modify it - where the Resource Server sends the resource_owner_initiated as the scope - and based on the scope AS returns back client_id together with the access_token it self.
 

 I wonder if the following two processes could satisfy your case:

Process One:
1. Resource Owner registers to-be-delegated clients and corresponding = RSs at AS, i.e., a long term delegation contract is stored at AS

2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token
3. Client accesses the protected resource on behalf of the Resource = Owner.

Process Two:
1. RO registers to-be-delegated clients at RS, i.e., a long term = delegation contract is stored at RS
2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token,AS may request RO to = authenticate and confirm the
access-token request
3. Client accesses the protected resource on behalf of the Resource = Owner.  


There needs to be an step to = facilitate client registration.
Client could = have registered at AS.
RO just select = clients from available clients list.
This = facilitating step still needed?

Thanks & regards,
-Prabath
 


Eve Maler       =                     =        http://www.xmlgrrl.com/blog
+1= 425 345 6756                 =         http://www.twitter.com/xmlgrrl=


= --Apple-Mail=_D0425988-02D4-422F-9761-1E94962EC6F3-- From prabath@wso2.com Wed Oct 10 15:35:27 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD11721F86EA for ; Wed, 10 Oct 2012 15:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.073 X-Spam-Level: X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8NEgvpCHqR3 for ; Wed, 10 Oct 2012 15:35:26 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3484821F86E4 for ; Wed, 10 Oct 2012 15:35:25 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so1175033vbb.31 for ; Wed, 10 Oct 2012 15:35:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=/dF/g1it5sw1nPzcyHYFmrcvmCkkRCdF6FUUNo4XNX0=; b=b3DHD560PKBUg/Hl+0WvMPjF4By/CWQn8ydbqq5emA947lY6ZKWbhLVtuH5gdSq3kM BLxvPqZsOUfrgtQZcyehA9c2+ggjspcd41jM3JpBbIIoIetzZ4XhDOEWzimYtzHdaZTO DHFHsIv6G0C2JOb3IgO8nHOgPRcBOnVEEHraqCA2ILZRc+hbaTO419oCxbLgMW1GHWnI svoEnvf5jqsrxIbxZM+4AT+V5Ig/SS7BOTyW8ADyuloXe/LdfuDUq27OSPQhGCbExiMq KwJfuh06Zbf88aqI37m0jAzocaooFte4pHN2cWgWXnO8kMkBFV9ihoTDUIhiDziW6Xdx jxVg== MIME-Version: 1.0 Received: by 10.52.92.11 with SMTP id ci11mr11830749vdb.7.1349908525355; Wed, 10 Oct 2012 15:35:25 -0700 (PDT) Received: by 10.59.0.129 with HTTP; Wed, 10 Oct 2012 15:35:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Oct 2012 15:35:25 -0700 Message-ID: From: Prabath Siriwardena To: Eve Maler Content-Type: multipart/alternative; boundary=20cf3071ce0a22120d04cbbc1239 X-Gm-Message-State: ALoCoQli75B5A/LCn5OhiMydsWgxdq7fUQtcFAVFjfl0G0oXOU23i2RzrApue1cB0jLQ1vXWYQCj Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 22:35:27 -0000 --20cf3071ce0a22120d04cbbc1239 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Eve, I have gone through UMA spec but failed to find any case which covers this scenario - in a resource owner initiated manner.. Can you please give some pointers..? Thanks & regards, -Prabath On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler wrote: > There are a number of implicit actions happening here that ideally should > be accounted for. If Alice is the RO and Bob is operating the client, the= n > when Bob accesses the protected resource it may not just be "on Alice's > behalf" -- think of how people share calendar read/write access with othe= r > people today. Those with delegated access act on their own behalf, with t= he > RO's permission. So the tuple represented by the access token is actually > quite a bit bigger than usual. > > Since OAuth makes a simplifying assumption that gets it entirely out of > this sort of business, the process of trying to shoehorn this use case in= to > a single plain OAuth flow may end badly. Better would be an explicit > recognition of the symmetry of Alice (with her user agent) on one side, a= nd > bob with his client on the other side. Not to sound like a broken record, > but the UMA model takes this fully into account and has even gone a fair > way down the path of considering the contractual and legal implications o= f > such authorization. > > Since the client (along with its operator) has to register on the AS side > anyway, having a clean model where it can do that without the RO's > synchronous presence would be ideal. Otherwise I suspect it's impractical > in normal use. > > Eve > > On 9 Oct 2012, at 6:49 PM, zhou.sujing@zte.com.cn wrote: > > > Hi=A3=ACPrabath > > > *Prabath Siriwardena * > > 2012-10-09 20:35 > =CA=D5=BC=FE=C8=CB > zhou.sujing@zte.com.cn > =B3=AD=CB=CD > Eve Maler , oauth@ietf.org, oauth-bounces@ietf.org > =D6=F7=CC=E2 > Re: Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation > > > > > > > On Mon, Oct 8, 2012 at 6:24 PM, <*zhou.sujing@zte.com.cn*> > wrote: > > Hi=A3=AC Prabath > > My question is since client-id is public, then it is a waste to get it b= y > granting an access-token. > And in step 2."Resource Owner grants access to a selected Client", RO > logins in to select clients to be delegated, > and RS redirects RO to AS to grant access token to client, to my > understanding, in this process RO needs to authenticate to RS and then > authenticate > to AS, it is a bit complicated. > > In fact I did not want to disturb normal OAuth flow.. BTW yes.. it adds > some overhead.. So - I would like to modify it - where the Resource Serve= r > sends the resource_owner_initiated as the scope - and based on the scope = AS > returns back client_id together with the access_token it self. > > > I wonder if the following two processes could satisfy your case: > > Process One: > 1. Resource Owner registers to-be-delegated clients and corresponding RSs > at AS, i.e., a long term delegation contract is stored at AS > > 2. When Resource Owner requests Client to access its resource at RS, > Client is directed by RS to AS to obtain access-token > 3. Client accesses the protected resource on behalf of the Resource Owner= . > > Process Two: > 1. RO registers to-be-delegated clients at RS, i.e., a long term > delegation contract is stored at RS > 2. When Resource Owner requests Client to access its resource at RS, > Client is directed by RS to AS to obtain access-token,AS may request RO t= o > authenticate and confirm the > access-token request > 3. Client accesses the protected resource on behalf of the Resource Owner= . > > > > There needs to be an step to facilitate client registration. > Client could have registered at AS. > RO just select clients from available clients list. > This facilitating step still needed? > > Thanks & regards, > -Prabath > > > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > > --=20 Thanks & Regards, Prabath Mobile : +94 71 809 6732 http://blog.facilelogin.com http://RampartFAQ.com --20cf3071ce0a22120d04cbbc1239 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Eve,

I have gone through UMA spec but failed to find = any case which covers this scenario - in a resource owner initiated manner.= .

Can you please give some pointers..?

Thanks & regards,
-Prabath

On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler <eve@xmlgr= rl.com> wrote:
The= re are a number of implicit actions happening here that ideally should be a= ccounted for. If Alice is the RO and Bob is operating the client, then when= Bob accesses the protected resource it may not just be "on Alice'= s behalf" -- think of how people share calendar read/write access with= other people today. Those with delegated access act on their own behalf, w= ith the RO's permission. So the tuple represented by the access token i= s actually quite a bit bigger than usual.

Since OAuth makes a simplifying assumption that gets it= entirely out of this sort of business, the process of trying to shoehorn t= his use case into a single plain OAuth flow may end badly. Better would be = an explicit recognition of the symmetry of Alice (with her user agent) on o= ne side, and bob with his client on the other side. Not to sound like a bro= ken record, but the UMA model takes this fully into account and has even go= ne a fair way down the path of considering the contractual and legal implic= ations of such authorization.

Since the client (along with its operator) has to regis= ter on the AS side anyway, having a clean model where it can do that withou= t the RO's synchronous presence would be ideal. Otherwise I suspect it&= #39;s impractical in normal use. 

Eve

On 9 Oct 2012, at 6:49 PM, zhou.sujing@zte.com.cn wrote:


Hi=A3=ACPrabath


Prabath Siriwarde= na <prabath@wso2.c= om>

2012-10-09 20:35

=CA=D5=BC=FE=C8= =CB
zhou.sujing@zte.com.cn
=B3=AD=CB=CD
Eve Maler <eve@xmlgrrl.com>, oauth@ietf.org, oauth-bounces@i= etf.org
=D6=F7=CC=E2
Re: Re: Re: Re: [OAUTH-WG] Re= source owner initiated OAuth delegation
On Mon, Oct 8, 2012 at 6:24 PM, &l= t;zhou.sujing@zte.com.cn= > wrote:

Hi=A3=AC Prabath
 
 My question is since client-id is public, then it is a waste to get it by granting an access-token.
 And in step 2."Resource Owner grants access to a selected Clien= t", RO  logins in to select clients to be delegated,
and RS redirects RO to AS to grant access token to client, to my understan= ding, in this process RO needs to authenticate to RS and then authenticate
to AS, it is a bit complicated.

In fact I did not want to disturb = normal OAuth flow.. BTW yes.. it adds some overhead.. So - I would like to modify it - where the Resource Server sends the resource_owner_initiated as the scope - and based on the scope AS returns back client_id together with the access_token it self.
 

 I wonder if the following two processes could satisfy your case:

Process One:
1. Resource Owner registers to-be-delegated clients and corresponding RSs at AS, i.e., a long term delegation contract is stored at AS

2. When Resource Owner requests Client to access its resource at RS, Client is directed by RS to AS to obtain access-token
3. Client accesses the protected resource on behalf of the Resource Owner.

Process Two:
1. RO registers to-be-delegated clients at RS, i.e., a long term delegation contract is stored at RS
2. When Resource Owner requests Client to access its resource at RS, Client is directed by RS to AS to obtain access-token,AS may request RO to authent= icate and confirm the
access-token request
3. Client accesses the protected resource on behalf of the Resource Owner.  


There needs to be an step to facil= itate client registration.
Client could have registered at AS.
RO just select clients from available clients list.
This facilitating step still needed?

Thanks & regards,
-Prabath
 


Eve Maler                   &n= bsp;              http://www.xmlgrrl.com/blog
+1 425 345 6756               &nbs= p;         http://www.twitter.com/xmlgrrl




-- =
Thanks & Regards,
Prabath


--20cf3071ce0a22120d04cbbc1239-- From pmhsfelix@gmail.com Wed Oct 10 15:50:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4021F042A for ; Wed, 10 Oct 2012 15:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN7iwmA0bV3O for ; Wed, 10 Oct 2012 15:50:52 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 17BBE1F041F for ; Wed, 10 Oct 2012 15:50:51 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so1165639wib.13 for ; Wed, 10 Oct 2012 15:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=x+V1YYZ90vCwP7VQcj0cFWydKb1RaHzVTkNH2TKtMd8=; b=eVHsIxhREB7VdmMHctHdgfnOHOUd/xpq8mli8VYBzKB1HQie3NbuVq+qqRHFa3478l TYDFBdU0ITXmLPyioK/dK7/9yq8YtaA0ItHipZSUbErHacZlbhmC72JB2LHQ4YEkda5T c4P0bOPTnq/+vWZ6AHXGEw1ItO6vmc+XegqbLZHHzJO9r953NKFzsy3m6Fajob4ItTi+ HM50ZPkyThwXGs2WoXQSpJogx7hRNuAr5+jpKLGvCVl/7qb548k3ocRFmYz9Xv/3WVZS 0Q/75A/xnoWKVj3QRO6zbcP2XhqnjMlL2d/TPhTkAZz6a4Vm16I5CYg6Rr5ym6JAzLcG c1jw== Received: by 10.180.94.226 with SMTP id df2mr16163807wib.11.1349909451269; Wed, 10 Oct 2012 15:50:51 -0700 (PDT) Received: from [192.168.0.10] (a95-93-248-121.cpe.netcabo.pt. [95.93.248.121]) by mx.google.com with ESMTPS id gm7sm5264596wib.10.2012.10.10.15.50.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Oct 2012 15:50:49 -0700 (PDT) References: <5075E379.7000502@lodderstedt.net> In-Reply-To: <5075E379.7000502@lodderstedt.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-9AD31118-7383-4C68-BA85-13304F94E90B Message-Id: <106E8A07-FE5C-4BC9-B7C8-9EDAE0F9C53B@gmail.com> X-Mailer: iPhone Mail (9B176) From: Pedro Felix Date: Wed, 10 Oct 2012 23:50:47 +0100 To: Torsten Lodderstedt Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Out-of-band code delivery and alternate redirect_uri schemes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 22:50:53 -0000 --Apple-Mail-9AD31118-7383-4C68-BA85-13304F94E90B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Hi Pedro, >=20 > Am 10.10.2012 16:25, schrieb Pedro Felix: >> 1) Out-of-band code transmission >>=20 >> Currently Google OAuth2 implementation uses the special "urn:ietf:wg:oaut= h:2.0:oob" to signal the Authorization Endpoint to return an HTML page with t= he code, instead of a redirect. At first sight, it seems a good idea, howeve= r it isn't in the OAuth 2 RFC.=20 >> a) What is the reason for the absence in the spec?=20 >> b) Is there any security problem associated with this usage? >>=20 >> 2) Alternative "redirect_uri" schemes >>=20 >> I'm also considering the use of alternative schemes on the "redirect_uri"= . For instance, a client app could use the "mailto:" scheme to instruct the A= uthorization Endpoint to send the code via email. I know that a naive implem= entation can be subject to fixation attacks, however >> a) Weren't these scenarios considered by the working group?=20 >> b) Is there a major security flaw on this usage? >=20 > What address should the authorization server send an e-mail to and how wou= ld the app acquire this code? >=20 > regards, > Torsten. The email address would be in the redirect_uri; the code would be inserted i= nto the client app explicitly by the user, after receiving it. Thanks Pedro >>=20 >> Thanks >> Pedro >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-9AD31118-7383-4C68-BA85-13304F94E90B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8


Hi Pedro,

Am 10.10.2012 16:25, schrieb Pedro Felix:
1) Out-of-band code transmission

Currently Google OAuth2 implementation uses the special "urn:ietf:wg:oauth:2.0:oob" to signal the Authorization Endpoint to return an HTML page with the code, instead of a redirect. At first sight, it seems a good idea, however it isn't in the OAuth 2 RFC. 
  a) What is the reason for the absence in the spec? 
  b) Is there any security problem associated with this usage?

2) Alternative "redirect_uri" schemes

I'm also considering the use of alternative schemes on the "redirect_uri". For instance, a client app could use the "mailto:" scheme to instruct the Authorization Endpoint to send the code via email. I know that a naive implementation can be subject to fixation attacks, however
  a) Weren't these scenarios considered by the working group? 
  b) Is there a major security flaw on this usage?

What address should the authorization server send an e-mail to and how would the app acquire this code?

regards,
Torsten.
The email address would be in the redirect_uri; the code would be inserted into the client app explicitly by the user, after receiving it.

Thanks
Pedro


--Apple-Mail-9AD31118-7383-4C68-BA85-13304F94E90B-- From eve@xmlgrrl.com Wed Oct 10 15:54:54 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032B01F041F for ; Wed, 10 Oct 2012 15:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.743 X-Spam-Level: X-Spam-Status: No, score=0.743 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqmiPdMssIDX for ; Wed, 10 Oct 2012 15:54:52 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 83CE421F847F for ; Wed, 10 Oct 2012 15:54:52 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q9AMspn5020451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Oct 2012 15:54:51 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_04D9C70F-8F0B-4A26-A294-3974A0BB25DC" From: Eve Maler In-Reply-To: Date: Wed, 10 Oct 2012 15:54:51 -0700 Message-Id: References: To: Prabath Siriwardena X-Mailer: Apple Mail (2.1499) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 22:54:54 -0000 --Apple-Mail=_04D9C70F-8F0B-4A26-A294-3974A0BB25DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Sure. We'll ultimately be publishing some case studies that will = hopefully make this clearer, but the key place to start in the spec is = here: = http://docs.kantarainitiative.org/uma/draft-uma-core.html#r-h-attempt-acce= ss ".... The requester typically attempts to access the desired resource at = the host directly (for example, when a human operator of the requester = software clicks on a thumbnail representation of the resource). The = requester is expected to discover, or be provisioned or configured with, = knowledge of the protected resource and its location out of band. = Further, the requester is expected to acquire its own knowledge about = the application-specific methods made available by the host for = operating on this protected resource (such as viewing it with a GET = method, or transforming it with some complex API call) and the possible = scopes of access." So the requester can initiate the request, with the following = preconditions: - The host (RS) has registered this resource as protected with the = authorization manager (AS). - The requester (client)/requesting party has learned the location and = applicable API details of the resource out of band. The interactions among the host (RS), AM (AS), and requester (client -- = potentially operated by a third party who is not the RO) are protected = with various tokens. This is illustrated in the introduction with ASCII = art... http://docs.kantarainitiative.org/uma/draft-uma-core.html#introduction The actual protected resource requires a "requester permission token" = (RPT) associated with suitable authorization data. This is an = UMA-specific construct -- admittedly not a true OAuth flow, though = inspired by it! The AM presents a protection API to the host for = registering protected resources; the API is protected by a plain-vanilla = OAuth token called a protection API token (PAT). The AM also presents an = authorization API to the requester, which is protected by a = plain-vanilla OAuth token called an authorization API token (AAT). We're = counting on dynamic client registration to be in place wherever = deployers want true loose coupling. When the requester initiates a request, if it has no token at all, the = host directs it to the AM to get first an AAT (which conveys Bob's = authorization to use it and the AM in conveying identity claims to win = authorization), and ultimately an RPT (which convey's Alice's = authorization for Bob and this requester app to access the resource with = specific scopes). Of course we're talking about an UMA-enabled requester = here, but it can literally initiate an access request with zero tokens = and ultimately get somewhere. We'll be demoing this whole thing next Wednesday in the webinar, = including the dynamic client reg, the PAT, AAT, and RPT, the UX for the = various parties interacting with systems, and even interesting app-level = enhancements like notifying Alice that Bob has made an access attempt = and inviting her to set up policies that let him in. Eve On 10 Oct 2012, at 3:35 PM, Prabath Siriwardena = wrote: > Hi Eve, >=20 > I have gone through UMA spec but failed to find any case which covers = this scenario - in a resource owner initiated manner.. >=20 > Can you please give some pointers..? >=20 > Thanks & regards, > -Prabath >=20 > On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler wrote: > There are a number of implicit actions happening here that ideally = should be accounted for. If Alice is the RO and Bob is operating the = client, then when Bob accesses the protected resource it may not just be = "on Alice's behalf" -- think of how people share calendar read/write = access with other people today. Those with delegated access act on their = own behalf, with the RO's permission. So the tuple represented by the = access token is actually quite a bit bigger than usual. >=20 > Since OAuth makes a simplifying assumption that gets it entirely out = of this sort of business, the process of trying to shoehorn this use = case into a single plain OAuth flow may end badly. Better would be an = explicit recognition of the symmetry of Alice (with her user agent) on = one side, and bob with his client on the other side. Not to sound like a = broken record, but the UMA model takes this fully into account and has = even gone a fair way down the path of considering the contractual and = legal implications of such authorization. >=20 > Since the client (along with its operator) has to register on the AS = side anyway, having a clean model where it can do that without the RO's = synchronous presence would be ideal. Otherwise I suspect it's = impractical in normal use.=20 >=20 > Eve >=20 > On 9 Oct 2012, at 6:49 PM, zhou.sujing@zte.com.cn wrote: >=20 >>=20 >> Hi=A3=ACPrabath=20 >>=20 >>=20 >> Prabath Siriwardena >> 2012-10-09 20:35 >>=20 >> =CA=D5=BC=FE=C8=CB >> zhou.sujing@zte.com.cn >> =B3=AD=CB=CD >> Eve Maler , oauth@ietf.org, oauth-bounces@ietf.org >> =D6=F7=CC=E2 >> Re: Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mon, Oct 8, 2012 at 6:24 PM, wrote:=20 >>=20 >> Hi=A3=AC Prabath=20 >> =20 >> My question is since client-id is public, then it is a waste to get = it by granting an access-token.=20 >> And in step 2."Resource Owner grants access to a selected Client", = RO logins in to select clients to be delegated,=20 >> and RS redirects RO to AS to grant access token to client, to my = understanding, in this process RO needs to authenticate to RS and then = authenticate=20 >> to AS, it is a bit complicated.=20 >>=20 >> In fact I did not want to disturb normal OAuth flow.. BTW yes.. it = adds some overhead.. So - I would like to modify it - where the Resource = Server sends the resource_owner_initiated as the scope - and based on = the scope AS returns back client_id together with the access_token it = self.=20 >> =20 >>=20 >> I wonder if the following two processes could satisfy your case:=20 >>=20 >> Process One:=20 >> 1. Resource Owner registers to-be-delegated clients and corresponding = RSs at AS, i.e., a long term delegation contract is stored at AS=20 >>=20 >> 2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token=20 >> 3. Client accesses the protected resource on behalf of the Resource = Owner.=20 >>=20 >> Process Two:=20 >> 1. RO registers to-be-delegated clients at RS, i.e., a long term = delegation contract is stored at RS=20 >> 2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token,AS may request RO = to authenticate and confirm the=20 >> access-token request=20 >> 3. Client accesses the protected resource on behalf of the Resource = Owner. =20 >>=20 >>=20 >> There needs to be an step to facilitate client registration.=20 >> Client could have registered at AS.=20 >> RO just select clients from available clients list.=20 >> This facilitating step still needed?=20 >>=20 >> Thanks & regards,=20 >> -Prabath=20 >> =20 >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 >=20 >=20 >=20 >=20 > --=20 > Thanks & Regards, > Prabath >=20 > Mobile : +94 71 809 6732=20 >=20 > http://blog.facilelogin.com > http://RampartFAQ.com >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_04D9C70F-8F0B-4A26-A294-3974A0BB25DC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 http://docs.kantarainitiative.org/uma/draft-uma-core.html#r-h-= attempt-access

".... The requester = typically attempts to access the desired resource at the host directly = (for example, when a human operator of the requester software clicks on = a thumbnail representation of the resource). The requester is = expected to discover, or be provisioned or configured with, knowledge of = the protected resource and its location out of band. Further, the = requester is expected to acquire its own knowledge about the = application-specific methods made available by the host for = operating on this protected resource (such as viewing it with a GET = method, or transforming it with some complex API call) and the possible = scopes of access."

So the requester can = initiate the request, with the following = preconditions:

- The host (RS) has registered = this resource as protected with the authorization manager = (AS).
- The requester (client)/requesting party has learned = the location and applicable API details of the resource out of = band.

The interactions among the host (RS), AM = (AS), and requester (client -- potentially operated by a third party who = is not the RO) are protected with various tokens. This is illustrated in = the introduction with ASCII art...


The actual protected resource requires a = "requester permission token" (RPT) associated with suitable = authorization data. This is an UMA-specific construct -- admittedly not = a true OAuth flow, though inspired by it! The AM presents a protection = API to the host for registering protected resources; the API is = protected by a plain-vanilla OAuth token called a protection API token = (PAT). The AM also presents an authorization API to the requester, which = is protected by a plain-vanilla OAuth token called an authorization API = token (AAT). We're counting on dynamic client registration to be in = place wherever deployers want true loose = coupling.

When the requester initiates a = request, if it has no token at all, the host directs it to the AM to get = first an AAT (which conveys Bob's authorization to use it and the AM in = conveying identity claims to win authorization), and ultimately an RPT = (which convey's Alice's authorization for Bob and this requester app to = access the resource with specific scopes). Of course we're talking about = an UMA-enabled requester here, but it can literally initiate an access = request with zero tokens and ultimately get = somewhere.

We'll be demoing this whole thing = next Wednesday in the webinar, including the dynamic client reg, the = PAT, AAT, and RPT, the UX for the various parties interacting with = systems, and even interesting app-level enhancements like notifying = Alice that Bob has made an access attempt and inviting her to set up = policies that let him in.

= Eve

On 10 Oct 2012, at 3:35 PM, Prabath = Siriwardena <prabath@wso2.com> = wrote:

Hi Eve,

I have gone through UMA spec = but failed to find any case which covers this scenario - in a resource = owner initiated manner..

Can you please give = some pointers..?

Thanks & = regards,
-Prabath

On = Wed, Oct 10, 2012 at 3:20 PM, Eve Maler <eve@xmlgrrl.com> wrote:
There are a number of implicit = actions happening here that ideally should be accounted for. If Alice is = the RO and Bob is operating the client, then when Bob accesses the = protected resource it may not just be "on Alice's behalf" -- think of = how people share calendar read/write access with other people today. = Those with delegated access act on their own behalf, with the RO's = permission. So the tuple represented by the access token is actually = quite a bit bigger than usual.

Since OAuth makes a simplifying assumption that gets = it entirely out of this sort of business, the process of trying to = shoehorn this use case into a single plain OAuth flow may end badly. = Better would be an explicit recognition of the symmetry of Alice (with = her user agent) on one side, and bob with his client on the other side. = Not to sound like a broken record, but the UMA model takes this fully = into account and has even gone a fair way down the path of considering = the contractual and legal implications of such authorization.

Since the client (along with its operator) has to = register on the AS side anyway, having a clean model where it can do = that without the RO's synchronous presence would be ideal. Otherwise I = suspect it's impractical in normal use. 

Eve

On 9 Oct 2012, at 6:49 PM, zhou.sujing@zte.com.cn wrote:


Hi=A3=ACPrabath


Prabath = Siriwardena <prabath@wso2.com>

2012-10-09 20:35

=CA=D5=BC=FE=C8=CB
zhou.sujing@zte.com.cn
=B3=AD=CB=CD
Eve Maler <eve@xmlgrrl.com>,= oauth@ietf.org, oauth-bounces@ietf.org
=D6=F7=CC=E2
Re: Re: Re: Re: [OAUTH-WG] = Resource owner initiated OAuth delegation
On Mon, Oct 8, 2012 at 6:24 PM, = <zhou.sujing@zte.com.cn> wrote:

Hi=A3=AC Prabath
 
 My question is since client-id is public, then it is a waste to get it by granting an access-token.
 And in step 2."Resource Owner grants access to a selected = Client", RO  logins in to select clients to be delegated,
and RS redirects RO to AS to grant access token to client, to my = understanding, in this process RO needs to authenticate to RS and then authenticate =
to AS, it is a bit complicated.

In fact I did not want to = disturb normal OAuth flow.. BTW yes.. it adds some overhead.. So - I would like to = modify it - where the Resource Server sends the resource_owner_initiated as the scope - and based on the scope AS returns back client_id together with the access_token it self.
 

 I wonder if the following two processes could satisfy your case:

Process One:
1. Resource Owner registers to-be-delegated clients and corresponding = RSs at AS, i.e., a long term delegation contract is stored at AS

2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token
3. Client accesses the protected resource on behalf of the Resource = Owner.

Process Two:
1. RO registers to-be-delegated clients at RS, i.e., a long term = delegation contract is stored at RS
2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token,AS may request RO to = authenticate and confirm the
access-token request
3. Client accesses the protected resource on behalf of the Resource = Owner.  


There needs to be an step to = facilitate client registration.
Client could have = registered at AS.
RO just select clients from available clients list.
This facilitating step = still needed?

Thanks & regards,
-Prabath
 


Eve Maler                   =                http://www.xmlgrrl.com/blog
+1 425 345 6756           =               http://www.twitter.com/xmlgrrl




--=
Thanks & Regards,
Prabath




Eve Maler       =                     =        http://www.xmlgrrl.com/blog
+1= 425 345 6756                 =         http://www.twitter.com/xmlgrrl=


= --Apple-Mail=_04D9C70F-8F0B-4A26-A294-3974A0BB25DC-- From zhou.sujing@zte.com.cn Wed Oct 10 17:41:06 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B7B11E80D5 for ; Wed, 10 Oct 2012 17:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.253 X-Spam-Level: X-Spam-Status: No, score=-96.253 tagged_above=-999 required=5 tests=[AWL=1.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHlZis3U5tYO for ; Wed, 10 Oct 2012 17:41:05 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4BB11E808D for ; Wed, 10 Oct 2012 17:41:04 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 3E2B412638C4 for ; Thu, 11 Oct 2012 08:41:42 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 87CEB4AFB03; Thu, 11 Oct 2012 08:37:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q9B0ewnj006785; Thu, 11 Oct 2012 08:40:58 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Eve Maler MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 11 Oct 2012 08:40:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-11 08:40:53, Serialize complete at 2012-10-11 08:40:53 Content-Type: multipart/alternative; boundary="=_alternative 0003D37F48257A94_=" X-MAIL: mse02.zte.com.cn q9B0ewnj006785 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 00:41:06 -0000 This is a multipart message in MIME format. --=_alternative 0003D37F48257A94_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIEV2ZSwNCiAgIFRoZSByZXF1ZXN0ZXIgeW91IGRlc2NyaWJlZCBjb3JyZXNwb25kcyB0byBD bGllbnQgaW4gT0F1dGgsIHNvIGl0IGlzIA0Kc3RpbGwgY2xpZW50IGluaXRpYXRlZCBkZWxlZ2F0 aW9uLCBub3Qgd2hhdCBQcmFiYXRoIHdhbnRzLg0KDQoNCg0KDQpFdmUgTWFsZXIgPGV2ZUB4bWxn cnJsLmNvbT4gDQoyMDEyLTEwLTExIDA2OjU0DQoNCsrVvP7Iyw0KUHJhYmF0aCBTaXJpd2FyZGVu YSA8cHJhYmF0aEB3c28yLmNvbT4NCrOty80NCnpob3Uuc3VqaW5nQHp0ZS5jb20uY24sICJvYXV0 aEBpZXRmLm9yZyBXRyIgPG9hdXRoQGlldGYub3JnPg0K1vfM4g0KUmU6IFtPQVVUSC1XR10gUmVz b3VyY2Ugb3duZXIgaW5pdGlhdGVkIE9BdXRoIGRlbGVnYXRpb24NCg0KDQoNCg0KDQoNClN1cmUu IFdlJ2xsIHVsdGltYXRlbHkgYmUgcHVibGlzaGluZyBzb21lIGNhc2Ugc3R1ZGllcyB0aGF0IHdp bGwgaG9wZWZ1bGx5IA0KbWFrZSB0aGlzIGNsZWFyZXIsIGJ1dCB0aGUga2V5IHBsYWNlIHRvIHN0 YXJ0IGluIHRoZSBzcGVjIGlzIGhlcmU6DQoNCmh0dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZl Lm9yZy91bWEvZHJhZnQtdW1hLWNvcmUuaHRtbCNyLWgtYXR0ZW1wdC1hY2Nlc3MNCg0KIi4uLi4g VGhlIHJlcXVlc3RlciB0eXBpY2FsbHkgYXR0ZW1wdHMgdG8gYWNjZXNzIHRoZSBkZXNpcmVkIHJl c291cmNlIGF0IA0KdGhlIGhvc3QgZGlyZWN0bHkgKGZvciBleGFtcGxlLCB3aGVuIGEgaHVtYW4g b3BlcmF0b3Igb2YgdGhlIHJlcXVlc3RlciANCnNvZnR3YXJlIGNsaWNrcyBvbiBhIHRodW1ibmFp bCByZXByZXNlbnRhdGlvbiBvZiB0aGUgcmVzb3VyY2UpLiBUaGUgDQpyZXF1ZXN0ZXIgaXMgZXhw ZWN0ZWQgdG8gZGlzY292ZXIsIG9yIGJlIHByb3Zpc2lvbmVkIG9yIGNvbmZpZ3VyZWQgd2l0aCwg DQprbm93bGVkZ2Ugb2YgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBhbmQgaXRzIGxvY2F0aW9uIG91 dCBvZiBiYW5kLiBGdXJ0aGVyLCANCnRoZSByZXF1ZXN0ZXIgaXMgZXhwZWN0ZWQgdG8gYWNxdWly ZSBpdHMgb3duIGtub3dsZWRnZSBhYm91dCB0aGUgDQphcHBsaWNhdGlvbi1zcGVjaWZpYyBtZXRo b2RzIG1hZGUgYXZhaWxhYmxlIGJ5IHRoZSBob3N0IGZvciBvcGVyYXRpbmcgb24gDQp0aGlzIHBy b3RlY3RlZCByZXNvdXJjZSAoc3VjaCBhcyB2aWV3aW5nIGl0IHdpdGggYSBHRVQgbWV0aG9kLCBv ciANCnRyYW5zZm9ybWluZyBpdCB3aXRoIHNvbWUgY29tcGxleCBBUEkgY2FsbCkgYW5kIHRoZSBw b3NzaWJsZSBzY29wZXMgb2YgDQphY2Nlc3MuIg0KDQpTbyB0aGUgcmVxdWVzdGVyIGNhbiBpbml0 aWF0ZSB0aGUgcmVxdWVzdCwgd2l0aCB0aGUgZm9sbG93aW5nIA0KcHJlY29uZGl0aW9uczoNCg0K LSBUaGUgaG9zdCAoUlMpIGhhcyByZWdpc3RlcmVkIHRoaXMgcmVzb3VyY2UgYXMgcHJvdGVjdGVk IHdpdGggdGhlIA0KYXV0aG9yaXphdGlvbiBtYW5hZ2VyIChBUykuDQotIFRoZSByZXF1ZXN0ZXIg KGNsaWVudCkvcmVxdWVzdGluZyBwYXJ0eSBoYXMgbGVhcm5lZCB0aGUgbG9jYXRpb24gYW5kIA0K YXBwbGljYWJsZSBBUEkgZGV0YWlscyBvZiB0aGUgcmVzb3VyY2Ugb3V0IG9mIGJhbmQuDQoNClRo ZSBpbnRlcmFjdGlvbnMgYW1vbmcgdGhlIGhvc3QgKFJTKSwgQU0gKEFTKSwgYW5kIHJlcXVlc3Rl ciAoY2xpZW50IC0tIA0KcG90ZW50aWFsbHkgb3BlcmF0ZWQgYnkgYSB0aGlyZCBwYXJ0eSB3aG8g aXMgbm90IHRoZSBSTykgYXJlIHByb3RlY3RlZCANCndpdGggdmFyaW91cyB0b2tlbnMuIFRoaXMg aXMgaWxsdXN0cmF0ZWQgaW4gdGhlIGludHJvZHVjdGlvbiB3aXRoIEFTQ0lJIA0KYXJ0Li4uDQoN Cmh0dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLWNvcmUuaHRt bCNpbnRyb2R1Y3Rpb24NCg0KVGhlIGFjdHVhbCBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWlyZXMg YSAicmVxdWVzdGVyIHBlcm1pc3Npb24gdG9rZW4iIA0KKFJQVCkgYXNzb2NpYXRlZCB3aXRoIHN1 aXRhYmxlIGF1dGhvcml6YXRpb24gZGF0YS4gVGhpcyBpcyBhbiBVTUEtc3BlY2lmaWMgDQpjb25z dHJ1Y3QgLS0gYWRtaXR0ZWRseSBub3QgYSB0cnVlIE9BdXRoIGZsb3csIHRob3VnaCBpbnNwaXJl ZCBieSBpdCEgVGhlIA0KQU0gcHJlc2VudHMgYSBwcm90ZWN0aW9uIEFQSSB0byB0aGUgaG9zdCBm b3IgcmVnaXN0ZXJpbmcgcHJvdGVjdGVkIA0KcmVzb3VyY2VzOyB0aGUgQVBJIGlzIHByb3RlY3Rl ZCBieSBhIHBsYWluLXZhbmlsbGEgT0F1dGggdG9rZW4gY2FsbGVkIGEgDQpwcm90ZWN0aW9uIEFQ SSB0b2tlbiAoUEFUKS4gVGhlIEFNIGFsc28gcHJlc2VudHMgYW4gYXV0aG9yaXphdGlvbiBBUEkg dG8gDQp0aGUgcmVxdWVzdGVyLCB3aGljaCBpcyBwcm90ZWN0ZWQgYnkgYSBwbGFpbi12YW5pbGxh IE9BdXRoIHRva2VuIGNhbGxlZCBhbiANCmF1dGhvcml6YXRpb24gQVBJIHRva2VuIChBQVQpLiBX ZSdyZSBjb3VudGluZyBvbiBkeW5hbWljIGNsaWVudCANCnJlZ2lzdHJhdGlvbiB0byBiZSBpbiBw bGFjZSB3aGVyZXZlciBkZXBsb3llcnMgd2FudCB0cnVlIGxvb3NlIGNvdXBsaW5nLg0KDQpXaGVu IHRoZSByZXF1ZXN0ZXIgaW5pdGlhdGVzIGEgcmVxdWVzdCwgaWYgaXQgaGFzIG5vIHRva2VuIGF0 IGFsbCwgdGhlIA0KaG9zdCBkaXJlY3RzIGl0IHRvIHRoZSBBTSB0byBnZXQgZmlyc3QgYW4gQUFU ICh3aGljaCBjb252ZXlzIEJvYidzIA0KYXV0aG9yaXphdGlvbiB0byB1c2UgaXQgYW5kIHRoZSBB TSBpbiBjb252ZXlpbmcgaWRlbnRpdHkgY2xhaW1zIHRvIHdpbiANCmF1dGhvcml6YXRpb24pLCBh bmQgdWx0aW1hdGVseSBhbiBSUFQgKHdoaWNoIGNvbnZleSdzIEFsaWNlJ3MgDQphdXRob3JpemF0 aW9uIGZvciBCb2IgYW5kIHRoaXMgcmVxdWVzdGVyIGFwcCB0byBhY2Nlc3MgdGhlIHJlc291cmNl IHdpdGggDQpzcGVjaWZpYyBzY29wZXMpLiBPZiBjb3Vyc2Ugd2UncmUgdGFsa2luZyBhYm91dCBh biBVTUEtZW5hYmxlZCByZXF1ZXN0ZXIgDQpoZXJlLCBidXQgaXQgY2FuIGxpdGVyYWxseSBpbml0 aWF0ZSBhbiBhY2Nlc3MgcmVxdWVzdCB3aXRoIHplcm8gdG9rZW5zIGFuZCANCnVsdGltYXRlbHkg Z2V0IHNvbWV3aGVyZS4NCg0KV2UnbGwgYmUgZGVtb2luZyB0aGlzIHdob2xlIHRoaW5nIG5leHQg V2VkbmVzZGF5IGluIHRoZSB3ZWJpbmFyLCBpbmNsdWRpbmcgDQp0aGUgZHluYW1pYyBjbGllbnQg cmVnLCB0aGUgUEFULCBBQVQsIGFuZCBSUFQsIHRoZSBVWCBmb3IgdGhlIHZhcmlvdXMgDQpwYXJ0 aWVzIGludGVyYWN0aW5nIHdpdGggc3lzdGVtcywgYW5kIGV2ZW4gaW50ZXJlc3RpbmcgYXBwLWxl dmVsIA0KZW5oYW5jZW1lbnRzIGxpa2Ugbm90aWZ5aW5nIEFsaWNlIHRoYXQgQm9iIGhhcyBtYWRl IGFuIGFjY2VzcyBhdHRlbXB0IGFuZCANCmludml0aW5nIGhlciB0byBzZXQgdXAgcG9saWNpZXMg dGhhdCBsZXQgaGltIGluLg0KDQpFdmUNCg0KT24gMTAgT2N0IDIwMTIsIGF0IDM6MzUgUE0sIFBy YWJhdGggU2lyaXdhcmRlbmEgPHByYWJhdGhAd3NvMi5jb20+IHdyb3RlOg0KDQpIaSBFdmUsDQoN CkkgaGF2ZSBnb25lIHRocm91Z2ggVU1BIHNwZWMgYnV0IGZhaWxlZCB0byBmaW5kIGFueSBjYXNl IHdoaWNoIGNvdmVycyB0aGlzIA0Kc2NlbmFyaW8gLSBpbiBhIHJlc291cmNlIG93bmVyIGluaXRp YXRlZCBtYW5uZXIuLg0KDQpDYW4geW91IHBsZWFzZSBnaXZlIHNvbWUgcG9pbnRlcnMuLj8NCg0K VGhhbmtzICYgcmVnYXJkcywNCi1QcmFiYXRoDQoNCk9uIFdlZCwgT2N0IDEwLCAyMDEyIGF0IDM6 MjAgUE0sIEV2ZSBNYWxlciA8ZXZlQHhtbGdycmwuY29tPiB3cm90ZToNClRoZXJlIGFyZSBhIG51 bWJlciBvZiBpbXBsaWNpdCBhY3Rpb25zIGhhcHBlbmluZyBoZXJlIHRoYXQgaWRlYWxseSBzaG91 bGQgDQpiZSBhY2NvdW50ZWQgZm9yLiBJZiBBbGljZSBpcyB0aGUgUk8gYW5kIEJvYiBpcyBvcGVy YXRpbmcgdGhlIGNsaWVudCwgdGhlbiANCndoZW4gQm9iIGFjY2Vzc2VzIHRoZSBwcm90ZWN0ZWQg cmVzb3VyY2UgaXQgbWF5IG5vdCBqdXN0IGJlICJvbiBBbGljZSdzIA0KYmVoYWxmIiAtLSB0aGlu ayBvZiBob3cgcGVvcGxlIHNoYXJlIGNhbGVuZGFyIHJlYWQvd3JpdGUgYWNjZXNzIHdpdGggb3Ro ZXIgDQpwZW9wbGUgdG9kYXkuIFRob3NlIHdpdGggZGVsZWdhdGVkIGFjY2VzcyBhY3Qgb24gdGhl aXIgb3duIGJlaGFsZiwgd2l0aCANCnRoZSBSTydzIHBlcm1pc3Npb24uIFNvIHRoZSB0dXBsZSBy ZXByZXNlbnRlZCBieSB0aGUgYWNjZXNzIHRva2VuIGlzIA0KYWN0dWFsbHkgcXVpdGUgYSBiaXQg YmlnZ2VyIHRoYW4gdXN1YWwuDQoNClNpbmNlIE9BdXRoIG1ha2VzIGEgc2ltcGxpZnlpbmcgYXNz dW1wdGlvbiB0aGF0IGdldHMgaXQgZW50aXJlbHkgb3V0IG9mIA0KdGhpcyBzb3J0IG9mIGJ1c2lu ZXNzLCB0aGUgcHJvY2VzcyBvZiB0cnlpbmcgdG8gc2hvZWhvcm4gdGhpcyB1c2UgY2FzZSANCmlu dG8gYSBzaW5nbGUgcGxhaW4gT0F1dGggZmxvdyBtYXkgZW5kIGJhZGx5LiBCZXR0ZXIgd291bGQg YmUgYW4gZXhwbGljaXQgDQpyZWNvZ25pdGlvbiBvZiB0aGUgc3ltbWV0cnkgb2YgQWxpY2UgKHdp dGggaGVyIHVzZXIgYWdlbnQpIG9uIG9uZSBzaWRlLCANCmFuZCBib2Igd2l0aCBoaXMgY2xpZW50 IG9uIHRoZSBvdGhlciBzaWRlLiBOb3QgdG8gc291bmQgbGlrZSBhIGJyb2tlbiANCnJlY29yZCwg YnV0IHRoZSBVTUEgbW9kZWwgdGFrZXMgdGhpcyBmdWxseSBpbnRvIGFjY291bnQgYW5kIGhhcyBl dmVuIGdvbmUgDQphIGZhaXIgd2F5IGRvd24gdGhlIHBhdGggb2YgY29uc2lkZXJpbmcgdGhlIGNv bnRyYWN0dWFsIGFuZCBsZWdhbCANCmltcGxpY2F0aW9ucyBvZiBzdWNoIGF1dGhvcml6YXRpb24u DQoNClNpbmNlIHRoZSBjbGllbnQgKGFsb25nIHdpdGggaXRzIG9wZXJhdG9yKSBoYXMgdG8gcmVn aXN0ZXIgb24gdGhlIEFTIHNpZGUgDQphbnl3YXksIGhhdmluZyBhIGNsZWFuIG1vZGVsIHdoZXJl IGl0IGNhbiBkbyB0aGF0IHdpdGhvdXQgdGhlIFJPJ3MgDQpzeW5jaHJvbm91cyBwcmVzZW5jZSB3 b3VsZCBiZSBpZGVhbC4gT3RoZXJ3aXNlIEkgc3VzcGVjdCBpdCdzIGltcHJhY3RpY2FsIA0KaW4g bm9ybWFsIHVzZS4gDQoNCkV2ZQ0KDQpPbiA5IE9jdCAyMDEyLCBhdCA2OjQ5IFBNLCB6aG91LnN1 amluZ0B6dGUuY29tLmNuIHdyb3RlOg0KDQoNCkhpo6xQcmFiYXRoIA0KDQoNClByYWJhdGggU2ly aXdhcmRlbmEgPHByYWJhdGhAd3NvMi5jb20+IA0KMjAxMi0xMC0wOSAyMDozNSANCg0KDQrK1bz+ yMsNCnpob3Uuc3VqaW5nQHp0ZS5jb20uY24gDQqzrcvNDQpFdmUgTWFsZXIgPGV2ZUB4bWxncnJs LmNvbT4sIG9hdXRoQGlldGYub3JnLCBvYXV0aC1ib3VuY2VzQGlldGYub3JnIA0K1vfM4g0KUmU6 IFJlOiBSZTogUmU6IFtPQVVUSC1XR10gUmVzb3VyY2Ugb3duZXIgaW5pdGlhdGVkIE9BdXRoIGRl bGVnYXRpb24NCg0KDQoNCg0KDQoNCg0KDQoNCg0KT24gTW9uLCBPY3QgOCwgMjAxMiBhdCA2OjI0 IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbj4gd3JvdGU6IA0KDQpIaaOsIFByYWJhdGggDQog DQogTXkgcXVlc3Rpb24gaXMgc2luY2UgY2xpZW50LWlkIGlzIHB1YmxpYywgdGhlbiBpdCBpcyBh IHdhc3RlIHRvIGdldCBpdCBieSANCmdyYW50aW5nIGFuIGFjY2Vzcy10b2tlbi4gDQogQW5kIGlu IHN0ZXAgMi4iUmVzb3VyY2UgT3duZXIgZ3JhbnRzIGFjY2VzcyB0byBhIHNlbGVjdGVkIENsaWVu dCIsIFJPIA0KbG9naW5zIGluIHRvIHNlbGVjdCBjbGllbnRzIHRvIGJlIGRlbGVnYXRlZCwgDQph bmQgUlMgcmVkaXJlY3RzIFJPIHRvIEFTIHRvIGdyYW50IGFjY2VzcyB0b2tlbiB0byBjbGllbnQs IHRvIG15IA0KdW5kZXJzdGFuZGluZywgaW4gdGhpcyBwcm9jZXNzIFJPIG5lZWRzIHRvIGF1dGhl bnRpY2F0ZSB0byBSUyBhbmQgdGhlbiANCmF1dGhlbnRpY2F0ZSANCnRvIEFTLCBpdCBpcyBhIGJp dCBjb21wbGljYXRlZC4gDQoNCkluIGZhY3QgSSBkaWQgbm90IHdhbnQgdG8gZGlzdHVyYiBub3Jt YWwgT0F1dGggZmxvdy4uIEJUVyB5ZXMuLiBpdCBhZGRzIA0Kc29tZSBvdmVyaGVhZC4uIFNvIC0g SSB3b3VsZCBsaWtlIHRvIG1vZGlmeSBpdCAtIHdoZXJlIHRoZSBSZXNvdXJjZSBTZXJ2ZXIgDQpz ZW5kcyB0aGUgcmVzb3VyY2Vfb3duZXJfaW5pdGlhdGVkIGFzIHRoZSBzY29wZSAtIGFuZCBiYXNl ZCBvbiB0aGUgc2NvcGUgDQpBUyByZXR1cm5zIGJhY2sgY2xpZW50X2lkIHRvZ2V0aGVyIHdpdGgg dGhlIGFjY2Vzc190b2tlbiBpdCBzZWxmLiANCiANCg0KIEkgd29uZGVyIGlmIHRoZSBmb2xsb3dp bmcgdHdvIHByb2Nlc3NlcyBjb3VsZCBzYXRpc2Z5IHlvdXIgY2FzZTogDQoNClByb2Nlc3MgT25l OiANCjEuIFJlc291cmNlIE93bmVyIHJlZ2lzdGVycyB0by1iZS1kZWxlZ2F0ZWQgY2xpZW50cyBh bmQgY29ycmVzcG9uZGluZyBSU3MgDQphdCBBUywgaS5lLiwgYSBsb25nIHRlcm0gZGVsZWdhdGlv biBjb250cmFjdCBpcyBzdG9yZWQgYXQgQVMgDQoNCjIuIFdoZW4gUmVzb3VyY2UgT3duZXIgcmVx dWVzdHMgQ2xpZW50IHRvIGFjY2VzcyBpdHMgcmVzb3VyY2UgYXQgUlMsIA0KQ2xpZW50IGlzIGRp cmVjdGVkIGJ5IFJTIHRvIEFTIHRvIG9idGFpbiBhY2Nlc3MtdG9rZW4gDQozLiBDbGllbnQgYWNj ZXNzZXMgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBvbiBiZWhhbGYgb2YgdGhlIFJlc291cmNlIE93 bmVyLiANCg0KDQpQcm9jZXNzIFR3bzogDQoxLiBSTyByZWdpc3RlcnMgdG8tYmUtZGVsZWdhdGVk IGNsaWVudHMgYXQgUlMsIGkuZS4sIGEgbG9uZyB0ZXJtIA0KZGVsZWdhdGlvbiBjb250cmFjdCBp cyBzdG9yZWQgYXQgUlMgDQoyLiBXaGVuIFJlc291cmNlIE93bmVyIHJlcXVlc3RzIENsaWVudCB0 byBhY2Nlc3MgaXRzIHJlc291cmNlIGF0IFJTLCANCkNsaWVudCBpcyBkaXJlY3RlZCBieSBSUyB0 byBBUyB0byBvYnRhaW4gYWNjZXNzLXRva2VuLEFTIG1heSByZXF1ZXN0IFJPIHRvIA0KYXV0aGVu dGljYXRlIGFuZCBjb25maXJtIHRoZSANCmFjY2Vzcy10b2tlbiByZXF1ZXN0IA0KMy4gQ2xpZW50 IGFjY2Vzc2VzIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2Ugb24gYmVoYWxmIG9mIHRoZSBSZXNvdXJj ZSBPd25lci4gDQogDQoNCg0KVGhlcmUgbmVlZHMgdG8gYmUgYW4gc3RlcCB0byBmYWNpbGl0YXRl IGNsaWVudCByZWdpc3RyYXRpb24uIA0KQ2xpZW50IGNvdWxkIGhhdmUgcmVnaXN0ZXJlZCBhdCBB Uy4gDQpSTyBqdXN0IHNlbGVjdCBjbGllbnRzIGZyb20gYXZhaWxhYmxlIGNsaWVudHMgbGlzdC4g DQpUaGlzIGZhY2lsaXRhdGluZyBzdGVwIHN0aWxsIG5lZWRlZD8gDQoNClRoYW5rcyAmIHJlZ2Fy ZHMsIA0KLVByYWJhdGggDQogDQoNCg0KRXZlIE1hbGVyICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGh0dHA6Ly93d3cueG1sZ3JybC5jb20vYmxvZw0KKzEgNDI1IDM0NSA2NzU2ICAg ICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cudHdpdHRlci5jb20veG1sZ3JybA0KDQoN Cg0KDQoNCi0tIA0KVGhhbmtzICYgUmVnYXJkcywNClByYWJhdGgNCg0KTW9iaWxlIDogKzk0IDcx IDgwOSA2NzMyIA0KDQpodHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCmh0dHA6Ly9SYW1wYXJ0 RkFRLmNvbQ0KDQoNCg0KRXZlIE1hbGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGh0dHA6Ly93d3cueG1sZ3JybC5jb20vYmxvZw0KKzEgNDI1IDM0NSA2NzU2ICAgICAgICAgICAg ICAgICAgICAgICAgIGh0dHA6Ly93d3cudHdpdHRlci5jb20veG1sZ3JybA0KDQoNCg0K --=_alternative 0003D37F48257A94_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBFdmUsPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7VGhlIHJlcXVlc3Rl ciB5b3UgZGVzY3JpYmVkDQpjb3JyZXNwb25kcyB0byBDbGllbnQgaW4gT0F1dGgsIHNvIGl0IGlz IHN0aWxsIGNsaWVudCBpbml0aWF0ZWQgZGVsZWdhdGlvbiwNCm5vdCB3aGF0IFByYWJhdGggd2Fu dHMuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPkV2ZSBNYWxlciAmbHQ7ZXZlQHhtbGdycmwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxw Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTEwLTExIDA2OjU0PC9mb250Pg0K PHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlByYWJhdGgg U2lyaXdhcmRlbmEgJmx0O3ByYWJhdGhAd3NvMi5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj56 aG91LnN1amluZ0B6dGUuY29tLmNuLCAmcXVvdDtvYXV0aEBpZXRmLm9yZw0KV0cmcXVvdDsgJmx0 O29hdXRoQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtPQVVUSC1XR10gUmVz b3VyY2Ugb3duZXIgaW5pdGlhdGVkDQpPQXV0aCBkZWxlZ2F0aW9uPC9mb250PjwvdGFibGU+DQo8 YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwv dGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlN1 cmUuIFdlJ2xsIHVsdGltYXRlbHkgYmUgcHVibGlzaGluZw0Kc29tZSBjYXNlIHN0dWRpZXMgdGhh dCB3aWxsIGhvcGVmdWxseSBtYWtlIHRoaXMgY2xlYXJlciwgYnV0IHRoZSBrZXkgcGxhY2UNCnRv IHN0YXJ0IGluIHRoZSBzcGVjIGlzIGhlcmU6PC9mb250Pg0KPGJyPg0KPGJyPjxhIGhyZWY9Imh0 dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLWNvcmUuaHRtbCNy LWgtYXR0ZW1wdC1hY2Nlc3MiPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1Pmh0dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLWNv cmUuaHRtbCNyLWgtYXR0ZW1wdC1hY2Nlc3M8L3U+PC9mb250PjwvYT4NCjxicj4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Li4uLiBUaGUgcmVxdWVzdGVyIHR5cGlj YWxseSBhdHRlbXB0cw0KdG8gYWNjZXNzIHRoZSBkZXNpcmVkIHJlc291cmNlIGF0IHRoZSBob3N0 IGRpcmVjdGx5IChmb3IgZXhhbXBsZSwgd2hlbg0KYSBodW1hbiBvcGVyYXRvciBvZiB0aGUgcmVx dWVzdGVyIHNvZnR3YXJlIGNsaWNrcyBvbiBhIHRodW1ibmFpbCByZXByZXNlbnRhdGlvbg0Kb2Yg dGhlIHJlc291cmNlKS4gVGhlIHJlcXVlc3RlciBpcyBleHBlY3RlZCB0byBkaXNjb3Zlciwgb3Ig YmUgcHJvdmlzaW9uZWQNCm9yIGNvbmZpZ3VyZWQgd2l0aCwga25vd2xlZGdlIG9mIHRoZSBwcm90 ZWN0ZWQgcmVzb3VyY2UgYW5kIGl0cyBsb2NhdGlvbg0Kb3V0IG9mIGJhbmQuIEZ1cnRoZXIsIHRo ZSByZXF1ZXN0ZXIgaXMgZXhwZWN0ZWQgdG8gYWNxdWlyZSBpdHMgb3duIGtub3dsZWRnZQ0KYWJv dXQgdGhlIGFwcGxpY2F0aW9uLXNwZWNpZmljIG1ldGhvZHMgbWFkZSBhdmFpbGFibGUgYnkgdGhl IGhvc3QgZm9yIG9wZXJhdGluZw0Kb24gdGhpcyBwcm90ZWN0ZWQgcmVzb3VyY2UgKHN1Y2ggYXMg dmlld2luZyBpdCB3aXRoIGEgR0VUIG1ldGhvZCwgb3IgdHJhbnNmb3JtaW5nDQppdCB3aXRoIHNv bWUgY29tcGxleCBBUEkgY2FsbCkgYW5kIHRoZSBwb3NzaWJsZSBzY29wZXMgb2YgYWNjZXNzLiZx dW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+U28g dGhlIHJlcXVlc3RlciBjYW4gaW5pdGlhdGUgdGhlIHJlcXVlc3QsDQp3aXRoIHRoZSBmb2xsb3dp bmcgcHJlY29uZGl0aW9uczo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPi0gVGhlIGhvc3QgKFJTKSBoYXMgcmVnaXN0ZXJlZCB0aGlzDQpyZXNvdXJjZSBh cyBwcm90ZWN0ZWQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBtYW5hZ2VyIChBUykuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4tIFRoZSByZXF1ZXN0ZXIgKGNsaWVu dCkvcmVxdWVzdGluZw0KcGFydHkgaGFzIGxlYXJuZWQgdGhlIGxvY2F0aW9uIGFuZCBhcHBsaWNh YmxlIEFQSSBkZXRhaWxzIG9mIHRoZSByZXNvdXJjZQ0Kb3V0IG9mIGJhbmQuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGUgaW50ZXJhY3Rpb25zIGFt b25nIHRoZSBob3N0IChSUyksDQpBTSAoQVMpLCBhbmQgcmVxdWVzdGVyIChjbGllbnQgLS0gcG90 ZW50aWFsbHkgb3BlcmF0ZWQgYnkgYSB0aGlyZCBwYXJ0eQ0Kd2hvIGlzIG5vdCB0aGUgUk8pIGFy ZSBwcm90ZWN0ZWQgd2l0aCB2YXJpb3VzIHRva2Vucy4gVGhpcyBpcyBpbGx1c3RyYXRlZA0KaW4g dGhlIGludHJvZHVjdGlvbiB3aXRoIEFTQ0lJIGFydC4uLjwvZm9udD4NCjxicj4NCjxicj48YSBo cmVmPSJodHRwOi8vZG9jcy5rYW50YXJhaW5pdGlhdGl2ZS5vcmcvdW1hL2RyYWZ0LXVtYS1jb3Jl Lmh0bWwjaW50cm9kdWN0aW9uIj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48dT5odHRwOi8vZG9jcy5rYW50YXJhaW5pdGlhdGl2ZS5vcmcvdW1hL2RyYWZ0LXVtYS1j b3JlLmh0bWwjaW50cm9kdWN0aW9uPC91PjwvZm9udD48L2E+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBhY3R1YWwgcHJvdGVjdGVkIHJlc291cmNlIHJlcXVp cmVzDQphICZxdW90O3JlcXVlc3RlciBwZXJtaXNzaW9uIHRva2VuJnF1b3Q7IChSUFQpIGFzc29j aWF0ZWQgd2l0aCBzdWl0YWJsZQ0KYXV0aG9yaXphdGlvbiBkYXRhLiBUaGlzIGlzIGFuIFVNQS1z cGVjaWZpYyBjb25zdHJ1Y3QgLS0gYWRtaXR0ZWRseSBub3QNCmEgdHJ1ZSBPQXV0aCBmbG93LCB0 aG91Z2ggaW5zcGlyZWQgYnkgaXQhIFRoZSBBTSBwcmVzZW50cyBhIHByb3RlY3Rpb24NCkFQSSB0 byB0aGUgaG9zdCBmb3IgcmVnaXN0ZXJpbmcgcHJvdGVjdGVkIHJlc291cmNlczsgdGhlIEFQSSBp cyBwcm90ZWN0ZWQNCmJ5IGEgcGxhaW4tdmFuaWxsYSBPQXV0aCB0b2tlbiBjYWxsZWQgYSBwcm90 ZWN0aW9uIEFQSSB0b2tlbiAoUEFUKS4gVGhlDQpBTSBhbHNvIHByZXNlbnRzIGFuIGF1dGhvcml6 YXRpb24gQVBJIHRvIHRoZSByZXF1ZXN0ZXIsIHdoaWNoIGlzIHByb3RlY3RlZA0KYnkgYSBwbGFp bi12YW5pbGxhIE9BdXRoIHRva2VuIGNhbGxlZCBhbiBhdXRob3JpemF0aW9uIEFQSSB0b2tlbiAo QUFUKS4NCldlJ3JlIGNvdW50aW5nIG9uIGR5bmFtaWMgY2xpZW50IHJlZ2lzdHJhdGlvbiB0byBi ZSBpbiBwbGFjZSB3aGVyZXZlciBkZXBsb3llcnMNCndhbnQgdHJ1ZSBsb29zZSBjb3VwbGluZy48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPldoZW4gdGhl IHJlcXVlc3RlciBpbml0aWF0ZXMgYSByZXF1ZXN0LA0KaWYgaXQgaGFzIG5vIHRva2VuIGF0IGFs bCwgdGhlIGhvc3QgZGlyZWN0cyBpdCB0byB0aGUgQU0gdG8gZ2V0IGZpcnN0IGFuDQpBQVQgKHdo aWNoIGNvbnZleXMgQm9iJ3MgYXV0aG9yaXphdGlvbiB0byB1c2UgaXQgYW5kIHRoZSBBTSBpbiBj b252ZXlpbmcNCmlkZW50aXR5IGNsYWltcyB0byB3aW4gYXV0aG9yaXphdGlvbiksIGFuZCB1bHRp bWF0ZWx5IGFuIFJQVCAod2hpY2ggY29udmV5J3MNCkFsaWNlJ3MgYXV0aG9yaXphdGlvbiBmb3Ig Qm9iIGFuZCB0aGlzIHJlcXVlc3RlciBhcHAgdG8gYWNjZXNzIHRoZSByZXNvdXJjZQ0Kd2l0aCBz cGVjaWZpYyBzY29wZXMpLiBPZiBjb3Vyc2Ugd2UncmUgdGFsa2luZyBhYm91dCBhbiBVTUEtZW5h YmxlZCByZXF1ZXN0ZXINCmhlcmUsIGJ1dCBpdCBjYW4gbGl0ZXJhbGx5IGluaXRpYXRlIGFuIGFj Y2VzcyByZXF1ZXN0IHdpdGggemVybyB0b2tlbnMNCmFuZCB1bHRpbWF0ZWx5IGdldCBzb21ld2hl cmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5XZSds bCBiZSBkZW1vaW5nIHRoaXMgd2hvbGUgdGhpbmcgbmV4dA0KV2VkbmVzZGF5IGluIHRoZSB3ZWJp bmFyLCBpbmNsdWRpbmcgdGhlIGR5bmFtaWMgY2xpZW50IHJlZywgdGhlIFBBVCwgQUFULA0KYW5k IFJQVCwgdGhlIFVYIGZvciB0aGUgdmFyaW91cyBwYXJ0aWVzIGludGVyYWN0aW5nIHdpdGggc3lz dGVtcywgYW5kIGV2ZW4NCmludGVyZXN0aW5nIGFwcC1sZXZlbCBlbmhhbmNlbWVudHMgbGlrZSBu b3RpZnlpbmcgQWxpY2UgdGhhdCBCb2IgaGFzIG1hZGUNCmFuIGFjY2VzcyBhdHRlbXB0IGFuZCBp bnZpdGluZyBoZXIgdG8gc2V0IHVwIHBvbGljaWVzIHRoYXQgbGV0IGhpbSBpbi48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkV2ZTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+T24gMTAgT2N0IDIwMTIsIGF0IDM6 MzUgUE0sIFByYWJhdGgNClNpcml3YXJkZW5hICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cHJh YmF0aEB3c28yLmNvbT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48 dT5wcmFiYXRoQHdzbzIuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPiZndDsNCndyb3RlOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+SGkgRXZlLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+SSBoYXZlIGdvbmUgdGhyb3VnaCBVTUEgc3BlYyBidXQgZmFpbGVkDQp0byBm aW5kIGFueSBjYXNlIHdoaWNoIGNvdmVycyB0aGlzIHNjZW5hcmlvIC0gaW4gYSByZXNvdXJjZSBv d25lciBpbml0aWF0ZWQNCm1hbm5lci4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj5DYW4geW91IHBsZWFzZSBnaXZlIHNvbWUgcG9pbnRlcnMuLj88L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyAmYW1w OyByZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+LVBy YWJhdGg8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPk9u IFdlZCwgT2N0IDEwLCAyMDEyIGF0IDM6MjAgUE0sIEV2ZQ0KTWFsZXIgJmx0OzwvZm9udD48YSBo cmVmPW1haWx0bzpldmVAeG1sZ3JybC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29s b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5ldmVAeG1sZ3JybC5jb208L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0Kd3JvdGU6PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5UaGVyZSBhcmUgYSBudW1iZXIgb2YgaW1w bGljaXQgYWN0aW9ucw0KaGFwcGVuaW5nIGhlcmUgdGhhdCBpZGVhbGx5IHNob3VsZCBiZSBhY2Nv dW50ZWQgZm9yLiBJZiBBbGljZSBpcyB0aGUgUk8NCmFuZCBCb2IgaXMgb3BlcmF0aW5nIHRoZSBj bGllbnQsIHRoZW4gd2hlbiBCb2IgYWNjZXNzZXMgdGhlIHByb3RlY3RlZCByZXNvdXJjZQ0KaXQg bWF5IG5vdCBqdXN0IGJlICZxdW90O29uIEFsaWNlJ3MgYmVoYWxmJnF1b3Q7IC0tIHRoaW5rIG9m IGhvdyBwZW9wbGUNCnNoYXJlIGNhbGVuZGFyIHJlYWQvd3JpdGUgYWNjZXNzIHdpdGggb3RoZXIg cGVvcGxlIHRvZGF5LiBUaG9zZSB3aXRoIGRlbGVnYXRlZA0KYWNjZXNzIGFjdCBvbiB0aGVpciBv d24gYmVoYWxmLCB3aXRoIHRoZSBSTydzIHBlcm1pc3Npb24uIFNvIHRoZSB0dXBsZQ0KcmVwcmVz ZW50ZWQgYnkgdGhlIGFjY2VzcyB0b2tlbiBpcyBhY3R1YWxseSBxdWl0ZSBhIGJpdCBiaWdnZXIg dGhhbiB1c3VhbC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPlNpbmNlIE9BdXRoIG1ha2VzIGEgc2ltcGxpZnlpbmcgYXNzdW1wdGlvbg0KdGhhdCBnZXRz IGl0IGVudGlyZWx5IG91dCBvZiB0aGlzIHNvcnQgb2YgYnVzaW5lc3MsIHRoZSBwcm9jZXNzIG9m IHRyeWluZw0KdG8gc2hvZWhvcm4gdGhpcyB1c2UgY2FzZSBpbnRvIGEgc2luZ2xlIHBsYWluIE9B dXRoIGZsb3cgbWF5IGVuZCBiYWRseS4NCkJldHRlciB3b3VsZCBiZSBhbiBleHBsaWNpdCByZWNv Z25pdGlvbiBvZiB0aGUgc3ltbWV0cnkgb2YgQWxpY2UgKHdpdGgNCmhlciB1c2VyIGFnZW50KSBv biBvbmUgc2lkZSwgYW5kIGJvYiB3aXRoIGhpcyBjbGllbnQgb24gdGhlIG90aGVyIHNpZGUuDQpO b3QgdG8gc291bmQgbGlrZSBhIGJyb2tlbiByZWNvcmQsIGJ1dCB0aGUgVU1BIG1vZGVsIHRha2Vz IHRoaXMgZnVsbHkgaW50bw0KYWNjb3VudCBhbmQgaGFzIGV2ZW4gZ29uZSBhIGZhaXIgd2F5IGRv d24gdGhlIHBhdGggb2YgY29uc2lkZXJpbmcgdGhlIGNvbnRyYWN0dWFsDQphbmQgbGVnYWwgaW1w bGljYXRpb25zIG9mIHN1Y2ggYXV0aG9yaXphdGlvbi48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlNpbmNlIHRoZSBjbGllbnQgKGFsb25nIHdpdGggaXRz IG9wZXJhdG9yKQ0KaGFzIHRvIHJlZ2lzdGVyIG9uIHRoZSBBUyBzaWRlIGFueXdheSwgaGF2aW5n IGEgY2xlYW4gbW9kZWwgd2hlcmUgaXQgY2FuDQpkbyB0aGF0IHdpdGhvdXQgdGhlIFJPJ3Mgc3lu Y2hyb25vdXMgcHJlc2VuY2Ugd291bGQgYmUgaWRlYWwuIE90aGVyd2lzZQ0KSSBzdXNwZWN0IGl0 J3MgaW1wcmFjdGljYWwgaW4gbm9ybWFsIHVzZS4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MyBjb2xvcj0jODg4ODg4IGZhY2U9InNhbnMtc2VyaWYiPkV2ZTwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+T24gOSBPY3QgMjAxMiwgYXQgNjo0OSBQ TSwgPC9mb250PjxhIGhyZWY9bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24gdGFyZ2V0PV9i bGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT56aG91LnN1 amluZ0B6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPg0Kd3JvdGU6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQpIaaOsUHJhYmF0aCA8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM3JT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+UHJhYmF0aCBTaXJpd2FyZGVuYSAmbHQ7PC9iPjwvZm9udD48YSBocmVm PW1haWx0bzpwcmFiYXRoQHdzbzIuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PHU+cHJhYmF0aEB3c28yLmNvbTwvdT48L2I+PC9m b250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjwvZm9u dD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTEwLTA5IDIwOjM1PC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD02 MiU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRo PTglPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8 /sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkxJT48YSBocmVmPW1haWx0bzp6aG91LnN1amlu Z0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+PHU+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+RXZlIE1hbGVy ICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZXZlQHhtbGdycmwuY29tIHRhcmdldD1fYmxhbms+ PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ZXZlQHhtbGdycmwu Y29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDssDQo8 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86b2F1dGhAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBz aXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5vYXV0aEBpZXRmLm9yZzwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4sDQo8L2ZvbnQ+PGEgaHJl Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6 ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+b2F1dGgtYm91bmNlc0BpZXRmLm9y ZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+UmU6IFJlOiBSZTogUmU6IFtPQVVUSC1XR10gUmVzb3VyY2UNCm93bmVyIGlu aXRpYXRlZCBPQXV0aCBkZWxlZ2F0aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0 aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiBNb24sIE9jdCA4LCAyMDEy IGF0IDY6MjQgUE0sICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhvdS5zdWppbmdAenRlLmNv bS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1Pnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0Kd3JvdGU6IDxicj4NCjxicj4NCkhpo6wgUHJhYmF0aCA8 YnI+DQogPGJyPg0KIE15IHF1ZXN0aW9uIGlzIHNpbmNlIGNsaWVudC1pZCBpcyBwdWJsaWMsIHRo ZW4gaXQgaXMgYSB3YXN0ZSB0byBnZXQgaXQNCmJ5IGdyYW50aW5nIGFuIGFjY2Vzcy10b2tlbi4g PGJyPg0KIEFuZCBpbiBzdGVwIDIuJnF1b3Q7UmVzb3VyY2UgT3duZXIgZ3JhbnRzIGFjY2VzcyB0 byBhIHNlbGVjdGVkIENsaWVudCZxdW90OywNClJPICZuYnNwO2xvZ2lucyBpbiB0byBzZWxlY3Qg Y2xpZW50cyB0byBiZSBkZWxlZ2F0ZWQsIDxicj4NCmFuZCBSUyByZWRpcmVjdHMgUk8gdG8gQVMg dG8gZ3JhbnQgYWNjZXNzIHRva2VuIHRvIGNsaWVudCwgdG8gbXkgdW5kZXJzdGFuZGluZywNCmlu IHRoaXMgcHJvY2VzcyBSTyBuZWVkcyB0byBhdXRoZW50aWNhdGUgdG8gUlMgYW5kIHRoZW4gYXV0 aGVudGljYXRlIDxicj4NCnRvIEFTLCBpdCBpcyBhIGJpdCBjb21wbGljYXRlZC4gPGJyPg0KPGJy Pg0KSW4gZmFjdCBJIGRpZCBub3Qgd2FudCB0byBkaXN0dXJiIG5vcm1hbCBPQXV0aCBmbG93Li4g QlRXIHllcy4uIGl0IGFkZHMNCnNvbWUgb3ZlcmhlYWQuLiBTbyAtIEkgd291bGQgbGlrZSB0byBt b2RpZnkgaXQgLSB3aGVyZSB0aGUgUmVzb3VyY2UgU2VydmVyDQpzZW5kcyB0aGUgcmVzb3VyY2Vf b3duZXJfaW5pdGlhdGVkIGFzIHRoZSBzY29wZSAtIGFuZCBiYXNlZCBvbiB0aGUgc2NvcGUNCkFT IHJldHVybnMgYmFjayBjbGllbnRfaWQgdG9nZXRoZXIgd2l0aCB0aGUgYWNjZXNzX3Rva2VuIGl0 IHNlbGYuIDxicj4NCiAmbmJzcDs8YnI+DQo8YnI+DQogSSB3b25kZXIgaWYgdGhlIGZvbGxvd2lu ZyB0d28gcHJvY2Vzc2VzIGNvdWxkIHNhdGlzZnkgeW91ciBjYXNlOiA8YnI+DQo8YnI+DQpQcm9j ZXNzIE9uZTogPGJyPg0KMS4gUmVzb3VyY2UgT3duZXIgcmVnaXN0ZXJzIHRvLWJlLWRlbGVnYXRl ZCBjbGllbnRzIGFuZCBjb3JyZXNwb25kaW5nIFJTcw0KYXQgQVMsIGkuZS4sIGEgbG9uZyB0ZXJt IGRlbGVnYXRpb24gY29udHJhY3QgaXMgc3RvcmVkIGF0IEFTIDxicj4NCjxicj4NCjIuIFdoZW4g UmVzb3VyY2UgT3duZXIgcmVxdWVzdHMgQ2xpZW50IHRvIGFjY2VzcyBpdHMgcmVzb3VyY2UgYXQg UlMsIENsaWVudA0KaXMgZGlyZWN0ZWQgYnkgUlMgdG8gQVMgdG8gb2J0YWluIGFjY2Vzcy10b2tl biA8YnI+DQozLiBDbGllbnQgYWNjZXNzZXMgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBvbiBiZWhh bGYgb2YgdGhlIFJlc291cmNlIE93bmVyLg0KPGJyPg0KPGJyPg0KUHJvY2VzcyBUd286IDxicj4N CjEuIFJPIHJlZ2lzdGVycyB0by1iZS1kZWxlZ2F0ZWQgY2xpZW50cyBhdCBSUywgaS5lLiwgYSBs b25nIHRlcm0gZGVsZWdhdGlvbg0KY29udHJhY3QgaXMgc3RvcmVkIGF0IFJTIDxicj4NCjIuIFdo ZW4gUmVzb3VyY2UgT3duZXIgcmVxdWVzdHMgQ2xpZW50IHRvIGFjY2VzcyBpdHMgcmVzb3VyY2Ug YXQgUlMsIENsaWVudA0KaXMgZGlyZWN0ZWQgYnkgUlMgdG8gQVMgdG8gb2J0YWluIGFjY2Vzcy10 b2tlbixBUyBtYXkgcmVxdWVzdCBSTyB0byBhdXRoZW50aWNhdGUNCmFuZCBjb25maXJtIHRoZSA8 YnI+DQphY2Nlc3MtdG9rZW4gcmVxdWVzdCA8YnI+DQozLiBDbGllbnQgYWNjZXNzZXMgdGhlIHBy b3RlY3RlZCByZXNvdXJjZSBvbiBiZWhhbGYgb2YgdGhlIFJlc291cmNlIE93bmVyLg0KJm5ic3A7 IDxicj4NCjxicj4NCjxicj4NClRoZXJlIG5lZWRzIHRvIGJlIGFuIHN0ZXAgdG8gZmFjaWxpdGF0 ZSBjbGllbnQgcmVnaXN0cmF0aW9uLiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KQ2xpZW50IGNvdWxkIGhhdmUgcmVnaXN0ZXJlZCBhdCBBUy48 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClJPIGp1c3Qgc2VsZWN0IGNsaWVu dHMgZnJvbSBhdmFpbGFibGUgY2xpZW50cyBsaXN0LiA8YnI+DQpUaGlzIGZhY2lsaXRhdGluZyBz dGVwIHN0aWxsIG5lZWRlZD88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0K PGJyPg0KPGJyPg0KVGhhbmtzICZhbXA7IHJlZ2FyZHMsIDxicj4NCi1QcmFiYXRoIDxicj4NCiAm bmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIiPjxicj4N CkV2ZSBNYWxlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cueG1sZ3JybC5jb20vYmxv ZyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIiPjx1 Pmh0dHA6Ly93d3cueG1sZ3JybC5jb20vYmxvZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBj b2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj10ZWw6 JTJCMSUyMDQyNSUyMDM0NSUyMDY3NTYgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJDb3VyaWVyIj48dT4rMQ0KNDI1IDM0NSA2NzU2PC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIiPiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9m b250PjxhIGhyZWY9aHR0cDovL3d3dy50d2l0dGVyLmNvbS94bWxncnJsIHRhcmdldD1fYmxhbms+ PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciI+PHU+aHR0cDovL3d3dy50d2l0 dGVyLmNvbS94bWxncnJsPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIi Pjxicj4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4t LSA8YnI+DQpUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+DQpQcmFiYXRoPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5Nb2JpbGUgOiArOTQgNzEgODA5IDY3 MzIgPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20v IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+ PHU+aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVm PWh0dHA6Ly9yYW1wYXJ0ZmFxLmNvbS8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vUmFtcGFydEZBUS5jb208L3U+PC9mb250 PjwvYT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciI+PGJyPg0K RXZlIE1hbGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy54bWxncnJsLmNvbS9ibG9n Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIiPjx1Pmh0dHA6Ly93d3cueG1s Z3JybC5jb20vYmxvZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIj48 YnI+DQorMSA0MjUgMzQ1IDY3NTYgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48 YSBocmVmPWh0dHA6Ly93d3cudHdpdHRlci5jb20veG1sZ3JybD48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJDb3VyaWVyIj48dT5odHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmw8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciI+PGJyPg0KPC9mb250Pg0KPGJy Pg0KPGJyPg0K --=_alternative 0003D37F48257A94_=-- From eve@xmlgrrl.com Wed Oct 10 20:31:09 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E5E21F8668 for ; Wed, 10 Oct 2012 20:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.847 X-Spam-Level: X-Spam-Status: No, score=0.847 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02hrs5j53vKx for ; Wed, 10 Oct 2012 20:31:08 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id DB6B421F865D for ; Wed, 10 Oct 2012 20:31:07 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q9B3V5oc027580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Oct 2012 20:31:06 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_7AD9C9D8-F076-4D00-A4C2-560DCCF3D34D" From: Eve Maler In-Reply-To: Date: Wed, 10 Oct 2012 20:31:05 -0700 Message-Id: <2A09D860-61F3-49F2-901D-C7CD8C0571FD@xmlgrrl.com> References: To: zhou.sujing@zte.com.cn X-Mailer: Apple Mail (2.1499) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 03:31:09 -0000 --Apple-Mail=_7AD9C9D8-F076-4D00-A4C2-560DCCF3D34D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Ah, right. I think I got this more correct in my initial post than in = this last one. Here's how I'd address this: RO Alice controls the access = by client/requester Bob by virtue of consenting at access token issuance = time in Prabath's proposal, vs. setting policies that direct an online = service to issue it when Bob approaches in UMA. Another way to say this = is that access is RO-initiated in the first case and, perhaps, = RO-directed in the second. Having an RO literally being present to = register a client operated by some third party still seems like an = unnecessary constraint to me if the alternative is for RO to configure = their preferences and then move on. (Note that if the RO and the requesting party are the same person, the = UMA flow looks pretty much like a regular OAuth flow because Alice can = configure a policy that says "Only alice@gmail can get full-scope access = to this resource", and if Alice herself shows up using any client and = can prove she's alice@gmail (e.g. through OpenID Connect claims, = something we've already profiled), she's good to go.) Eve On 10 Oct 2012, at 5:40 PM, zhou.sujing@zte.com.cn wrote: >=20 > Hi, Eve,=20 > The requester you described corresponds to Client in OAuth, so it = is still client initiated delegation, not what Prabath wants.=20 >=20 >=20 >=20 > Eve Maler > 2012-10-11 06:54 >=20 > =CA=D5=BC=FE=C8=CB > Prabath Siriwardena > =B3=AD=CB=CD > zhou.sujing@zte.com.cn, "oauth@ietf.org WG" > =D6=F7=CC=E2 > Re: [OAUTH-WG] Resource owner initiated OAuth delegation >=20 >=20 >=20 >=20 >=20 > Sure. We'll ultimately be publishing some case studies that will = hopefully make this clearer, but the key place to start in the spec is = here:=20 >=20 > = http://docs.kantarainitiative.org/uma/draft-uma-core.html#r-h-attempt-acce= ss=20 >=20 > ".... The requester typically attempts to access the desired resource = at the host directly (for example, when a human operator of the = requester software clicks on a thumbnail representation of the = resource). The requester is expected to discover, or be provisioned or = configured with, knowledge of the protected resource and its location = out of band. Further, the requester is expected to acquire its own = knowledge about the application-specific methods made available by the = host for operating on this protected resource (such as viewing it with a = GET method, or transforming it with some complex API call) and the = possible scopes of access."=20 >=20 > So the requester can initiate the request, with the following = preconditions:=20 >=20 > - The host (RS) has registered this resource as protected with the = authorization manager (AS).=20 > - The requester (client)/requesting party has learned the location and = applicable API details of the resource out of band.=20 >=20 > The interactions among the host (RS), AM (AS), and requester (client = -- potentially operated by a third party who is not the RO) are = protected with various tokens. This is illustrated in the introduction = with ASCII art...=20 >=20 > http://docs.kantarainitiative.org/uma/draft-uma-core.html#introduction=20= >=20 > The actual protected resource requires a "requester permission token" = (RPT) associated with suitable authorization data. This is an = UMA-specific construct -- admittedly not a true OAuth flow, though = inspired by it! The AM presents a protection API to the host for = registering protected resources; the API is protected by a plain-vanilla = OAuth token called a protection API token (PAT). The AM also presents an = authorization API to the requester, which is protected by a = plain-vanilla OAuth token called an authorization API token (AAT). We're = counting on dynamic client registration to be in place wherever = deployers want true loose coupling.=20 >=20 > When the requester initiates a request, if it has no token at all, the = host directs it to the AM to get first an AAT (which conveys Bob's = authorization to use it and the AM in conveying identity claims to win = authorization), and ultimately an RPT (which convey's Alice's = authorization for Bob and this requester app to access the resource with = specific scopes). Of course we're talking about an UMA-enabled requester = here, but it can literally initiate an access request with zero tokens = and ultimately get somewhere.=20 >=20 > We'll be demoing this whole thing next Wednesday in the webinar, = including the dynamic client reg, the PAT, AAT, and RPT, the UX for the = various parties interacting with systems, and even interesting app-level = enhancements like notifying Alice that Bob has made an access attempt = and inviting her to set up policies that let him in.=20 >=20 > Eve=20 >=20 > On 10 Oct 2012, at 3:35 PM, Prabath Siriwardena = wrote:=20 >=20 > Hi Eve,=20 >=20 > I have gone through UMA spec but failed to find any case which covers = this scenario - in a resource owner initiated manner..=20 >=20 > Can you please give some pointers..?=20 >=20 > Thanks & regards,=20 > -Prabath=20 >=20 > On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler wrote:=20 > There are a number of implicit actions happening here that ideally = should be accounted for. If Alice is the RO and Bob is operating the = client, then when Bob accesses the protected resource it may not just be = "on Alice's behalf" -- think of how people share calendar read/write = access with other people today. Those with delegated access act on their = own behalf, with the RO's permission. So the tuple represented by the = access token is actually quite a bit bigger than usual.=20 >=20 > Since OAuth makes a simplifying assumption that gets it entirely out = of this sort of business, the process of trying to shoehorn this use = case into a single plain OAuth flow may end badly. Better would be an = explicit recognition of the symmetry of Alice (with her user agent) on = one side, and bob with his client on the other side. Not to sound like a = broken record, but the UMA model takes this fully into account and has = even gone a fair way down the path of considering the contractual and = legal implications of such authorization.=20 >=20 > Since the client (along with its operator) has to register on the AS = side anyway, having a clean model where it can do that without the RO's = synchronous presence would be ideal. Otherwise I suspect it's = impractical in normal use.=20 >=20 > Eve=20 >=20 > On 9 Oct 2012, at 6:49 PM, zhou.sujing@zte.com.cn wrote:=20 >=20 >=20 > Hi=A3=ACPrabath=20 >=20 > Prabath Siriwardena > 2012-10-09 20:35 >=20 >=20 > =CA=D5=BC=FE=C8=CB > zhou.sujing@zte.com.cn > =B3=AD=CB=CD > Eve Maler , oauth@ietf.org, oauth-bounces@ietf.org > =D6=F7=CC=E2 > Re: Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Oct 8, 2012 at 6:24 PM, wrote:=20 >=20 > Hi=A3=AC Prabath=20 >=20 > My question is since client-id is public, then it is a waste to get it = by granting an access-token.=20 > And in step 2."Resource Owner grants access to a selected Client", RO = logins in to select clients to be delegated,=20 > and RS redirects RO to AS to grant access token to client, to my = understanding, in this process RO needs to authenticate to RS and then = authenticate=20 > to AS, it is a bit complicated.=20 >=20 > In fact I did not want to disturb normal OAuth flow.. BTW yes.. it = adds some overhead.. So - I would like to modify it - where the Resource = Server sends the resource_owner_initiated as the scope - and based on = the scope AS returns back client_id together with the access_token it = self.=20 > =20 >=20 > I wonder if the following two processes could satisfy your case:=20 >=20 > Process One:=20 > 1. Resource Owner registers to-be-delegated clients and corresponding = RSs at AS, i.e., a long term delegation contract is stored at AS=20 >=20 > 2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token=20 > 3. Client accesses the protected resource on behalf of the Resource = Owner.=20 >=20 > Process Two:=20 > 1. RO registers to-be-delegated clients at RS, i.e., a long term = delegation contract is stored at RS=20 > 2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token,AS may request RO = to authenticate and confirm the=20 > access-token request=20 > 3. Client accesses the protected resource on behalf of the Resource = Owner. =20 >=20 >=20 > There needs to be an step to facilitate client registration.=20 > Client could have registered at AS.=20 > RO just select clients from available clients list.=20 > This facilitating step still needed?=20 >=20 > Thanks & regards,=20 > -Prabath=20 > =20 >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 >=20 >=20 >=20 >=20 > --=20 > Thanks & Regards, > Prabath=20 >=20 > Mobile : +94 71 809 6732=20 >=20 > http://blog.facilelogin.com > http://RampartFAQ.com=20 >=20 >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_7AD9C9D8-F076-4D00-A4C2-560DCCF3D34D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Ah, = right. I think I got this more correct in my initial post than in this = last one. Here's how I'd address this: RO Alice controls the access by = client/requester Bob by virtue of consenting at access token = issuance time in Prabath's proposal, vs. setting policies that = direct an online service to issue it when Bob approaches in UMA. Another = way to say this is that access is RO-initiated in the first case = and, perhaps, RO-directed in the second. Having an RO = literally being present to register a client operated by some third = party still seems like an unnecessary constraint to me if the = alternative is for RO to configure their preferences and then move = on.

(Note that if the RO and the requesting party are = the same person, the UMA flow looks pretty much like a regular OAuth = flow because Alice can configure a policy that says "Only alice@gmail = can get full-scope access to this resource", and if Alice herself shows = up using any client and can prove she's alice@gmail (e.g. = through OpenID Connect claims, something we've already profiled), she's = good to go.)

= --Apple-Mail=_7AD9C9D8-F076-4D00-A4C2-560DCCF3D34D-- From torsten@lodderstedt.net Wed Oct 10 22:15:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3740F21F86AB for ; Wed, 10 Oct 2012 22:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdeyqYkkRyYM for ; Wed, 10 Oct 2012 22:15:44 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1DD21F8559 for ; Wed, 10 Oct 2012 22:15:43 -0700 (PDT) Received: from [79.253.45.101] (helo=[192.168.71.108]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1TMB7V-0003Ze-Jf; Thu, 11 Oct 2012 07:15:42 +0200 User-Agent: K-9 Mail for Android In-Reply-To: <106E8A07-FE5C-4BC9-B7C8-9EDAE0F9C53B@gmail.com> References: <5075E379.7000502@lodderstedt.net> <106E8A07-FE5C-4BC9-B7C8-9EDAE0F9C53B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----JMRP2I57VSA8X8E3SXYJHY4UV0VK4N" From: Torsten Lodderstedt Date: Thu, 11 Oct 2012 07:15:38 +0200 To: Pedro Felix Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Out-of-band code delivery and alternate redirect_uri schemes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 05:15:45 -0000 ------JMRP2I57VSA8X8E3SXYJHY4UV0VK4N Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit So you assume to use resource owner's address? Regards, Torsten. Pedro Felix schrieb: > > >> Hi Pedro, >> >> Am 10.10.2012 16:25, schrieb Pedro Felix: >>> 1) Out-of-band code transmission >>> >>> Currently Google OAuth2 implementation uses the special >"urn:ietf:wg:oauth:2.0:oob" to signal the Authorization Endpoint to >return an HTML page with the code, instead of a redirect. At first >sight, it seems a good idea, however it isn't in the OAuth 2 RFC. >>> a) What is the reason for the absence in the spec? >>> b) Is there any security problem associated with this usage? >>> >>> 2) Alternative "redirect_uri" schemes >>> >>> I'm also considering the use of alternative schemes on the >"redirect_uri". For instance, a client app could use the "mailto:" >scheme to instruct the Authorization Endpoint to send the code via >email. I know that a naive implementation can be subject to fixation >attacks, however >>> a) Weren't these scenarios considered by the working group? >>> b) Is there a major security flaw on this usage? >> >> What address should the authorization server send an e-mail to and >how would the app acquire this code? >> >> regards, >> Torsten. >The email address would be in the redirect_uri; the code would be >inserted into the client app explicitly by the user, after receiving >it. > >Thanks >Pedro > > >>> >>> Thanks >>> Pedro >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> ------JMRP2I57VSA8X8E3SXYJHY4UV0VK4N Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit So you assume to use resource owner's address?

Regards,
Torsten.



Pedro Felix <pmhsfelix@gmail.com> schrieb:


Hi Pedro,

Am 10.10.2012 16:25, schrieb Pedro Felix:
1) Out-of-band code transmission

Currently Google OAuth2 implementation uses the special "urn:ietf:wg:oauth:2.0:oob" to signal the Authorization Endpoint to return an HTML page with the code, instead of a redirect. At first sight, it seems a good idea, however it isn't in the OAuth 2 RFC. 
  a) What is the reason for the absence in the spec? 
  b) Is there any security problem associated with this usage?

2) Alternative "redirect_uri" schemes

I'm also considering the use of alternative schemes on the "redirect_uri". For instance, a client app could use the "mailto:" scheme to instruct the Authorization Endpoint to send the code via email. I know that a naive implementation can be subject to fixation attacks, however
  a) Weren't these scenarios considered by the working group? 
  b) Is there a major security flaw on this usage?

What address should the authorization server send an e-mail to and how would the app acquire this code?

regards,
Torsten.
The email address would be in the redirect_uri; the code would be inserted into the client app explicitly by the user, after receiving it.

Thanks
Pedro



Thanks
Pedro



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

------JMRP2I57VSA8X8E3SXYJHY4UV0VK4N-- From zhou.sujing@zte.com.cn Thu Oct 11 01:45:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB5D21F86DD for ; Thu, 11 Oct 2012 01:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.337 X-Spam-Level: X-Spam-Status: No, score=-96.337 tagged_above=-999 required=5 tests=[AWL=1.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1osn1kwWPfM5 for ; Thu, 11 Oct 2012 01:45:06 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6F85E21F84F9 for ; Thu, 11 Oct 2012 01:45:05 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 7668D12690DF; Thu, 11 Oct 2012 16:45:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q9B8ipPU048722; Thu, 11 Oct 2012 16:44:51 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <2A09D860-61F3-49F2-901D-C7CD8C0571FD@xmlgrrl.com> To: Eve Maler MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 11 Oct 2012 16:44:40 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-11 16:44:47, Serialize complete at 2012-10-11 16:44:47 Content-Type: multipart/alternative; boundary="=_alternative 0030216448257A94_=" X-MAIL: mse02.zte.com.cn q9B8ipPU048722 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 08:45:08 -0000 This is a multipart message in MIME format. --=_alternative 0030216448257A94_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksRXZlDQoNCiAiSGF2aW5nIGFuIFJPIGxpdGVyYWxseSBiZWluZyBwcmVzZW50IHRvIHJlZ2lz dGVyIGEgY2xpZW50IG9wZXJhdGVkIGJ5IA0Kc29tZSB0aGlyZCBwYXJ0eSBzdGlsbCBzZWVtcyBs aWtlIGFuIHVubmVjZXNzYXJ5IGNvbnN0cmFpbnQgdG8gbWUgaWYgdGhlIA0KYWx0ZXJuYXRpdmUg aXMgZm9yIFJPIHRvIGNvbmZpZ3VyZSB0aGVpciBwcmVmZXJlbmNlcyBhbmQgdGhlbiBtb3ZlIG9u LiINCg0KLS1JIGRpZG4ndCBjYXRjaCB0aGUgc2lnbmlmaWNhbmNlIG9mIGl0IGVpdGhlci4gQnV0 IEkgdGhpbmsgUHJhYmF0aCdzIGlkZWEgDQppcyBub3QgUk8taW5pdGlhdGVkIGNsaWVudCByZWdp c3RlcmF0aW9uLCBidXQgUk8taW5pdGlhdGVkIGFjY2VzcyB0b2tlbiANCmRlbGVnYXRpb24uDQog IExldCBSTyBpdHNlbGYgZGVjaWRlIHdobyBpcyB0byBiZSBkZWxlZ2F0ZWQgaXMgcmVhc29uYWJs ZSwgYW5kIGNvdWxkIGJlIA0KY29tbW9ubHkgc2VlbiBpbiBldmVyZGF5IGxpZmUuDQogIEZvciBl eGFtcGxlLCBJIGRlcG9zaXQgbXkgY2hpbGQgYXQga2luZGVyZ2FyZGVuLCB0aGVuIHdoZW4gc29t ZW9uZSB0cmllcyANCnRvIHRha2UgaGltIG91dHNpZGUgb2YgdGhlIGtpbmRlcmdhcmRlbiwgdGhl IHRlYWNoZXIgd2lsbCBpbmZvcm0gbWUgImRvIA0KeW91IGF1dGhvcml6ZSB0aGlzIGd1eSBkbyBp dCItLS10aGF0IGlzIHdoYXQgT0F1dGggY3VycmVudGx5IGRvOw0KICBCdXQgSSBtYXkgcHJlZmVy IG5vdCB0byBiZSBkaXN0dXJiZWQgdG9vIG9mdGVuLCBJIGp1c3Qgc2VuZCBkZWxlZ2F0aW9uIA0K c3RhdGVtZW50IHRvIGEgZmV3IG9mIHBlcnNvbnMsIGUuZy4sIGdyYW5kcGFyZW50cyBvZiBteSBj aGlsZCwgdGhlbiB3aGVuIA0Kc29tZW9uZSB0cmllcyB0byAgIHRha2UgbXkgY2hpbGQgb3V0c2lk ZSBvZiB0aGUga2luZGVyZ2FyZGVuLCB0aGUgdGVhY2hlciANCndpbGwgYXNrIGhpbS9oZXIgdG8g c2hvdyBteSBkZWxlZ2F0aW9uIHN0YXRlbWVudCwgbm8gc3RhdGVtZW50LCBubyB0YWtpbmcgDQpt eSBjaGlsZC4gLS0tLXRoYXQgbXkgdW5kZXJzdGFuZGluZyBvZiBSTy1pbml0aWF0ZWQgZGVsZWdh dGlvbi4NCg0KIA0KDQoNCg0KRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5jb20+IA0KMjAxMi0xMC0x MSAxMTozMQ0KDQrK1bz+yMsNCnpob3Uuc3VqaW5nQHp0ZS5jb20uY24NCrOty80NCiJvYXV0aEBp ZXRmLm9yZyBXRyIgPG9hdXRoQGlldGYub3JnPiwgUHJhYmF0aCBTaXJpd2FyZGVuYSANCjxwcmFi YXRoQHdzbzIuY29tPg0K1vfM4g0KUmU6IFtPQVVUSC1XR10gUmVzb3VyY2Ugb3duZXIgaW5pdGlh dGVkIE9BdXRoIGRlbGVnYXRpb24NCg0KDQoNCg0KDQoNCkFoLCByaWdodC4gSSB0aGluayBJIGdv dCB0aGlzIG1vcmUgY29ycmVjdCBpbiBteSBpbml0aWFsIHBvc3QgdGhhbiBpbiB0aGlzIA0KbGFz dCBvbmUuIEhlcmUncyBob3cgSSdkIGFkZHJlc3MgdGhpczogUk8gQWxpY2UgY29udHJvbHMgdGhl IGFjY2VzcyBieSANCmNsaWVudC9yZXF1ZXN0ZXIgQm9iIGJ5IHZpcnR1ZSBvZiBjb25zZW50aW5n IGF0IGFjY2VzcyB0b2tlbiBpc3N1YW5jZSB0aW1lIA0KaW4gUHJhYmF0aCdzIHByb3Bvc2FsLCB2 cy4gc2V0dGluZyBwb2xpY2llcyB0aGF0IGRpcmVjdCBhbiBvbmxpbmUgc2VydmljZSANCnRvIGlz c3VlIGl0IHdoZW4gQm9iIGFwcHJvYWNoZXMgaW4gVU1BLiBBbm90aGVyIHdheSB0byBzYXkgdGhp cyBpcyB0aGF0IA0KYWNjZXNzIGlzIFJPLWluaXRpYXRlZCBpbiB0aGUgZmlyc3QgY2FzZSBhbmQs IHBlcmhhcHMsIFJPLWRpcmVjdGVkIGluIHRoZSANCnNlY29uZC4gSGF2aW5nIGFuIFJPIGxpdGVy YWxseSBiZWluZyBwcmVzZW50IHRvIHJlZ2lzdGVyIGEgY2xpZW50IG9wZXJhdGVkIA0KYnkgc29t ZSB0aGlyZCBwYXJ0eSBzdGlsbCBzZWVtcyBsaWtlIGFuIHVubmVjZXNzYXJ5IGNvbnN0cmFpbnQg dG8gbWUgaWYgDQp0aGUgYWx0ZXJuYXRpdmUgaXMgZm9yIFJPIHRvIGNvbmZpZ3VyZSB0aGVpciBw cmVmZXJlbmNlcyBhbmQgdGhlbiBtb3ZlIG9uLg0KDQooTm90ZSB0aGF0IGlmIHRoZSBSTyBhbmQg dGhlIHJlcXVlc3RpbmcgcGFydHkgYXJlIHRoZSBzYW1lIHBlcnNvbiwgdGhlIFVNQSANCmZsb3cg bG9va3MgcHJldHR5IG11Y2ggbGlrZSBhIHJlZ3VsYXIgT0F1dGggZmxvdyBiZWNhdXNlIEFsaWNl IGNhbiANCmNvbmZpZ3VyZSBhIHBvbGljeSB0aGF0IHNheXMgIk9ubHkgYWxpY2VAZ21haWwgY2Fu IGdldCBmdWxsLXNjb3BlIGFjY2VzcyANCnRvIHRoaXMgcmVzb3VyY2UiLCBhbmQgaWYgQWxpY2Ug aGVyc2VsZiBzaG93cyB1cCB1c2luZyBhbnkgY2xpZW50IGFuZCBjYW4gDQpwcm92ZSBzaGUncyBh bGljZUBnbWFpbCAoZS5nLiB0aHJvdWdoIE9wZW5JRCBDb25uZWN0IGNsYWltcywgc29tZXRoaW5n IA0Kd2UndmUgYWxyZWFkeSBwcm9maWxlZCksIHNoZSdzIGdvb2QgdG8gZ28uKQ0KDQpFdmUNCg0K T24gMTAgT2N0IDIwMTIsIGF0IDU6NDAgUE0sIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24gd3JvdGU6 DQoNCg0KSGksIEV2ZSwgDQogICBUaGUgcmVxdWVzdGVyIHlvdSBkZXNjcmliZWQgY29ycmVzcG9u ZHMgdG8gQ2xpZW50IGluIE9BdXRoLCBzbyBpdCBpcyANCnN0aWxsIGNsaWVudCBpbml0aWF0ZWQg ZGVsZWdhdGlvbiwgbm90IHdoYXQgUHJhYmF0aCB3YW50cy4gDQoNCg0KDQpFdmUgTWFsZXIgPGV2 ZUB4bWxncnJsLmNvbT4gDQoyMDEyLTEwLTExIDA2OjU0IA0KDQoNCsrVvP7Iyw0KUHJhYmF0aCBT aXJpd2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbT4gDQqzrcvNDQp6aG91LnN1amluZ0B6dGUuY29t LmNuLCAib2F1dGhAaWV0Zi5vcmcgV0ciIDxvYXV0aEBpZXRmLm9yZz4gDQrW98ziDQpSZTogW09B VVRILVdHXSBSZXNvdXJjZSBvd25lciBpbml0aWF0ZWQgT0F1dGggZGVsZWdhdGlvbg0KDQoNCg0K DQoNCg0KDQoNClN1cmUuIFdlJ2xsIHVsdGltYXRlbHkgYmUgcHVibGlzaGluZyBzb21lIGNhc2Ug c3R1ZGllcyB0aGF0IHdpbGwgaG9wZWZ1bGx5IA0KbWFrZSB0aGlzIGNsZWFyZXIsIGJ1dCB0aGUg a2V5IHBsYWNlIHRvIHN0YXJ0IGluIHRoZSBzcGVjIGlzIGhlcmU6IA0KDQpodHRwOi8vZG9jcy5r YW50YXJhaW5pdGlhdGl2ZS5vcmcvdW1hL2RyYWZ0LXVtYS1jb3JlLmh0bWwjci1oLWF0dGVtcHQt YWNjZXNzIA0KDQoNCiIuLi4uIFRoZSByZXF1ZXN0ZXIgdHlwaWNhbGx5IGF0dGVtcHRzIHRvIGFj Y2VzcyB0aGUgZGVzaXJlZCByZXNvdXJjZSBhdCANCnRoZSBob3N0IGRpcmVjdGx5IChmb3IgZXhh bXBsZSwgd2hlbiBhIGh1bWFuIG9wZXJhdG9yIG9mIHRoZSByZXF1ZXN0ZXIgDQpzb2Z0d2FyZSBj bGlja3Mgb24gYSB0aHVtYm5haWwgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc291cmNlKS4gVGhl IA0KcmVxdWVzdGVyIGlzIGV4cGVjdGVkIHRvIGRpc2NvdmVyLCBvciBiZSBwcm92aXNpb25lZCBv ciBjb25maWd1cmVkIHdpdGgsIA0Ka25vd2xlZGdlIG9mIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2Ug YW5kIGl0cyBsb2NhdGlvbiBvdXQgb2YgYmFuZC4gRnVydGhlciwgDQp0aGUgcmVxdWVzdGVyIGlz IGV4cGVjdGVkIHRvIGFjcXVpcmUgaXRzIG93biBrbm93bGVkZ2UgYWJvdXQgdGhlIA0KYXBwbGlj YXRpb24tc3BlY2lmaWMgbWV0aG9kcyBtYWRlIGF2YWlsYWJsZSBieSB0aGUgaG9zdCBmb3Igb3Bl cmF0aW5nIG9uIA0KdGhpcyBwcm90ZWN0ZWQgcmVzb3VyY2UgKHN1Y2ggYXMgdmlld2luZyBpdCB3 aXRoIGEgR0VUIG1ldGhvZCwgb3IgDQp0cmFuc2Zvcm1pbmcgaXQgd2l0aCBzb21lIGNvbXBsZXgg QVBJIGNhbGwpIGFuZCB0aGUgcG9zc2libGUgc2NvcGVzIG9mIA0KYWNjZXNzLiIgDQoNClNvIHRo ZSByZXF1ZXN0ZXIgY2FuIGluaXRpYXRlIHRoZSByZXF1ZXN0LCB3aXRoIHRoZSBmb2xsb3dpbmcg DQpwcmVjb25kaXRpb25zOiANCg0KLSBUaGUgaG9zdCAoUlMpIGhhcyByZWdpc3RlcmVkIHRoaXMg cmVzb3VyY2UgYXMgcHJvdGVjdGVkIHdpdGggdGhlIA0KYXV0aG9yaXphdGlvbiBtYW5hZ2VyIChB UykuIA0KLSBUaGUgcmVxdWVzdGVyIChjbGllbnQpL3JlcXVlc3RpbmcgcGFydHkgaGFzIGxlYXJu ZWQgdGhlIGxvY2F0aW9uIGFuZCANCmFwcGxpY2FibGUgQVBJIGRldGFpbHMgb2YgdGhlIHJlc291 cmNlIG91dCBvZiBiYW5kLiANCg0KVGhlIGludGVyYWN0aW9ucyBhbW9uZyB0aGUgaG9zdCAoUlMp LCBBTSAoQVMpLCBhbmQgcmVxdWVzdGVyIChjbGllbnQgLS0gDQpwb3RlbnRpYWxseSBvcGVyYXRl ZCBieSBhIHRoaXJkIHBhcnR5IHdobyBpcyBub3QgdGhlIFJPKSBhcmUgcHJvdGVjdGVkIA0Kd2l0 aCB2YXJpb3VzIHRva2Vucy4gVGhpcyBpcyBpbGx1c3RyYXRlZCBpbiB0aGUgaW50cm9kdWN0aW9u IHdpdGggQVNDSUkgDQphcnQuLi4gDQoNCmh0dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9y Zy91bWEvZHJhZnQtdW1hLWNvcmUuaHRtbCNpbnRyb2R1Y3Rpb24gDQoNClRoZSBhY3R1YWwgcHJv dGVjdGVkIHJlc291cmNlIHJlcXVpcmVzIGEgInJlcXVlc3RlciBwZXJtaXNzaW9uIHRva2VuIiAN CihSUFQpIGFzc29jaWF0ZWQgd2l0aCBzdWl0YWJsZSBhdXRob3JpemF0aW9uIGRhdGEuIFRoaXMg aXMgYW4gVU1BLXNwZWNpZmljIA0KY29uc3RydWN0IC0tIGFkbWl0dGVkbHkgbm90IGEgdHJ1ZSBP QXV0aCBmbG93LCB0aG91Z2ggaW5zcGlyZWQgYnkgaXQhIFRoZSANCkFNIHByZXNlbnRzIGEgcHJv dGVjdGlvbiBBUEkgdG8gdGhlIGhvc3QgZm9yIHJlZ2lzdGVyaW5nIHByb3RlY3RlZCANCnJlc291 cmNlczsgdGhlIEFQSSBpcyBwcm90ZWN0ZWQgYnkgYSBwbGFpbi12YW5pbGxhIE9BdXRoIHRva2Vu IGNhbGxlZCBhIA0KcHJvdGVjdGlvbiBBUEkgdG9rZW4gKFBBVCkuIFRoZSBBTSBhbHNvIHByZXNl bnRzIGFuIGF1dGhvcml6YXRpb24gQVBJIHRvIA0KdGhlIHJlcXVlc3Rlciwgd2hpY2ggaXMgcHJv dGVjdGVkIGJ5IGEgcGxhaW4tdmFuaWxsYSBPQXV0aCB0b2tlbiBjYWxsZWQgYW4gDQphdXRob3Jp emF0aW9uIEFQSSB0b2tlbiAoQUFUKS4gV2UncmUgY291bnRpbmcgb24gZHluYW1pYyBjbGllbnQg DQpyZWdpc3RyYXRpb24gdG8gYmUgaW4gcGxhY2Ugd2hlcmV2ZXIgZGVwbG95ZXJzIHdhbnQgdHJ1 ZSBsb29zZSBjb3VwbGluZy4gDQoNCldoZW4gdGhlIHJlcXVlc3RlciBpbml0aWF0ZXMgYSByZXF1 ZXN0LCBpZiBpdCBoYXMgbm8gdG9rZW4gYXQgYWxsLCB0aGUgDQpob3N0IGRpcmVjdHMgaXQgdG8g dGhlIEFNIHRvIGdldCBmaXJzdCBhbiBBQVQgKHdoaWNoIGNvbnZleXMgQm9iJ3MgDQphdXRob3Jp emF0aW9uIHRvIHVzZSBpdCBhbmQgdGhlIEFNIGluIGNvbnZleWluZyBpZGVudGl0eSBjbGFpbXMg dG8gd2luIA0KYXV0aG9yaXphdGlvbiksIGFuZCB1bHRpbWF0ZWx5IGFuIFJQVCAod2hpY2ggY29u dmV5J3MgQWxpY2UncyANCmF1dGhvcml6YXRpb24gZm9yIEJvYiBhbmQgdGhpcyByZXF1ZXN0ZXIg YXBwIHRvIGFjY2VzcyB0aGUgcmVzb3VyY2Ugd2l0aCANCnNwZWNpZmljIHNjb3BlcykuIE9mIGNv dXJzZSB3ZSdyZSB0YWxraW5nIGFib3V0IGFuIFVNQS1lbmFibGVkIHJlcXVlc3RlciANCmhlcmUs IGJ1dCBpdCBjYW4gbGl0ZXJhbGx5IGluaXRpYXRlIGFuIGFjY2VzcyByZXF1ZXN0IHdpdGggemVy byB0b2tlbnMgYW5kIA0KdWx0aW1hdGVseSBnZXQgc29tZXdoZXJlLiANCg0KV2UnbGwgYmUgZGVt b2luZyB0aGlzIHdob2xlIHRoaW5nIG5leHQgV2VkbmVzZGF5IGluIHRoZSB3ZWJpbmFyLCBpbmNs dWRpbmcgDQp0aGUgZHluYW1pYyBjbGllbnQgcmVnLCB0aGUgUEFULCBBQVQsIGFuZCBSUFQsIHRo ZSBVWCBmb3IgdGhlIHZhcmlvdXMgDQpwYXJ0aWVzIGludGVyYWN0aW5nIHdpdGggc3lzdGVtcywg YW5kIGV2ZW4gaW50ZXJlc3RpbmcgYXBwLWxldmVsIA0KZW5oYW5jZW1lbnRzIGxpa2Ugbm90aWZ5 aW5nIEFsaWNlIHRoYXQgQm9iIGhhcyBtYWRlIGFuIGFjY2VzcyBhdHRlbXB0IGFuZCANCmludml0 aW5nIGhlciB0byBzZXQgdXAgcG9saWNpZXMgdGhhdCBsZXQgaGltIGluLiANCg0KRXZlIA0KDQpP biAxMCBPY3QgMjAxMiwgYXQgMzozNSBQTSwgUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3 c28yLmNvbT4gd3JvdGU6IA0KDQpIaSBFdmUsIA0KDQpJIGhhdmUgZ29uZSB0aHJvdWdoIFVNQSBz cGVjIGJ1dCBmYWlsZWQgdG8gZmluZCBhbnkgY2FzZSB3aGljaCBjb3ZlcnMgdGhpcyANCnNjZW5h cmlvIC0gaW4gYSByZXNvdXJjZSBvd25lciBpbml0aWF0ZWQgbWFubmVyLi4gDQoNCkNhbiB5b3Ug cGxlYXNlIGdpdmUgc29tZSBwb2ludGVycy4uPyANCg0KVGhhbmtzICYgcmVnYXJkcywgDQotUHJh YmF0aCANCg0KT24gV2VkLCBPY3QgMTAsIDIwMTIgYXQgMzoyMCBQTSwgRXZlIE1hbGVyIDxldmVA eG1sZ3JybC5jb20+IHdyb3RlOiANClRoZXJlIGFyZSBhIG51bWJlciBvZiBpbXBsaWNpdCBhY3Rp b25zIGhhcHBlbmluZyBoZXJlIHRoYXQgaWRlYWxseSBzaG91bGQgDQpiZSBhY2NvdW50ZWQgZm9y LiBJZiBBbGljZSBpcyB0aGUgUk8gYW5kIEJvYiBpcyBvcGVyYXRpbmcgdGhlIGNsaWVudCwgdGhl biANCndoZW4gQm9iIGFjY2Vzc2VzIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgaXQgbWF5IG5vdCBq dXN0IGJlICJvbiBBbGljZSdzIA0KYmVoYWxmIiAtLSB0aGluayBvZiBob3cgcGVvcGxlIHNoYXJl IGNhbGVuZGFyIHJlYWQvd3JpdGUgYWNjZXNzIHdpdGggb3RoZXIgDQpwZW9wbGUgdG9kYXkuIFRo b3NlIHdpdGggZGVsZWdhdGVkIGFjY2VzcyBhY3Qgb24gdGhlaXIgb3duIGJlaGFsZiwgd2l0aCAN CnRoZSBSTydzIHBlcm1pc3Npb24uIFNvIHRoZSB0dXBsZSByZXByZXNlbnRlZCBieSB0aGUgYWNj ZXNzIHRva2VuIGlzIA0KYWN0dWFsbHkgcXVpdGUgYSBiaXQgYmlnZ2VyIHRoYW4gdXN1YWwuIA0K DQpTaW5jZSBPQXV0aCBtYWtlcyBhIHNpbXBsaWZ5aW5nIGFzc3VtcHRpb24gdGhhdCBnZXRzIGl0 IGVudGlyZWx5IG91dCBvZiANCnRoaXMgc29ydCBvZiBidXNpbmVzcywgdGhlIHByb2Nlc3Mgb2Yg dHJ5aW5nIHRvIHNob2Vob3JuIHRoaXMgdXNlIGNhc2UgDQppbnRvIGEgc2luZ2xlIHBsYWluIE9B dXRoIGZsb3cgbWF5IGVuZCBiYWRseS4gQmV0dGVyIHdvdWxkIGJlIGFuIGV4cGxpY2l0IA0KcmVj b2duaXRpb24gb2YgdGhlIHN5bW1ldHJ5IG9mIEFsaWNlICh3aXRoIGhlciB1c2VyIGFnZW50KSBv biBvbmUgc2lkZSwgDQphbmQgYm9iIHdpdGggaGlzIGNsaWVudCBvbiB0aGUgb3RoZXIgc2lkZS4g Tm90IHRvIHNvdW5kIGxpa2UgYSBicm9rZW4gDQpyZWNvcmQsIGJ1dCB0aGUgVU1BIG1vZGVsIHRh a2VzIHRoaXMgZnVsbHkgaW50byBhY2NvdW50IGFuZCBoYXMgZXZlbiBnb25lIA0KYSBmYWlyIHdh eSBkb3duIHRoZSBwYXRoIG9mIGNvbnNpZGVyaW5nIHRoZSBjb250cmFjdHVhbCBhbmQgbGVnYWwg DQppbXBsaWNhdGlvbnMgb2Ygc3VjaCBhdXRob3JpemF0aW9uLiANCg0KU2luY2UgdGhlIGNsaWVu dCAoYWxvbmcgd2l0aCBpdHMgb3BlcmF0b3IpIGhhcyB0byByZWdpc3RlciBvbiB0aGUgQVMgc2lk ZSANCmFueXdheSwgaGF2aW5nIGEgY2xlYW4gbW9kZWwgd2hlcmUgaXQgY2FuIGRvIHRoYXQgd2l0 aG91dCB0aGUgUk8ncyANCnN5bmNocm9ub3VzIHByZXNlbmNlIHdvdWxkIGJlIGlkZWFsLiBPdGhl cndpc2UgSSBzdXNwZWN0IGl0J3MgaW1wcmFjdGljYWwgDQppbiBub3JtYWwgdXNlLiANCg0KRXZl IA0KDQpPbiA5IE9jdCAyMDEyLCBhdCA2OjQ5IFBNLCB6aG91LnN1amluZ0B6dGUuY29tLmNuIHdy b3RlOiANCg0KDQpIaaOsUHJhYmF0aCANCg0KUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3 c28yLmNvbT4gDQoyMDEyLTEwLTA5IDIwOjM1IA0KDQoNCsrVvP7Iyw0KemhvdS5zdWppbmdAenRl LmNvbS5jbiANCrOty80NCkV2ZSBNYWxlciA8ZXZlQHhtbGdycmwuY29tPiwgb2F1dGhAaWV0Zi5v cmcsIG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgDQrW98ziDQpSZTogUmU6IFJlOiBSZTogW09BVVRI LVdHXSBSZXNvdXJjZSBvd25lciBpbml0aWF0ZWQgT0F1dGggZGVsZWdhdGlvbg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KT24gTW9uLCBPY3QgOCwgMjAxMiBhdCA2OjI0IFBNLCA8emhvdS5zdWpp bmdAenRlLmNvbS5jbj4gd3JvdGU6IA0KDQpIaaOsIFByYWJhdGggDQoNCk15IHF1ZXN0aW9uIGlz IHNpbmNlIGNsaWVudC1pZCBpcyBwdWJsaWMsIHRoZW4gaXQgaXMgYSB3YXN0ZSB0byBnZXQgaXQg YnkgDQpncmFudGluZyBhbiBhY2Nlc3MtdG9rZW4uIA0KQW5kIGluIHN0ZXAgMi4iUmVzb3VyY2Ug T3duZXIgZ3JhbnRzIGFjY2VzcyB0byBhIHNlbGVjdGVkIENsaWVudCIsIFJPIA0KbG9naW5zIGlu IHRvIHNlbGVjdCBjbGllbnRzIHRvIGJlIGRlbGVnYXRlZCwgDQphbmQgUlMgcmVkaXJlY3RzIFJP IHRvIEFTIHRvIGdyYW50IGFjY2VzcyB0b2tlbiB0byBjbGllbnQsIHRvIG15IA0KdW5kZXJzdGFu ZGluZywgaW4gdGhpcyBwcm9jZXNzIFJPIG5lZWRzIHRvIGF1dGhlbnRpY2F0ZSB0byBSUyBhbmQg dGhlbiANCmF1dGhlbnRpY2F0ZSANCnRvIEFTLCBpdCBpcyBhIGJpdCBjb21wbGljYXRlZC4gDQoN CkluIGZhY3QgSSBkaWQgbm90IHdhbnQgdG8gZGlzdHVyYiBub3JtYWwgT0F1dGggZmxvdy4uIEJU VyB5ZXMuLiBpdCBhZGRzIA0Kc29tZSBvdmVyaGVhZC4uIFNvIC0gSSB3b3VsZCBsaWtlIHRvIG1v ZGlmeSBpdCAtIHdoZXJlIHRoZSBSZXNvdXJjZSBTZXJ2ZXIgDQpzZW5kcyB0aGUgcmVzb3VyY2Vf b3duZXJfaW5pdGlhdGVkIGFzIHRoZSBzY29wZSAtIGFuZCBiYXNlZCBvbiB0aGUgc2NvcGUgDQpB UyByZXR1cm5zIGJhY2sgY2xpZW50X2lkIHRvZ2V0aGVyIHdpdGggdGhlIGFjY2Vzc190b2tlbiBp dCBzZWxmLiANCiANCg0KSSB3b25kZXIgaWYgdGhlIGZvbGxvd2luZyB0d28gcHJvY2Vzc2VzIGNv dWxkIHNhdGlzZnkgeW91ciBjYXNlOiANCg0KUHJvY2VzcyBPbmU6IA0KMS4gUmVzb3VyY2UgT3du ZXIgcmVnaXN0ZXJzIHRvLWJlLWRlbGVnYXRlZCBjbGllbnRzIGFuZCBjb3JyZXNwb25kaW5nIFJT cyANCmF0IEFTLCBpLmUuLCBhIGxvbmcgdGVybSBkZWxlZ2F0aW9uIGNvbnRyYWN0IGlzIHN0b3Jl ZCBhdCBBUyANCg0KMi4gV2hlbiBSZXNvdXJjZSBPd25lciByZXF1ZXN0cyBDbGllbnQgdG8gYWNj ZXNzIGl0cyByZXNvdXJjZSBhdCBSUywgDQpDbGllbnQgaXMgZGlyZWN0ZWQgYnkgUlMgdG8gQVMg dG8gb2J0YWluIGFjY2Vzcy10b2tlbiANCjMuIENsaWVudCBhY2Nlc3NlcyB0aGUgcHJvdGVjdGVk IHJlc291cmNlIG9uIGJlaGFsZiBvZiB0aGUgUmVzb3VyY2UgT3duZXIuIA0KDQoNClByb2Nlc3Mg VHdvOiANCjEuIFJPIHJlZ2lzdGVycyB0by1iZS1kZWxlZ2F0ZWQgY2xpZW50cyBhdCBSUywgaS5l LiwgYSBsb25nIHRlcm0gDQpkZWxlZ2F0aW9uIGNvbnRyYWN0IGlzIHN0b3JlZCBhdCBSUyANCjIu IFdoZW4gUmVzb3VyY2UgT3duZXIgcmVxdWVzdHMgQ2xpZW50IHRvIGFjY2VzcyBpdHMgcmVzb3Vy Y2UgYXQgUlMsIA0KQ2xpZW50IGlzIGRpcmVjdGVkIGJ5IFJTIHRvIEFTIHRvIG9idGFpbiBhY2Nl c3MtdG9rZW4sQVMgbWF5IHJlcXVlc3QgUk8gdG8gDQphdXRoZW50aWNhdGUgYW5kIGNvbmZpcm0g dGhlIA0KYWNjZXNzLXRva2VuIHJlcXVlc3QgDQozLiBDbGllbnQgYWNjZXNzZXMgdGhlIHByb3Rl Y3RlZCByZXNvdXJjZSBvbiBiZWhhbGYgb2YgdGhlIFJlc291cmNlIE93bmVyLiANCiANCg0KDQpU aGVyZSBuZWVkcyB0byBiZSBhbiBzdGVwIHRvIGZhY2lsaXRhdGUgY2xpZW50IHJlZ2lzdHJhdGlv bi4gDQpDbGllbnQgY291bGQgaGF2ZSByZWdpc3RlcmVkIGF0IEFTLiANClJPIGp1c3Qgc2VsZWN0 IGNsaWVudHMgZnJvbSBhdmFpbGFibGUgY2xpZW50cyBsaXN0LiANClRoaXMgZmFjaWxpdGF0aW5n IHN0ZXAgc3RpbGwgbmVlZGVkPyANCg0KVGhhbmtzICYgcmVnYXJkcywgDQotUHJhYmF0aCANCiAN Cg0KDQpFdmUgTWFsZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3 dy54bWxncnJsLmNvbS9ibG9nDQorMSA0MjUgMzQ1IDY3NTYgICAgICAgICAgICAgICAgICAgICAg ICAgaHR0cDovL3d3dy50d2l0dGVyLmNvbS94bWxncnJsDQoNCg0KDQoNCg0KLS0gDQpUaGFua3Mg JiBSZWdhcmRzLA0KUHJhYmF0aCANCg0KTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0KDQpodHRw Oi8vYmxvZy5mYWNpbGVsb2dpbi5jb20NCmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbSANCg0KDQoNCkV2 ZSBNYWxlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vd3d3LnhtbGdy cmwuY29tL2Jsb2cNCisxIDQyNSAzNDUgNjc1NiAgICAgICAgICAgICAgICAgICAgICAgICBodHRw Oi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmwNCg0KDQoNCg0KRXZlIE1hbGVyICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cueG1sZ3JybC5jb20vYmxvZw0KKzEgNDI1 IDM0NSA2NzU2ICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cudHdpdHRlci5jb20v eG1sZ3JybA0KDQoNCg0K --=_alternative 0030216448257A94_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLEV2ZTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7JnF1b3Q7PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5IYXZpbmcNCmFuIFJPIGxpdGVyYWxseSBiZWlu ZyBwcmVzZW50IHRvIHJlZ2lzdGVyIGEgY2xpZW50IG9wZXJhdGVkIGJ5IHNvbWUgdGhpcmQNCnBh cnR5IHN0aWxsIHNlZW1zIGxpa2UgYW4gdW5uZWNlc3NhcnkgY29uc3RyYWludCB0byBtZSBpZiB0 aGUgYWx0ZXJuYXRpdmUNCmlzIGZvciBSTyB0byBjb25maWd1cmUgdGhlaXIgcHJlZmVyZW5jZXMg YW5kIHRoZW4gbW92ZSBvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+LS1J IGRpZG4ndCBjYXRjaCB0aGUgc2lnbmlmaWNhbmNlIG9mDQppdCBlaXRoZXIuIEJ1dCBJIHRoaW5r IFByYWJhdGgncyBpZGVhIGlzIG5vdCBSTy1pbml0aWF0ZWQgY2xpZW50IHJlZ2lzdGVyYXRpb24s DQpidXQgUk8taW5pdGlhdGVkIGFjY2VzcyB0b2tlbiBkZWxlZ2F0aW9uLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IExldCBSTyBpdHNlbGYgZGVjaWRl IHdobyBpcyB0bw0KYmUgZGVsZWdhdGVkIGlzIHJlYXNvbmFibGUsIGFuZCBjb3VsZCBiZSBjb21t b25seSBzZWVuIGluIGV2ZXJkYXkgbGlmZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyBGb3IgZXhhbXBsZSwgSSBkZXBvc2l0IG15IGNoaWxkDQphdCBr aW5kZXJnYXJkZW4sIHRoZW4gd2hlbiBzb21lb25lIHRyaWVzIHRvIHRha2UgaGltIG91dHNpZGUg b2YgdGhlIGtpbmRlcmdhcmRlbiwNCnRoZSB0ZWFjaGVyIHdpbGwgaW5mb3JtIG1lICZxdW90O2Rv IHlvdSBhdXRob3JpemUgdGhpcyBndXkgZG8gaXQmcXVvdDstLS10aGF0DQppcyB3aGF0IE9BdXRo IGN1cnJlbnRseSBkbzs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyBCdXQgSSBtYXkgcHJlZmVyIG5vdCB0byBiZSBkaXN0dXJiZWQNCnRvbyBvZnRlbiwg SSBqdXN0IHNlbmQgZGVsZWdhdGlvbiBzdGF0ZW1lbnQgdG8gYSBmZXcgb2YgcGVyc29ucywgZS5n LiwNCmdyYW5kcGFyZW50cyBvZiBteSBjaGlsZCwgdGhlbiB3aGVuIHNvbWVvbmUgdHJpZXMgdG8g Jm5ic3A7IHRha2UgbXkgY2hpbGQNCm91dHNpZGUgb2YgdGhlIGtpbmRlcmdhcmRlbiwgdGhlIHRl YWNoZXIgd2lsbCBhc2sgaGltL2hlciB0byBzaG93IG15IGRlbGVnYXRpb24NCnN0YXRlbWVudCwg bm8gc3RhdGVtZW50LCBubyB0YWtpbmcgbXkgY2hpbGQuIC0tLS10aGF0IG15IHVuZGVyc3RhbmRp bmcNCm9mIFJPLWluaXRpYXRlZCBkZWxlZ2F0aW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkV2ZSBNYWxlciAmbHQ7ZXZlQHhtbGdycmwuY29t Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEy LTEwLTExIDExOjMxPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90O29hdXRoQGlldGYub3JnIFdHJnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDssDQpQcmFi YXRoIFNpcml3YXJkZW5hICZsdDtwcmFiYXRoQHdzbzIuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+UmU6IFtPQVVUSC1XR10gUmVzb3VyY2Ugb3duZXIgaW5pdGlhdGVkDQpPQXV0aCBkZWxlZ2F0 aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N Cjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPkFoLCByaWdodC4gSSB0aGluayBJIGdvdCB0aGlzIG1vcmUgY29y cmVjdA0KaW4gbXkgaW5pdGlhbCBwb3N0IHRoYW4gaW4gdGhpcyBsYXN0IG9uZS4gSGVyZSdzIGhv dyBJJ2QgYWRkcmVzcyB0aGlzOg0KUk8gQWxpY2UgY29udHJvbHMgdGhlIGFjY2VzcyBieSBjbGll bnQvcmVxdWVzdGVyIEJvYiBieSB2aXJ0dWUgb2YgPGk+Y29uc2VudGluZzwvaT4NCmF0IGFjY2Vz cyB0b2tlbiBpc3N1YW5jZSB0aW1lIGluIFByYWJhdGgncyBwcm9wb3NhbCwgdnMuIDxpPnNldHRp bmcgcG9saWNpZXM8L2k+DQp0aGF0IGRpcmVjdCBhbiBvbmxpbmUgc2VydmljZSB0byBpc3N1ZSBp dCB3aGVuIEJvYiBhcHByb2FjaGVzIGluIFVNQS4gQW5vdGhlcg0Kd2F5IHRvIHNheSB0aGlzIGlz IHRoYXQgYWNjZXNzIGlzIFJPLTxpPmluaXRpYXRlZDwvaT4gaW4gdGhlIGZpcnN0IGNhc2UNCmFu ZCwgcGVyaGFwcywgUk8tPGk+ZGlyZWN0ZWQ8L2k+IGluIHRoZSBzZWNvbmQuIEhhdmluZyBhbiBS TyBsaXRlcmFsbHkNCmJlaW5nIHByZXNlbnQgdG8gcmVnaXN0ZXIgYSBjbGllbnQgb3BlcmF0ZWQg Ynkgc29tZSB0aGlyZCBwYXJ0eSBzdGlsbCBzZWVtcw0KbGlrZSBhbiB1bm5lY2Vzc2FyeSBjb25z dHJhaW50IHRvIG1lIGlmIHRoZSBhbHRlcm5hdGl2ZSBpcyBmb3IgUk8gdG8gY29uZmlndXJlDQp0 aGVpciBwcmVmZXJlbmNlcyBhbmQgdGhlbiBtb3ZlIG9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+KE5vdGUgdGhhdCBpZiB0aGUgUk8gYW5kIHRoZSBy ZXF1ZXN0aW5nDQpwYXJ0eSBhcmUgdGhlIHNhbWUgcGVyc29uLCB0aGUgVU1BIGZsb3cgbG9va3Mg cHJldHR5IG11Y2ggbGlrZSBhIHJlZ3VsYXINCk9BdXRoIGZsb3cgYmVjYXVzZSBBbGljZSBjYW4g Y29uZmlndXJlIGEgcG9saWN5IHRoYXQgc2F5cyAmcXVvdDtPbmx5IGFsaWNlQGdtYWlsDQpjYW4g Z2V0IGZ1bGwtc2NvcGUgYWNjZXNzIHRvIHRoaXMgcmVzb3VyY2UmcXVvdDssIGFuZCBpZiBBbGlj ZSBoZXJzZWxmDQpzaG93cyB1cCB1c2luZyBhbnkgY2xpZW50IGFuZCBjYW4gcHJvdmUgc2hlJ3Mg YWxpY2VAZ21haWwgKGUuZy4gdGhyb3VnaA0KT3BlbklEIENvbm5lY3QgY2xhaW1zLCBzb21ldGhp bmcgd2UndmUgYWxyZWFkeSBwcm9maWxlZCksIHNoZSdzIGdvb2QgdG8NCmdvLik8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkV2ZTwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+T24gMTAgT2N0IDIwMTIsIGF0IDU6 NDAgUE0sIDwvZm9udD48YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pnpob3Uuc3VqaW5nQHp0ZS5j b20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQp3cm90 ZTo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N CkhpLCBFdmUsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7IFRoZSByZXF1ZXN0ZXIg eW91IGRlc2NyaWJlZCBjb3JyZXNwb25kcyB0byBDbGllbnQgaW4gT0F1dGgsIHNvDQppdCBpcyBz dGlsbCBjbGllbnQgaW5pdGlhdGVkIGRlbGVnYXRpb24sIG5vdCB3aGF0IFByYWJhdGggd2FudHMu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjxicj4NCjxicj4N CjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MzIlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5FdmUgTWFsZXIgJmx0OzwvYj48 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZXZlQHhtbGdycmwuY29tPjxmb250IHNpemU9MSBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PmV2ZUB4bWxncnJsLmNvbTwvdT48L2I+PC9mb250 PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTEwLTExIDA2OjU0PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD02NyU+ DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTgl Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkxJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+UHJhYmF0aCBTaXJpd2FyZGVuYSAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnByYWJhdGhA d3NvMi5jb20+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+cHJh YmF0aEB3c28yLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48YSBocmVmPW1haWx0bzp6aG91LnN1 amluZ0B6dGUuY29tLmNuPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pjx1Pnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+LA0KJnF1b3Q7PC9mb250PjxhIGhyZWY9bWFpbHRvOm9hdXRoQGlldGYu b3JnPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pm9hdXRoQGll dGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPg0KV0cm cXVvdDsgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpvYXV0aEBpZXRmLm9yZz48Zm9udCBzaXpl PTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5vYXV0aEBpZXRmLm9yZzwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtPQVVUSC1X R10gUmVzb3VyY2Ugb3duZXIgaW5pdGlhdGVkDQpPQXV0aCBkZWxlZ2F0aW9uPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk IHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8YnI+DQo8YnI+DQpTdXJlLiBXZSds bCB1bHRpbWF0ZWx5IGJlIHB1Ymxpc2hpbmcgc29tZSBjYXNlIHN0dWRpZXMgdGhhdCB3aWxsIGhv cGVmdWxseQ0KbWFrZSB0aGlzIGNsZWFyZXIsIGJ1dCB0aGUga2V5IHBsYWNlIHRvIHN0YXJ0IGlu IHRoZSBzcGVjIGlzIGhlcmU6IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBm YWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9Imh0dHA6Ly9kb2Nz LmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLWNvcmUuaHRtbCNyLWgtYXR0ZW1w dC1hY2Nlc3MiPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0 dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLWNvcmUuaHRtbCNy LWgtYXR0ZW1wdC1hY2Nlc3M8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+DQo8YnI+DQo8YnI+DQomcXVvdDsuLi4uIFRoZSByZXF1ZXN0ZXIgdHlwaWNhbGx5IGF0 dGVtcHRzIHRvIGFjY2VzcyB0aGUgZGVzaXJlZCByZXNvdXJjZQ0KYXQgdGhlIGhvc3QgZGlyZWN0 bHkgKGZvciBleGFtcGxlLCB3aGVuIGEgaHVtYW4gb3BlcmF0b3Igb2YgdGhlIHJlcXVlc3Rlcg0K c29mdHdhcmUgY2xpY2tzIG9uIGEgdGh1bWJuYWlsIHJlcHJlc2VudGF0aW9uIG9mIHRoZSByZXNv dXJjZSkuIFRoZSByZXF1ZXN0ZXINCmlzIGV4cGVjdGVkIHRvIGRpc2NvdmVyLCBvciBiZSBwcm92 aXNpb25lZCBvciBjb25maWd1cmVkIHdpdGgsIGtub3dsZWRnZQ0Kb2YgdGhlIHByb3RlY3RlZCBy ZXNvdXJjZSBhbmQgaXRzIGxvY2F0aW9uIG91dCBvZiBiYW5kLiBGdXJ0aGVyLCB0aGUgcmVxdWVz dGVyDQppcyBleHBlY3RlZCB0byBhY3F1aXJlIGl0cyBvd24ga25vd2xlZGdlIGFib3V0IHRoZSBh cHBsaWNhdGlvbi1zcGVjaWZpYw0KbWV0aG9kcyBtYWRlIGF2YWlsYWJsZSBieSB0aGUgaG9zdCBm b3Igb3BlcmF0aW5nIG9uIHRoaXMgcHJvdGVjdGVkIHJlc291cmNlDQooc3VjaCBhcyB2aWV3aW5n IGl0IHdpdGggYSBHRVQgbWV0aG9kLCBvciB0cmFuc2Zvcm1pbmcgaXQgd2l0aCBzb21lIGNvbXBs ZXgNCkFQSSBjYWxsKSBhbmQgdGhlIHBvc3NpYmxlIHNjb3BlcyBvZiBhY2Nlc3MuJnF1b3Q7IDxi cj4NCjxicj4NClNvIHRoZSByZXF1ZXN0ZXIgY2FuIGluaXRpYXRlIHRoZSByZXF1ZXN0LCB3aXRo IHRoZSBmb2xsb3dpbmcgcHJlY29uZGl0aW9uczoNCjxicj4NCjxicj4NCi0gVGhlIGhvc3QgKFJT KSBoYXMgcmVnaXN0ZXJlZCB0aGlzIHJlc291cmNlIGFzIHByb3RlY3RlZCB3aXRoIHRoZSBhdXRo b3JpemF0aW9uDQptYW5hZ2VyIChBUykuIDxicj4NCi0gVGhlIHJlcXVlc3RlciAoY2xpZW50KS9y ZXF1ZXN0aW5nIHBhcnR5IGhhcyBsZWFybmVkIHRoZSBsb2NhdGlvbiBhbmQNCmFwcGxpY2FibGUg QVBJIGRldGFpbHMgb2YgdGhlIHJlc291cmNlIG91dCBvZiBiYW5kLiA8YnI+DQo8YnI+DQpUaGUg aW50ZXJhY3Rpb25zIGFtb25nIHRoZSBob3N0IChSUyksIEFNIChBUyksIGFuZCByZXF1ZXN0ZXIg KGNsaWVudCAtLQ0KcG90ZW50aWFsbHkgb3BlcmF0ZWQgYnkgYSB0aGlyZCBwYXJ0eSB3aG8gaXMg bm90IHRoZSBSTykgYXJlIHByb3RlY3RlZA0Kd2l0aCB2YXJpb3VzIHRva2Vucy4gVGhpcyBpcyBp bGx1c3RyYXRlZCBpbiB0aGUgaW50cm9kdWN0aW9uIHdpdGggQVNDSUkNCmFydC4uLiA8YnI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0K PC91PjwvZm9udD48YSBocmVmPSJodHRwOi8vZG9jcy5rYW50YXJhaW5pdGlhdGl2ZS5vcmcvdW1h L2RyYWZ0LXVtYS1jb3JlLmh0bWwjaW50cm9kdWN0aW9uIj48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vZG9jcy5rYW50YXJhaW5pdGlhdGl2ZS5vcmcv dW1hL2RyYWZ0LXVtYS1jb3JlLmh0bWwjaW50cm9kdWN0aW9uPC91PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPGJyPg0KVGhlIGFjdHVhbCBwcm90ZWN0 ZWQgcmVzb3VyY2UgcmVxdWlyZXMgYSAmcXVvdDtyZXF1ZXN0ZXIgcGVybWlzc2lvbiB0b2tlbiZx dW90Ow0KKFJQVCkgYXNzb2NpYXRlZCB3aXRoIHN1aXRhYmxlIGF1dGhvcml6YXRpb24gZGF0YS4g VGhpcyBpcyBhbiBVTUEtc3BlY2lmaWMNCmNvbnN0cnVjdCAtLSBhZG1pdHRlZGx5IG5vdCBhIHRy dWUgT0F1dGggZmxvdywgdGhvdWdoIGluc3BpcmVkIGJ5IGl0ISBUaGUNCkFNIHByZXNlbnRzIGEg cHJvdGVjdGlvbiBBUEkgdG8gdGhlIGhvc3QgZm9yIHJlZ2lzdGVyaW5nIHByb3RlY3RlZCByZXNv dXJjZXM7DQp0aGUgQVBJIGlzIHByb3RlY3RlZCBieSBhIHBsYWluLXZhbmlsbGEgT0F1dGggdG9r ZW4gY2FsbGVkIGEgcHJvdGVjdGlvbg0KQVBJIHRva2VuIChQQVQpLiBUaGUgQU0gYWxzbyBwcmVz ZW50cyBhbiBhdXRob3JpemF0aW9uIEFQSSB0byB0aGUgcmVxdWVzdGVyLA0Kd2hpY2ggaXMgcHJv dGVjdGVkIGJ5IGEgcGxhaW4tdmFuaWxsYSBPQXV0aCB0b2tlbiBjYWxsZWQgYW4gYXV0aG9yaXph dGlvbg0KQVBJIHRva2VuIChBQVQpLiBXZSdyZSBjb3VudGluZyBvbiBkeW5hbWljIGNsaWVudCBy ZWdpc3RyYXRpb24gdG8gYmUgaW4NCnBsYWNlIHdoZXJldmVyIGRlcGxveWVycyB3YW50IHRydWUg bG9vc2UgY291cGxpbmcuIDxicj4NCjxicj4NCldoZW4gdGhlIHJlcXVlc3RlciBpbml0aWF0ZXMg YSByZXF1ZXN0LCBpZiBpdCBoYXMgbm8gdG9rZW4gYXQgYWxsLCB0aGUNCmhvc3QgZGlyZWN0cyBp dCB0byB0aGUgQU0gdG8gZ2V0IGZpcnN0IGFuIEFBVCAod2hpY2ggY29udmV5cyBCb2IncyBhdXRo b3JpemF0aW9uDQp0byB1c2UgaXQgYW5kIHRoZSBBTSBpbiBjb252ZXlpbmcgaWRlbnRpdHkgY2xh aW1zIHRvIHdpbiBhdXRob3JpemF0aW9uKSwNCmFuZCB1bHRpbWF0ZWx5IGFuIFJQVCAod2hpY2gg Y29udmV5J3MgQWxpY2UncyBhdXRob3JpemF0aW9uIGZvciBCb2IgYW5kDQp0aGlzIHJlcXVlc3Rl ciBhcHAgdG8gYWNjZXNzIHRoZSByZXNvdXJjZSB3aXRoIHNwZWNpZmljIHNjb3BlcykuIE9mIGNv dXJzZQ0Kd2UncmUgdGFsa2luZyBhYm91dCBhbiBVTUEtZW5hYmxlZCByZXF1ZXN0ZXIgaGVyZSwg YnV0IGl0IGNhbiBsaXRlcmFsbHkNCmluaXRpYXRlIGFuIGFjY2VzcyByZXF1ZXN0IHdpdGggemVy byB0b2tlbnMgYW5kIHVsdGltYXRlbHkgZ2V0IHNvbWV3aGVyZS4NCjxicj4NCjxicj4NCldlJ2xs IGJlIGRlbW9pbmcgdGhpcyB3aG9sZSB0aGluZyBuZXh0IFdlZG5lc2RheSBpbiB0aGUgd2ViaW5h ciwgaW5jbHVkaW5nDQp0aGUgZHluYW1pYyBjbGllbnQgcmVnLCB0aGUgUEFULCBBQVQsIGFuZCBS UFQsIHRoZSBVWCBmb3IgdGhlIHZhcmlvdXMgcGFydGllcw0KaW50ZXJhY3Rpbmcgd2l0aCBzeXN0 ZW1zLCBhbmQgZXZlbiBpbnRlcmVzdGluZyBhcHAtbGV2ZWwgZW5oYW5jZW1lbnRzIGxpa2UNCm5v dGlmeWluZyBBbGljZSB0aGF0IEJvYiBoYXMgbWFkZSBhbiBhY2Nlc3MgYXR0ZW1wdCBhbmQgaW52 aXRpbmcgaGVyIHRvDQpzZXQgdXAgcG9saWNpZXMgdGhhdCBsZXQgaGltIGluLiA8YnI+DQo8YnI+ DQpFdmUgPGJyPg0KPGJyPg0KT24gMTAgT2N0IDIwMTIsIGF0IDM6MzUgUE0sIFByYWJhdGggU2ly aXdhcmRlbmEgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpwcmFiYXRoQHdzbzIuY29tPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PnByYWJhdGhAd3NvMi5jb208 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0Kd3JvdGU6 IDxicj4NCjxicj4NCkhpIEV2ZSwgPGJyPg0KPGJyPg0KSSBoYXZlIGdvbmUgdGhyb3VnaCBVTUEg c3BlYyBidXQgZmFpbGVkIHRvIGZpbmQgYW55IGNhc2Ugd2hpY2ggY292ZXJzIHRoaXMNCnNjZW5h cmlvIC0gaW4gYSByZXNvdXJjZSBvd25lciBpbml0aWF0ZWQgbWFubmVyLi4gPGJyPg0KPGJyPg0K Q2FuIHlvdSBwbGVhc2UgZ2l2ZSBzb21lIHBvaW50ZXJzLi4/IDxicj4NCjxicj4NClRoYW5rcyAm YW1wOyByZWdhcmRzLCA8YnI+DQotUHJhYmF0aCA8YnI+DQo8YnI+DQpPbiBXZWQsIE9jdCAxMCwg MjAxMiBhdCAzOjIwIFBNLCBFdmUgTWFsZXIgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpldmVA eG1sZ3JybC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJz YW5zLXNlcmlmIj48dT5ldmVAeG1sZ3JybC5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+Jmd0Ow0Kd3JvdGU6IDxicj4NClRoZXJlIGFyZSBhIG51bWJlciBv ZiBpbXBsaWNpdCBhY3Rpb25zIGhhcHBlbmluZyBoZXJlIHRoYXQgaWRlYWxseSBzaG91bGQNCmJl IGFjY291bnRlZCBmb3IuIElmIEFsaWNlIGlzIHRoZSBSTyBhbmQgQm9iIGlzIG9wZXJhdGluZyB0 aGUgY2xpZW50LCB0aGVuDQp3aGVuIEJvYiBhY2Nlc3NlcyB0aGUgcHJvdGVjdGVkIHJlc291cmNl IGl0IG1heSBub3QganVzdCBiZSAmcXVvdDtvbiBBbGljZSdzDQpiZWhhbGYmcXVvdDsgLS0gdGhp bmsgb2YgaG93IHBlb3BsZSBzaGFyZSBjYWxlbmRhciByZWFkL3dyaXRlIGFjY2VzcyB3aXRoDQpv dGhlciBwZW9wbGUgdG9kYXkuIFRob3NlIHdpdGggZGVsZWdhdGVkIGFjY2VzcyBhY3Qgb24gdGhl aXIgb3duIGJlaGFsZiwNCndpdGggdGhlIFJPJ3MgcGVybWlzc2lvbi4gU28gdGhlIHR1cGxlIHJl cHJlc2VudGVkIGJ5IHRoZSBhY2Nlc3MgdG9rZW4NCmlzIGFjdHVhbGx5IHF1aXRlIGEgYml0IGJp Z2dlciB0aGFuIHVzdWFsLiA8YnI+DQo8YnI+DQpTaW5jZSBPQXV0aCBtYWtlcyBhIHNpbXBsaWZ5 aW5nIGFzc3VtcHRpb24gdGhhdCBnZXRzIGl0IGVudGlyZWx5IG91dCBvZg0KdGhpcyBzb3J0IG9m IGJ1c2luZXNzLCB0aGUgcHJvY2VzcyBvZiB0cnlpbmcgdG8gc2hvZWhvcm4gdGhpcyB1c2UgY2Fz ZQ0KaW50byBhIHNpbmdsZSBwbGFpbiBPQXV0aCBmbG93IG1heSBlbmQgYmFkbHkuIEJldHRlciB3 b3VsZCBiZSBhbiBleHBsaWNpdA0KcmVjb2duaXRpb24gb2YgdGhlIHN5bW1ldHJ5IG9mIEFsaWNl ICh3aXRoIGhlciB1c2VyIGFnZW50KSBvbiBvbmUgc2lkZSwNCmFuZCBib2Igd2l0aCBoaXMgY2xp ZW50IG9uIHRoZSBvdGhlciBzaWRlLiBOb3QgdG8gc291bmQgbGlrZSBhIGJyb2tlbiByZWNvcmQs DQpidXQgdGhlIFVNQSBtb2RlbCB0YWtlcyB0aGlzIGZ1bGx5IGludG8gYWNjb3VudCBhbmQgaGFz IGV2ZW4gZ29uZSBhIGZhaXINCndheSBkb3duIHRoZSBwYXRoIG9mIGNvbnNpZGVyaW5nIHRoZSBj b250cmFjdHVhbCBhbmQgbGVnYWwgaW1wbGljYXRpb25zDQpvZiBzdWNoIGF1dGhvcml6YXRpb24u IDxicj4NCjxicj4NClNpbmNlIHRoZSBjbGllbnQgKGFsb25nIHdpdGggaXRzIG9wZXJhdG9yKSBo YXMgdG8gcmVnaXN0ZXIgb24gdGhlIEFTIHNpZGUNCmFueXdheSwgaGF2aW5nIGEgY2xlYW4gbW9k ZWwgd2hlcmUgaXQgY2FuIGRvIHRoYXQgd2l0aG91dCB0aGUgUk8ncyBzeW5jaHJvbm91cw0KcHJl c2VuY2Ugd291bGQgYmUgaWRlYWwuIE90aGVyd2lzZSBJIHN1c3BlY3QgaXQncyBpbXByYWN0aWNh bCBpbiBub3JtYWwNCnVzZS4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jODg4ODg4 IGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkV2ZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+IDxicj4NCjxicj4NCk9uIDkgT2N0IDIwMTIsIGF0IDY6NDkgUE0sIDwvZm9udD48 YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhvdS5zdWppbmdAenRlLmNv bS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCndyb3Rl OiA8YnI+DQo8YnI+DQo8YnI+DQpIaaOsUHJhYmF0aCA8YnI+DQo8L2ZvbnQ+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM3JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+UHJhYmF0aCBTaXJpd2FyZGVuYSAmbHQ7PC9iPjwvZm9udD48YSBo cmVmPW1haWx0bzpwcmFiYXRoQHdzbzIuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNv bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PHU+cHJhYmF0aEB3c28yLmNvbTwvdT48L2I+ PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEyLTEwLTA5IDIwOjM1 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0 aD02MiU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTglPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkxJT48YSBocmVmPW1haWx0bzp6aG91LnN1 amluZ0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFj ZT0ic2Fucy1zZXJpZiI+PHU+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63L zTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+RXZlIE1h bGVyICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZXZlQHhtbGdycmwuY29tIHRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ZXZlQHhtbGdy cmwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZndDss DQo8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86b2F1dGhAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5vYXV0aEBpZXRmLm9yZzwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4sDQo8L2ZvbnQ+PGEg aHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+b2F1dGgtYm91bmNlc0BpZXRm Lm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+UmU6IFJlOiBSZTogUmU6IFtPQVVUSC1XR10gUmVzb3VyY2UNCm93bmVy IGluaXRpYXRlZCBPQXV0aCBkZWxlZ2F0aW9uPC9mb250PjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6 ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3Rh YmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIE1vbiwgT2N0IDgsIDIwMTIgYXQg NjoyNCBQTSwgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNu IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+ PHU+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTogPGJyPg0KPGJyPg0KSGmjrCBQcmFiYXRoIDxicj4N Cjxicj4NCk15IHF1ZXN0aW9uIGlzIHNpbmNlIGNsaWVudC1pZCBpcyBwdWJsaWMsIHRoZW4gaXQg aXMgYSB3YXN0ZSB0byBnZXQgaXQNCmJ5IGdyYW50aW5nIGFuIGFjY2Vzcy10b2tlbi4gPGJyPg0K QW5kIGluIHN0ZXAgMi4mcXVvdDtSZXNvdXJjZSBPd25lciBncmFudHMgYWNjZXNzIHRvIGEgc2Vs ZWN0ZWQgQ2xpZW50JnF1b3Q7LA0KUk8gJm5ic3A7bG9naW5zIGluIHRvIHNlbGVjdCBjbGllbnRz IHRvIGJlIGRlbGVnYXRlZCwgPGJyPg0KYW5kIFJTIHJlZGlyZWN0cyBSTyB0byBBUyB0byBncmFu dCBhY2Nlc3MgdG9rZW4gdG8gY2xpZW50LCB0byBteSB1bmRlcnN0YW5kaW5nLA0KaW4gdGhpcyBw cm9jZXNzIFJPIG5lZWRzIHRvIGF1dGhlbnRpY2F0ZSB0byBSUyBhbmQgdGhlbiBhdXRoZW50aWNh dGUgPGJyPg0KdG8gQVMsIGl0IGlzIGEgYml0IGNvbXBsaWNhdGVkLiA8YnI+DQo8YnI+DQpJbiBm YWN0IEkgZGlkIG5vdCB3YW50IHRvIGRpc3R1cmIgbm9ybWFsIE9BdXRoIGZsb3cuLiBCVFcgeWVz Li4gaXQgYWRkcw0Kc29tZSBvdmVyaGVhZC4uIFNvIC0gSSB3b3VsZCBsaWtlIHRvIG1vZGlmeSBp dCAtIHdoZXJlIHRoZSBSZXNvdXJjZSBTZXJ2ZXINCnNlbmRzIHRoZSByZXNvdXJjZV9vd25lcl9p bml0aWF0ZWQgYXMgdGhlIHNjb3BlIC0gYW5kIGJhc2VkIG9uIHRoZSBzY29wZQ0KQVMgcmV0dXJu cyBiYWNrIGNsaWVudF9pZCB0b2dldGhlciB3aXRoIHRoZSBhY2Nlc3NfdG9rZW4gaXQgc2VsZi4g PGJyPg0KIDxicj4NCjxicj4NCkkgd29uZGVyIGlmIHRoZSBmb2xsb3dpbmcgdHdvIHByb2Nlc3Nl cyBjb3VsZCBzYXRpc2Z5IHlvdXIgY2FzZTogPGJyPg0KPGJyPg0KUHJvY2VzcyBPbmU6IDxicj4N CjEuIFJlc291cmNlIE93bmVyIHJlZ2lzdGVycyB0by1iZS1kZWxlZ2F0ZWQgY2xpZW50cyBhbmQg Y29ycmVzcG9uZGluZyBSU3MNCmF0IEFTLCBpLmUuLCBhIGxvbmcgdGVybSBkZWxlZ2F0aW9uIGNv bnRyYWN0IGlzIHN0b3JlZCBhdCBBUyA8YnI+DQo8YnI+DQoyLiBXaGVuIFJlc291cmNlIE93bmVy IHJlcXVlc3RzIENsaWVudCB0byBhY2Nlc3MgaXRzIHJlc291cmNlIGF0IFJTLCBDbGllbnQNCmlz IGRpcmVjdGVkIGJ5IFJTIHRvIEFTIHRvIG9idGFpbiBhY2Nlc3MtdG9rZW4gPGJyPg0KMy4gQ2xp ZW50IGFjY2Vzc2VzIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2Ugb24gYmVoYWxmIG9mIHRoZSBSZXNv dXJjZSBPd25lci4NCjxicj4NCjxicj4NClByb2Nlc3MgVHdvOiA8YnI+DQoxLiBSTyByZWdpc3Rl cnMgdG8tYmUtZGVsZWdhdGVkIGNsaWVudHMgYXQgUlMsIGkuZS4sIGEgbG9uZyB0ZXJtIGRlbGVn YXRpb24NCmNvbnRyYWN0IGlzIHN0b3JlZCBhdCBSUyA8YnI+DQoyLiBXaGVuIFJlc291cmNlIE93 bmVyIHJlcXVlc3RzIENsaWVudCB0byBhY2Nlc3MgaXRzIHJlc291cmNlIGF0IFJTLCBDbGllbnQN CmlzIGRpcmVjdGVkIGJ5IFJTIHRvIEFTIHRvIG9idGFpbiBhY2Nlc3MtdG9rZW4sQVMgbWF5IHJl cXVlc3QgUk8gdG8gYXV0aGVudGljYXRlDQphbmQgY29uZmlybSB0aGUgPGJyPg0KYWNjZXNzLXRv a2VuIHJlcXVlc3QgPGJyPg0KMy4gQ2xpZW50IGFjY2Vzc2VzIHRoZSBwcm90ZWN0ZWQgcmVzb3Vy Y2Ugb24gYmVoYWxmIG9mIHRoZSBSZXNvdXJjZSBPd25lci4NCiZuYnNwOyA8YnI+DQo8YnI+DQo8 YnI+DQpUaGVyZSBuZWVkcyB0byBiZSBhbiBzdGVwIHRvIGZhY2lsaXRhdGUgY2xpZW50IHJlZ2lz dHJhdGlvbi4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCkNsaWVudCBjb3VsZCBoYXZlIHJlZ2lzdGVyZWQgYXQgQVMuPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQpSTyBqdXN0IHNlbGVjdCBjbGllbnRzIGZyb20gYXZhaWxh YmxlIGNsaWVudHMgbGlzdC4gPGJyPg0KVGhpcyBmYWNpbGl0YXRpbmcgc3RlcCBzdGlsbCBuZWVk ZWQ/PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjxicj4NClRo YW5rcyAmYW1wOyByZWdhcmRzLCA8YnI+DQotUHJhYmF0aCA8YnI+DQogJm5ic3A7PGJyPg0KPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIj48YnI+DQo8YnI+DQpFdmUgTWFsZXIgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3LnhtbGdycmwuY29tL2Jsb2cgdGFyZ2V0PV9ibGFu az48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIj48dT5odHRwOi8vd3d3Lnht bGdycmwuY29tL2Jsb2c8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9dGVsOiUyQjElMjA0MjUl MjAzNDUlMjA2NzU2IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i Q291cmllciI+PHU+KzENCjQyNSAzNDUgNjc1NjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJDb3VyaWVyIj4gJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48YSBocmVm PWh0dHA6Ly93d3cudHdpdHRlci5jb20veG1sZ3JybCB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIiPjx1Pmh0dHA6Ly93d3cudHdpdHRlci5jb20veG1s Z3JybDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQpUaGFua3MgJmFtcDsgUmVnYXJk cyw8YnI+DQpQcmFiYXRoIDxicj4NCjxicj4NCk1vYmlsZSA6ICs5NCA3MSA4MDkgNjczMiA8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPGJy Pg0KPC91PjwvZm9udD48YSBocmVmPWh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbS8gdGFyZ2V0 PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRw Oi8vYmxvZy5mYWNpbGVsb2dpbi5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cDov L3JhbXBhcnRmYXEuY29tLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbTwvdT48L2ZvbnQ+PC9hPjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQ291cmllciI+PGJyPg0KPGJyPg0KRXZlIE1hbGVyICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxh IGhyZWY9aHR0cDovL3d3dy54bWxncnJsLmNvbS9ibG9nPjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9IkNvdXJpZXIiPjx1Pmh0dHA6Ly93d3cueG1sZ3JybC5jb20vYmxvZzwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIj48YnI+DQorMSA0MjUgMzQ1IDY3NTYgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48YSBocmVmPWh0dHA6Ly93d3cudHdpdHRl ci5jb20veG1sZ3JybD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIj48dT5o dHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmw8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJDb3VyaWVyIj48YnI+DQpFdmUgTWFsZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGEgaHJlZj1o dHRwOi8vd3d3LnhtbGdycmwuY29tL2Jsb2c+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i Q291cmllciI+PHU+aHR0cDovL3d3dy54bWxncnJsLmNvbS9ibG9nPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIiPjxicj4NCisxIDQyNSAzNDUgNjc1NiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgPC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy50d2l0dGVyLmNvbS94 bWxncnJsPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIiPjx1Pmh0dHA6Ly93 d3cudHdpdHRlci5jb20veG1sZ3JybDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJD b3VyaWVyIj48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo= --=_alternative 0030216448257A94_=-- From hardjono@mit.edu Thu Oct 11 08:44:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694B721F86B5 for ; Thu, 11 Oct 2012 08:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+Aon5bv+sv9 for ; Thu, 11 Oct 2012 08:44:10 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9536121F8442 for ; Thu, 11 Oct 2012 08:44:09 -0700 (PDT) X-AuditID: 1209190d-b7f906d0000008de-fb-5076e948e71b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id DF.5B.02270.849E6705; Thu, 11 Oct 2012 11:44:09 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q9BFi6sP028950; Thu, 11 Oct 2012 11:44:06 -0400 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (OC11EXEDGE3.EXCHANGE.MIT.EDU [18.9.3.21]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id q9BFi1iu006088; Thu, 11 Oct 2012 11:44:04 -0400 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 11 Oct 2012 11:43:28 -0400 Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.236]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.02.0309.002; Thu, 11 Oct 2012 11:44:03 -0400 From: Thomas Hardjono To: "oauth@ietf.org WG" , "zhou.sujing@zte.com.cn" , "Eve Maler (eve@xmlgrrl.com)" Thread-Topic: [OAUTH-WG] Resource owner initiated OAuth delegation Thread-Index: AQHNpzVvEH6B9O1eBUmhRafSRW+Bt5ezY7eAgAAFboCAAB2YAIAAL5aAgABXnQCAAC4qAA== Date: Thu, 11 Oct 2012 15:44:03 +0000 Message-ID: <5E393DF26B791A428E5F003BB6C5342A108CD966@OC11EXPO24.exchange.mit.edu> References: <2A09D860-61F3-49F2-901D-C7CD8C0571FD@xmlgrrl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [18.111.114.85] Content-Type: multipart/signed; boundary="----=_NextPart_000_0102_01CDA7A5.B5A9D0E0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUgTYRzHe+628yaenXO2R2cvrrJIZ29KohUaBAaRo6DCf+pqlxttp91t Q41CejGoyN4ot6JpaIStFCsqMWmrfMd8yzAo2lIp14ZBlGZZdztX/vf5Pd/v8/3ej3twVG7D 4nADY6ZZhjKqsXCJXBazWLPls1W7yp+YHuipAent/jEs/bmzPCwLzamunkRymk+8xnKczRMS LZoXvl5HGw1Wml25cW+43jbyHSv8YANFZ4aG0VJw7yQ4DWQ4JFPh+VGvVOR5sOd9HXYahONy shnAzqv3gTg8A/DE1JBUHFoBPF7Xj4jDIwBtv27M2O4A+PxRrUQIw8jlsHvqaZggKMhKAH2B 0WBLNJkNA40vMIEV5CZ4srSNZ5znnfDY4ALhWEIuhZWT44jABLkd3m2uQcWCUwA6KsqDgozc AdvqXcEywH/5jw5n8BwllfDtsAMRN1JAT28nFtpuutEzwwmw0xcI7oOS5QA2lfmlYlsUbLcN S84DpX1Wln22zz7LJ5qSodd1N0zkJHiryoeKnAkrfrowkRPg5TOeGU8a9L38CioBXgvm60wl GhNlMHL0fg23n2IYmtWsSTEZzCm0ztIAgn89lngMAi61G5A4UEcQE08sWrmUsnLFJjeIxRF1 DBH5yaqVR+4r0BXrKU6/h7UYac4NlvBd3vo7PSBOwhQwtFpBnO3jfYSOKi6h2YKQTYVL1Epi QDeUKyfzKTN9kKYLaTakxuO4GhIqoSCKpfPpogMGo/m/jOAyN4B4BB/OCh6CK6RMnCFf1DtA QpySWC4IpCDoLcy/u6EXPQaU/FrRxBzBFcG/93+3x/hghA+Ov2gWgs3UfymuFGx6ldRzSSeF I8lX+8oXMRfc+wYg3bJMmtjvmfvGe3ROYmvAVbH1sJ0pOXROccTxUHWhV9qybTLSUzcwyGUh C/StDVfWNvm7qnRdC7NvorujQHyGNqPsz7XYjHfdSUsyczUyM7Lu4+bbfdedZanuY+N531QP 0jK//ObWTe9ybEhVSzg9tXoFynLUX7+tsfSsAwAA Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 15:44:11 -0000 ------=_NextPart_000_0102_01CDA7A5.B5A9D0E0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Apologies for jumping in late. > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of zhou.sujing@zte.com.cn > Sent: Thursday, October 11, 2012 4:45 AM > To: Eve Maler > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation >=20 >=20 > Hi,Eve >=20 > "Having an RO literally being present to register a client operated by > some third party still seems like an unnecessary constraint to me if > the alternative is for RO to configure their preferences and then move > on." >=20 > --I didn't catch the significance of it either. But I think Prabath's > idea is not RO-initiated client registeration, but RO-initiated access > token delegation. > Let RO itself decide who is to be delegated is reasonable, and could > be commonly seen in everday life. > For example, I deposit my child at kindergarden, then when someone > tries to take him outside of the kindergarden, the teacher will inform > me "do you authorize this guy do it"---that is what OAuth currently do; > But I may prefer not to be disturbed too often, I just send > delegation statement to a few of persons, e.g., grandparents of my > child, then when someone tries to take my child outside of the > kindergarden, the teacher will ask him/her to show my delegation > statement, no statement, no taking my child. ----that my understanding > of RO-initiated delegation. What may not be clear up-front from reading the UMA core spec is that there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting Party) and Bob's portal/platform (Requester)). Here's a more accurate picture: - I deposit my Child at the Kindergarten. - I delegate my old Grandmother to pick up the Child. - My Grandmother takes a taxi. - The taxi Driver acts as proxy to my old Grandmother who stays in the taxi. - The taxi Driver needs to show 2 forms of Delegation to the Teacher. - The Taxi driver walks the Child to the taxi. Bear in mind that my Grandmother now has to manage the delegation she gave the taxi Driver (plus the Scopes involved). /thomas/ > Eve Maler > 2012-10-11 11:31 > =CA=D5=BC=FE=C8=CB > zhou.sujing@zte.com.cn > =B3=AD=CB=CD > "oauth@ietf.org WG" , Prabath Siriwardena > > =D6=F7=CC=E2 > Re: [OAUTH-WG] Resource owner initiated OAuth delegation >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ah, right. I think I got this more correct in my initial post than in > this last one. Here's how I'd address this: RO Alice controls the > access by client/requester Bob by virtue of consenting at access token > issuance time in Prabath's proposal, vs. setting policies that direct > an online service to issue it when Bob approaches in UMA. Another way > to say this is that access is RO-initiated in the first case and, > perhaps, RO-directed in the second. Having an RO literally being > present to register a client operated by some third party still seems > like an unnecessary constraint to me if the alternative is for RO to > configure their preferences and then move on. >=20 > (Note that if the RO and the requesting party are the same person, the > UMA flow looks pretty much like a regular OAuth flow because Alice can > configure a policy that says "Only alice@gmail can get full-scope > access to this resource", and if Alice herself shows up using any > client and can prove she's alice@gmail (e.g. through OpenID Connect > claims, something we've already profiled), she's good to go.) >=20 > Eve >=20 > On 10 Oct 2012, at 5:40 PM, zhou.sujing@zte.com.cn wrote: >=20 >=20 > Hi, Eve, > The requester you described corresponds to Client in OAuth, so it is > still client initiated delegation, not what Prabath wants. >=20 > Eve Maler > 2012-10-11 06:54 >=20 > =CA=D5=BC=FE=C8=CB > Prabath Siriwardena > =B3=AD=CB=CD > zhou.sujing@zte.com.cn, "oauth@ietf.org WG" > =D6=F7=CC=E2 > Re: [OAUTH-WG] Resource owner initiated OAuth delegation >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Sure. We'll ultimately be publishing some case studies that will > hopefully make this clearer, but the key place to start in the spec is > here: >=20 > http://docs.kantarainitiative.org/uma/draft-uma-core.html#r-h-attempt- > access >=20 > ".... The requester typically attempts to access the desired resource > at the host directly (for example, when a human operator of the > requester software clicks on a thumbnail representation of the > resource). The requester is expected to discover, or be provisioned or > configured with, knowledge of the protected resource and its location > out of band. Further, the requester is expected to acquire its own > knowledge about the application-specific methods made available by the > host for operating on this protected resource (such as viewing it with > a GET method, or transforming it with some complex API call) and the > possible scopes of access." >=20 > So the requester can initiate the request, with the following > preconditions: >=20 > - The host (RS) has registered this resource as protected with the > authorization manager (AS). > - The requester (client)/requesting party has learned the location and > applicable API details of the resource out of band. >=20 > The interactions among the host (RS), AM (AS), and requester (client -- > potentially operated by a third party who is not the RO) are protected > with various tokens. This is illustrated in the introduction with ASCII > art... >=20 > http://docs.kantarainitiative.org/uma/draft-uma-core.html#introduction >=20 > The actual protected resource requires a "requester permission token" > (RPT) associated with suitable authorization data. This is an UMA- > specific construct -- admittedly not a true OAuth flow, though inspired > by it! The AM presents a protection API to the host for registering > protected resources; the API is protected by a plain-vanilla OAuth > token called a protection API token (PAT). The AM also presents an > authorization API to the requester, which is protected by a plain- > vanilla OAuth token called an authorization API token (AAT). We're > counting on dynamic client registration to be in place wherever > deployers want true loose coupling. >=20 > When the requester initiates a request, if it has no token at all, the > host directs it to the AM to get first an AAT (which conveys Bob's > authorization to use it and the AM in conveying identity claims to win > authorization), and ultimately an RPT (which convey's Alice's > authorization for Bob and this requester app to access the resource > with specific scopes). Of course we're talking about an UMA-enabled > requester here, but it can literally initiate an access request with > zero tokens and ultimately get somewhere. >=20 > We'll be demoing this whole thing next Wednesday in the webinar, > including the dynamic client reg, the PAT, AAT, and RPT, the UX for the > various parties interacting with systems, and even interesting app- > level enhancements like notifying Alice that Bob has made an access > attempt and inviting her to set up policies that let him in. >=20 > Eve >=20 > On 10 Oct 2012, at 3:35 PM, Prabath Siriwardena > wrote: >=20 > Hi Eve, >=20 > I have gone through UMA spec but failed to find any case which covers > this scenario - in a resource owner initiated manner.. >=20 > Can you please give some pointers..? >=20 > Thanks & regards, > -Prabath >=20 > On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler wrote: > There are a number of implicit actions happening here that ideally > should be accounted for. If Alice is the RO and Bob is operating the > client, then when Bob accesses the protected resource it may not just > be "on Alice's behalf" -- think of how people share calendar read/write > access with other people today. Those with delegated access act on > their own behalf, with the RO's permission. So the tuple represented by > the access token is actually quite a bit bigger than usual. >=20 > Since OAuth makes a simplifying assumption that gets it entirely out of > this sort of business, the process of trying to shoehorn this use case > into a single plain OAuth flow may end badly. Better would be an > explicit recognition of the symmetry of Alice (with her user agent) on > one side, and bob with his client on the other side. Not to sound like > a broken record, but the UMA model takes this fully into account and > has even gone a fair way down the path of considering the contractual > and legal implications of such authorization. >=20 > Since the client (along with its operator) has to register on the AS > side anyway, having a clean model where it can do that without the RO's > synchronous presence would be ideal. Otherwise I suspect it's > impractical in normal use. >=20 > Eve >=20 > On 9 Oct 2012, at 6:49 PM, zhou.sujing@zte.com.cn wrote: >=20 >=20 > Hi=A3=ACPrabath > Prabath Siriwardena > 2012-10-09 20:35 >=20 > =CA=D5=BC=FE=C8=CB > zhou.sujing@zte.com.cn > =B3=AD=CB=CD > Eve Maler , oauth@ietf.org, oauth-bounces@ietf.org > =D6=F7=CC=E2 > Re: Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Mon, Oct 8, 2012 at 6:24 PM, wrote: >=20 > Hi=A3=AC Prabath >=20 > My question is since client-id is public, then it is a waste to get it > by granting an access-token. > And in step 2."Resource Owner grants access to a selected Client", RO > logins in to select clients to be delegated, > and RS redirects RO to AS to grant access token to client, to my > understanding, in this process RO needs to authenticate to RS and then > authenticate > to AS, it is a bit complicated. >=20 > In fact I did not want to disturb normal OAuth flow.. BTW yes.. it adds > some overhead.. So - I would like to modify it - where the Resource > Server sends the resource_owner_initiated as the scope - and based on > the scope AS returns back client_id together with the access_token it > self. >=20 >=20 > I wonder if the following two processes could satisfy your case: >=20 > Process One: > 1. Resource Owner registers to-be-delegated clients and corresponding > RSs at AS, i.e., a long term delegation contract is stored at AS >=20 > 2. When Resource Owner requests Client to access its resource at RS, > Client is directed by RS to AS to obtain access-token > 3. Client accesses the protected resource on behalf of the Resource > Owner. >=20 > Process Two: > 1. RO registers to-be-delegated clients at RS, i.e., a long term > delegation contract is stored at RS > 2. When Resource Owner requests Client to access its resource at RS, > Client is directed by RS to AS to obtain access-token,AS may request RO > to authenticate and confirm the > access-token request > 3. Client accesses the protected resource on behalf of the Resource > Owner. >=20 >=20 > There needs to be an step to facilitate client registration. > Client could have registered at AS. > RO just select clients from available clients list. > This facilitating step still needed? >=20 > Thanks & regards, > -Prabath >=20 >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 >=20 >=20 >=20 >=20 > -- > Thanks & Regards, > Prabath >=20 > Mobile : +94 71 809 6732 >=20 > http://blog.facilelogin.com > http://RampartFAQ.com >=20 >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 >=20 >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl ------=_NextPart_000_0102_01CDA7A5.B5A9D0E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP4DCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTMMIIDtKADAgECAhB4Uq7mlIth1FJ90gEtCu8wMA0G CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy IENBIC0gRzMwHhcNMTIwMzA2MDAwMDAwWhcNMTMwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13 d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9u bzEfMB0GCSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAmPCe+VCa3OQBiPsHUyh69qmKngwP6dHrXQtHphyr1P9LnMHdF+DletpaSm1b4HXjqbzm Ne/dj5169ZzwMjFdl3cVYGbZTvILmHNXH0kSlYl4NM/59ri+UBnV3oBnXg+g3Vhet6MDWJn/7exV AY4u5SpM7I+b+yQwDlTT90rJbXcCAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYL YIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAL BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh bElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAthQJhe+BCY99zTBcAG73fFOmROKAFQyQLxzV mJLBy8HV2hNXVA8qL87UpbBLcWT3+qDmMYn70X3Hhj+givCw0hLLeEpOWWRtXSuGt7MNrjQR1sNz Zl+NJQN+S9kl1AzYMec19OE8D+5A8WbOna8aWhGmMISqwJ3FBt6VUFIosTUGTHLI9H+LrgENQMif jCrY2PoLZvsgdQRtwhYTMbbeSLWuHILpZn2zEluSU6drzaTBPIA5uOUAtwCPRfocAzTh/mvfJ51y MNoLjFeZaovhhUdeBYJaI78y55A0nBsGyYQvYdESuqJf1UCGIK76M3c37q5YZOvmVA6sIloOcWk1 wzCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq +mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9Ix slQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMD rho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n 0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UC AwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4a HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIw YKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUY MCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEf MB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD 9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykg MTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0g RzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJ bOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeL eo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs 6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I 0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHML sbyg2lJY3QoOf8GCMYIEuDCCBLQCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk dWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQeFKu5pSLYdRSfdIBLQrvMDAJBgUrDgMCGgUAoIIDGzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEwMTExNTQ0MDJaMCMG CSqGSIb3DQEJBDEWBBQYQUtGBzW+08U4u3ZeZ+dA0a8sADCBqwYJKoZIhvcNAQkPMYGdMIGaMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3 DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCCAQMGCSsGAQQBgjcQBDGB9TCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhB4 Uq7mlIth1FJ90gEtCu8wMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQeFKu5pSLYdRSfdIBLQrvMDANBgkq hkiG9w0BAQEFAASBgDtRMvL3LkivyN9daWI7o1nOh0VwnOKEEtGguhH7c6IW4LvsCCRSBhXlaZU5 OYiAEYbLN9jEy5EVtmPD75Uz8CCl2GEYhXRBplD0VqgAfETRB3tJrEJTzFYH0rhc8+0U3vdtFBh1 4u9JoLIVuBZJLEriZKpNIFspySrfsFXRU2y7AAAAAAAA ------=_NextPart_000_0102_01CDA7A5.B5A9D0E0-- From eve@xmlgrrl.com Thu Oct 11 09:59:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A3A21F8619 for ; Thu, 11 Oct 2012 09:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, J_CHICKENPOX_23=0.6, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7vDewdq62fa for ; Thu, 11 Oct 2012 09:59:56 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id C064521F8516 for ; Thu, 11 Oct 2012 09:59:56 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q9BGxsMh018867 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Oct 2012 09:59:54 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=GB2312 From: Eve Maler In-Reply-To: <5E393DF26B791A428E5F003BB6C5342A108CD966@OC11EXPO24.exchange.mit.edu> Date: Thu, 11 Oct 2012 09:59:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <096AEA61-8DD7-416D-A73D-16ACFF39B64C@xmlgrrl.com> References: <2A09D860-61F3-49F2-901D-C7CD8C0571FD@xmlgrrl.com> <5E393DF26B791A428E5F003BB6C5342A108CD966@OC11EXPO24.exchange.mit.edu> To: Thomas Hardjono X-Mailer: Apple Mail (2.1499) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 16:59:58 -0000 If the client/requesting party is literally acting on behalf of the = initial RO, then it would seem to me that this is closer to the = discussions of "redelegation" and Twitter Echo and such from the past. = UMA's use cases have to do with authorizing delegated access that is = performed on behalf of the client itself (the word "autonomous" from = OAuth 1.0 springs to mind). Eve On 11 Oct 2012, at 8:44 AM, Thomas Hardjono wrote: > Apologies for jumping in late. >=20 >=20 >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf >> Of zhou.sujing@zte.com.cn >> Sent: Thursday, October 11, 2012 4:45 AM >> To: Eve Maler >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation >>=20 >>=20 >> Hi,Eve >>=20 >> "Having an RO literally being present to register a client operated > by >> some third party still seems like an unnecessary constraint to me if >> the alternative is for RO to configure their preferences and then > move >> on." >>=20 >> --I didn't catch the significance of it either. But I think > Prabath's >> idea is not RO-initiated client registeration, but RO-initiated > access >> token delegation. >> Let RO itself decide who is to be delegated is reasonable, and > could >> be commonly seen in everday life. >> For example, I deposit my child at kindergarden, then when someone >> tries to take him outside of the kindergarden, the teacher will > inform >> me "do you authorize this guy do it"---that is what OAuth currently > do; >> But I may prefer not to be disturbed too often, I just send >> delegation statement to a few of persons, e.g., grandparents of my >> child, then when someone tries to take my child outside of the >> kindergarden, the teacher will ask him/her to show my delegation >> statement, no statement, no taking my child. ----that my > understanding >> of RO-initiated delegation. >=20 > What may not be clear up-front from reading the UMA core spec is that > there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting > Party) and Bob's portal/platform (Requester)). >=20 > Here's a more accurate picture: >=20 > - I deposit my Child at the Kindergarten. > - I delegate my old Grandmother to pick up the Child. > - My Grandmother takes a taxi. > - The taxi Driver acts as proxy to my old Grandmother who stays in the > taxi. > - The taxi Driver needs to show 2 forms of Delegation to the Teacher. > - The Taxi driver walks the Child to the taxi. >=20 > Bear in mind that my Grandmother now has to manage the delegation she > gave the taxi Driver (plus the Scopes involved). >=20 > /thomas/ >=20 >=20 >=20 >=20 >> Eve Maler >> 2012-10-11 11:31 >> =CA=D5=BC=FE=C8=CB >> zhou.sujing@zte.com.cn >> =B3=AD=CB=CD >> "oauth@ietf.org WG" , Prabath Siriwardena >> >> =D6=F7=CC=E2 >> Re: [OAUTH-WG] Resource owner initiated OAuth delegation >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Ah, right. I think I got this more correct in my initial post than > in >> this last one. Here's how I'd address this: RO Alice controls the >> access by client/requester Bob by virtue of consenting at access > token >> issuance time in Prabath's proposal, vs. setting policies that > direct >> an online service to issue it when Bob approaches in UMA. Another > way >> to say this is that access is RO-initiated in the first case and, >> perhaps, RO-directed in the second. Having an RO literally being >> present to register a client operated by some third party still > seems >> like an unnecessary constraint to me if the alternative is for RO to >> configure their preferences and then move on. >>=20 >> (Note that if the RO and the requesting party are the same person, > the >> UMA flow looks pretty much like a regular OAuth flow because Alice > can >> configure a policy that says "Only alice@gmail can get full-scope >> access to this resource", and if Alice herself shows up using any >> client and can prove she's alice@gmail (e.g. through OpenID Connect >> claims, something we've already profiled), she's good to go.) >>=20 >> Eve >>=20 >> On 10 Oct 2012, at 5:40 PM, zhou.sujing@zte.com.cn wrote: >>=20 >>=20 >> Hi, Eve, >> The requester you described corresponds to Client in OAuth, so it > is >> still client initiated delegation, not what Prabath wants. >>=20 >> Eve Maler >> 2012-10-11 06:54 >>=20 >> =CA=D5=BC=FE=C8=CB >> Prabath Siriwardena >> =B3=AD=CB=CD >> zhou.sujing@zte.com.cn, "oauth@ietf.org WG" >> =D6=F7=CC=E2 >> Re: [OAUTH-WG] Resource owner initiated OAuth delegation >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Sure. We'll ultimately be publishing some case studies that will >> hopefully make this clearer, but the key place to start in the spec > is >> here: >>=20 >>=20 > http://docs.kantarainitiative.org/uma/draft-uma-core.html#r-h-attempt- >> access >>=20 >> ".... The requester typically attempts to access the desired > resource >> at the host directly (for example, when a human operator of the >> requester software clicks on a thumbnail representation of the >> resource). The requester is expected to discover, or be provisioned > or >> configured with, knowledge of the protected resource and its > location >> out of band. Further, the requester is expected to acquire its own >> knowledge about the application-specific methods made available by > the >> host for operating on this protected resource (such as viewing it > with >> a GET method, or transforming it with some complex API call) and the >> possible scopes of access." >>=20 >> So the requester can initiate the request, with the following >> preconditions: >>=20 >> - The host (RS) has registered this resource as protected with the >> authorization manager (AS). >> - The requester (client)/requesting party has learned the location > and >> applicable API details of the resource out of band. >>=20 >> The interactions among the host (RS), AM (AS), and requester (client > -- >> potentially operated by a third party who is not the RO) are > protected >> with various tokens. This is illustrated in the introduction with > ASCII >> art... >>=20 >>=20 > http://docs.kantarainitiative.org/uma/draft-uma-core.html#introduction >>=20 >> The actual protected resource requires a "requester permission > token" >> (RPT) associated with suitable authorization data. This is an UMA- >> specific construct -- admittedly not a true OAuth flow, though > inspired >> by it! The AM presents a protection API to the host for registering >> protected resources; the API is protected by a plain-vanilla OAuth >> token called a protection API token (PAT). The AM also presents an >> authorization API to the requester, which is protected by a plain- >> vanilla OAuth token called an authorization API token (AAT). We're >> counting on dynamic client registration to be in place wherever >> deployers want true loose coupling. >>=20 >> When the requester initiates a request, if it has no token at all, > the >> host directs it to the AM to get first an AAT (which conveys Bob's >> authorization to use it and the AM in conveying identity claims to > win >> authorization), and ultimately an RPT (which convey's Alice's >> authorization for Bob and this requester app to access the resource >> with specific scopes). Of course we're talking about an UMA-enabled >> requester here, but it can literally initiate an access request with >> zero tokens and ultimately get somewhere. >>=20 >> We'll be demoing this whole thing next Wednesday in the webinar, >> including the dynamic client reg, the PAT, AAT, and RPT, the UX for > the >> various parties interacting with systems, and even interesting app- >> level enhancements like notifying Alice that Bob has made an access >> attempt and inviting her to set up policies that let him in. >>=20 >> Eve >>=20 >> On 10 Oct 2012, at 3:35 PM, Prabath Siriwardena >> wrote: >>=20 >> Hi Eve, >>=20 >> I have gone through UMA spec but failed to find any case which > covers >> this scenario - in a resource owner initiated manner.. >>=20 >> Can you please give some pointers..? >>=20 >> Thanks & regards, >> -Prabath >>=20 >> On Wed, Oct 10, 2012 at 3:20 PM, Eve Maler wrote: >> There are a number of implicit actions happening here that ideally >> should be accounted for. If Alice is the RO and Bob is operating the >> client, then when Bob accesses the protected resource it may not > just >> be "on Alice's behalf" -- think of how people share calendar > read/write >> access with other people today. Those with delegated access act on >> their own behalf, with the RO's permission. So the tuple represented > by >> the access token is actually quite a bit bigger than usual. >>=20 >> Since OAuth makes a simplifying assumption that gets it entirely out > of >> this sort of business, the process of trying to shoehorn this use > case >> into a single plain OAuth flow may end badly. Better would be an >> explicit recognition of the symmetry of Alice (with her user agent) > on >> one side, and bob with his client on the other side. Not to sound > like >> a broken record, but the UMA model takes this fully into account and >> has even gone a fair way down the path of considering the > contractual >> and legal implications of such authorization. >>=20 >> Since the client (along with its operator) has to register on the AS >> side anyway, having a clean model where it can do that without the > RO's >> synchronous presence would be ideal. Otherwise I suspect it's >> impractical in normal use. >>=20 >> Eve >>=20 >> On 9 Oct 2012, at 6:49 PM, zhou.sujing@zte.com.cn wrote: >>=20 >>=20 >> Hi=A3=ACPrabath >> Prabath Siriwardena >> 2012-10-09 20:35 >>=20 >> =CA=D5=BC=FE=C8=CB >> zhou.sujing@zte.com.cn >> =B3=AD=CB=CD >> Eve Maler , oauth@ietf.org, oauth-bounces@ietf.org >> =D6=F7=CC=E2 >> Re: Re: Re: Re: [OAUTH-WG] Resource owner initiated OAuth delegation >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mon, Oct 8, 2012 at 6:24 PM, wrote: >>=20 >> Hi=A3=AC Prabath >>=20 >> My question is since client-id is public, then it is a waste to get > it >> by granting an access-token. >> And in step 2."Resource Owner grants access to a selected Client", > RO >> logins in to select clients to be delegated, >> and RS redirects RO to AS to grant access token to client, to my >> understanding, in this process RO needs to authenticate to RS and > then >> authenticate >> to AS, it is a bit complicated. >>=20 >> In fact I did not want to disturb normal OAuth flow.. BTW yes.. it > adds >> some overhead.. So - I would like to modify it - where the Resource >> Server sends the resource_owner_initiated as the scope - and based > on >> the scope AS returns back client_id together with the access_token > it >> self. >>=20 >>=20 >> I wonder if the following two processes could satisfy your case: >>=20 >> Process One: >> 1. Resource Owner registers to-be-delegated clients and > corresponding >> RSs at AS, i.e., a long term delegation contract is stored at AS >>=20 >> 2. When Resource Owner requests Client to access its resource at RS, >> Client is directed by RS to AS to obtain access-token >> 3. Client accesses the protected resource on behalf of the Resource >> Owner. >>=20 >> Process Two: >> 1. RO registers to-be-delegated clients at RS, i.e., a long term >> delegation contract is stored at RS >> 2. When Resource Owner requests Client to access its resource at RS, >> Client is directed by RS to AS to obtain access-token,AS may request > RO >> to authenticate and confirm the >> access-token request >> 3. Client accesses the protected resource on behalf of the Resource >> Owner. >>=20 >>=20 >> There needs to be an step to facilitate client registration. >> Client could have registered at AS. >> RO just select clients from available clients list. >> This facilitating step still needed? >>=20 >> Thanks & regards, >> -Prabath >>=20 >>=20 >>=20 >> Eve Maler > http://www.xmlgrrl.com/blog >> +1 425 345 6756 > http://www.twitter.com/xmlgrrl >>=20 >>=20 >>=20 >>=20 >>=20 >> -- >> Thanks & Regards, >> Prabath >>=20 >> Mobile : +94 71 809 6732 >>=20 >> http://blog.facilelogin.com >> http://RampartFAQ.com >>=20 >>=20 >>=20 >> Eve Maler > http://www.xmlgrrl.com/blog >> +1 425 345 6756 > http://www.twitter.com/xmlgrrl >>=20 >>=20 >>=20 >>=20 >> Eve Maler > http://www.xmlgrrl.com/blog >> +1 425 345 6756 > http://www.twitter.com/xmlgrrl >=20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From iesg-secretary@ietf.org Fri Oct 12 07:47:17 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644A421F8639; Fri, 12 Oct 2012 07:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKuQcReus1K5; Fri, 12 Oct 2012 07:47:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8099821F8665; Fri, 12 Oct 2012 07:47:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121012144716.17075.82005.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2012 07:47:16 -0700 Cc: oauth chair , oauth mailing list , RFC Editor Subject: [OAUTH-WG] Document Action: 'OAuth 2.0 Threat Model and Security Considerations' to Informational RFC (draft-ietf-oauth-v2-threatmodel-08.txt) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 14:47:17 -0000 The IESG has approved the following document: - 'OAuth 2.0 Threat Model and Security Considerations' (draft-ietf-oauth-v2-threatmodel-08.txt) as Informational RFC This document is the product of the Web Authorization Protocol Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel/ Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol. The document: o Documents any assumptions and scope considered when creating the threat model. o Describes the security features in-built into the OAuth protocol and how they are intended to thwart attacks. o Gives a comprehensive threat model for OAuth and describes the respective counter measures to thwart those threats. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document began life as a working document for the development of a Security Considerations section of the base OAuth protocol document. It quickly became far too large for that purpose, and at IETF 80 a design team was set up to extract the key points for a proper Security Considerations section, leaving the remainder for this Informational document. Throughout the development, the goal has been to include as much as possible. There's been some discussion of whether this has resulted in a document that's too long to be practical. And that concern has resulted in some pushback at the end of its life cycle, resisting the addition of new material that seemed non-specific to OAuth. There have nevertheless been some compromises made, as some participants considered it important in a few cases to highlight threats that apply to services in general, but that might be falsely construed either as not applying to OAuth, or as being mitigated in some way by OAuth. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? In the end, we have a document that's thorough and well written, and that represents the consensus of the working group, with a liberal view toward inclusion. The authors have already noted, in the acknowledgments, key contributors and reviewers. Personnel Barry Leiba is the document shepherd. Stephen Farrell is the responsible AD. RFC Editor Note - Both section 8.1 and 8.2 are called "Informative References" but 8.1 should be "Normative References" so in both the TOC and body of the document please change the title of 8.1 to "Normative References" From wwwrun@rfc-editor.org Fri Oct 12 15:48:01 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5277821F86EC; Fri, 12 Oct 2012 15:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaq3BoghYjog; Fri, 12 Oct 2012 15:48:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EAB7A21F86EA; Fri, 12 Oct 2012 15:48:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CC54572E038; Fri, 12 Oct 2012 15:42:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121012224252.CC54572E038@rfc-editor.org> Date: Fri, 12 Oct 2012 15:42:52 -0700 (PDT) Cc: oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 6749 on The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 22:48:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6749 Title: The OAuth 2.0 Authorization Framework Author: D. Hardt, Ed. Status: Standards Track Stream: IETF Date: October 2012 Mailbox: dick.hardt@gmail.com Pages: 76 Characters: 163498 Obsoletes: RFC5849 I-D Tag: draft-ietf-oauth-v2-31.txt URL: http://www.rfc-editor.org/rfc/rfc6749.txt The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. 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 Internet Official Protocol Standards (STD 1) 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 http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Fri Oct 12 15:49:38 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB6121F870E; Fri, 12 Oct 2012 15:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.025 X-Spam-Level: X-Spam-Status: No, score=-102.025 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETN+YJm4WZBs; Fri, 12 Oct 2012 15:49:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C3D6521F856D; Fri, 12 Oct 2012 15:49:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3F99B72E038; Fri, 12 Oct 2012 15:44:37 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121012224437.3F99B72E038@rfc-editor.org> Date: Fri, 12 Oct 2012 15:44:37 -0700 (PDT) Cc: oauth@ietf.org, rfc-editor@rfc-editor.org Subject: [OAUTH-WG] RFC 6750 on The OAuth 2.0 Authorization Framework: Bearer Token Usage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 22:49:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6750 Title: The OAuth 2.0 Authorization Framework: Bearer Token Usage Author: M. Jones, D. Hardt Status: Standards Track Stream: IETF Date: October 2012 Mailbox: mbj@microsoft.com, dick.hardt@gmail.com Pages: 18 Characters: 38949 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-oauth-v2-bearer-23.txt URL: http://www.rfc-editor.org/rfc/rfc6750.txt This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] This document is a product of the Web Authorization Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. 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 Internet Official Protocol Standards (STD 1) 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 http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From dick.hardt@gmail.com Fri Oct 12 16:12:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC1421F86C1 for ; Fri, 12 Oct 2012 16:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTLmIsGtOeFf for ; Fri, 12 Oct 2012 16:12:32 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 821A521F86AA for ; Fri, 12 Oct 2012 16:12:32 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so3325818pbb.31 for ; Fri, 12 Oct 2012 16:12:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=JBHZZnUsrIetehMQcVmLKYIAnoCiXUm7o/SRRomkNyY=; b=NFr3nPYCFJuUj0yVfbz5LjeUOpM/fg7JC+dndvupSTJiIbDKSHBbwwMc5kOm83l8l9 drdFa9mReUMap0qNvEzSVydD3lVglMqKe4x1v4mp9ugrmFzVNhQeHGJU5iQEHDl7Gbo8 3a4XYMu1b8sIJh5jrACBKNEvp6L+27VFqO7/ZsQxuaut0hbcYkilGhMs/E7Gx31RmbCH VjHDKcnPVwRyv3ggXwUYxQ/CnkEwTb/KEUkpzKqiFeYjNBhIvEIeGlRIDvyxH/fGjx4F SolYvqHQXtEdRDanQZWClpv+dvw7z2ePEj+iD6NjWa588LPC03Dvw30GRkdwYmO6yrcL NUaQ== Received: by 10.68.116.228 with SMTP id jz4mr16749462pbb.166.1350083552280; Fri, 12 Oct 2012 16:12:32 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id od2sm5090252pbb.28.2012.10.12.16.12.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2012 16:12:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <20121012224252.CC54572E038@rfc-editor.org> Date: Fri, 12 Oct 2012 16:12:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121012224252.CC54572E038@rfc-editor.org> To: "oauth@ietf.org WG" X-Mailer: Apple Mail (2.1499) Subject: Re: [OAUTH-WG] RFC 6749 on The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 23:12:33 -0000 Thanks everyone for all their work! We can now focus on the next layers = in the identity stack. -- Dick On Oct 12, 2012, at 3:42 PM, rfc-editor@rfc-editor.org wrote: >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6749 >=20 > Title: The OAuth 2.0 Authorization Framework=20 > Author: D. Hardt, Ed. > Status: Standards Track > Stream: IETF > Date: October 2012 > Mailbox: dick.hardt@gmail.com > Pages: 76 > Characters: 163498 > Obsoletes: RFC5849 >=20 > I-D Tag: draft-ietf-oauth-v2-31.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6749.txt >=20 > The OAuth 2.0 authorization framework enables a third-party > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and the HTTP service, or by allowing the > third-party application to obtain access on its own behalf. This > specification replaces and obsoletes the OAuth 1.0 protocol described > in RFC 5849. [STANDARDS-TRACK] >=20 > This document is a product of the Web Authorization Protocol Working = Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > 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 Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > 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. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Fri Oct 12 16:34:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CC821F849A for ; Fri, 12 Oct 2012 16:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqpnIOtv68PD for ; Fri, 12 Oct 2012 16:34:22 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id 16E5321F84A6 for ; Fri, 12 Oct 2012 16:34:21 -0700 (PDT) Received: from BL2FFO11FD011.protection.gbl (10.173.161.203) by BL2FFO11HUB027.protection.gbl (10.173.161.51) with Microsoft SMTP Server (TLS) id 15.0.516.0; Fri, 12 Oct 2012 23:35:17 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD011.mail.protection.outlook.com (10.173.161.17) with Microsoft SMTP Server (TLS) id 15.0.516.0 via Frontend Transport; Fri, 12 Oct 2012 23:35:17 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Fri, 12 Oct 2012 23:34:02 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 RFCs Completed Thread-Index: Ac2o0g5UnfkkfGxrQSWten+ni7nRyw== Date: Fri, 12 Oct 2012 23:34:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943668481BD@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943668481BDTK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(54164002)(42186003)(16406001)(33656001)(5343665001)(46102001)(47446002)(15202345001)(512954001)(74502001)(50986001)(47976001)(74662001)(15395725001)(47736001)(20776001)(1076001)(49866001)(44976002)(16826001)(4196001)(31966008)(16696001)(3846001)(4396001)(5343635001)(51856001)(5343655001)(8716001)(316001)(3746001)(6606295001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0632519F33 Subject: [OAUTH-WG] OAuth 2.0 RFCs Completed X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 23:34:23 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943668481BDTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750. Thanks to all of you who brought us to this important mileston= e! I wrote about this at http://self-issued.info/?p=3D870 and Dick wrote about= it at http://dickhardt.org/2012/10/oauth-2-0/. Now, on to approving the next set of related standards! Thanks all! -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943668481BDTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Th= e OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750.  Thanks to all of you who brought us to this important m= ilestone!

 

I = wrote about this at http://self-issued.info/?p=3D8= 70 and Dick wrote about it at http://dickhardt.org/20= 12/10/oauth-2-0/.

 

No= w, on to approving the next set of related standards!

 

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         Thanks all!=

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         -- Mike

 

--_000_4E1F6AAD24975D4BA5B1680429673943668481BDTK5EX14MBXC284r_-- From torsten@lodderstedt.net Sat Oct 13 00:20:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011A821F8681 for ; Sat, 13 Oct 2012 00:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVRTQHtZ5AJc for ; Sat, 13 Oct 2012 00:20:35 -0700 (PDT) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by ietfa.amsl.com (Postfix) with ESMTP id E32ED21F8606 for ; Sat, 13 Oct 2012 00:20:34 -0700 (PDT) Received: from [79.253.39.151] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TMw1O-0003YC-W3; Sat, 13 Oct 2012 09:20:31 +0200 Message-ID: <5079163F.1020506@lodderstedt.net> Date: Sat, 13 Oct 2012 09:20:31 +0200 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mike Jones References: <4E1F6AAD24975D4BA5B1680429673943668481BD@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943668481BD@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: multipart/alternative; boundary="------------060509030505090800030304" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 RFCs Completed X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 07:20:36 -0000 This is a multi-part message in MIME format. --------------060509030505090800030304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Great! Let's celebrate this in Atlanta :-) best regards, Torsten. Am 13.10.2012 01:34, schrieb Mike Jones: > > The OAuth 2.0 Core and Bearer specifications are now RFC 6749 > and RFC 6750 > . Thanks to all of you who > brought us to this important milestone! > > I wrote about this at http://self-issued.info/?p=870 and Dick wrote > about it at http://dickhardt.org/2012/10/oauth-2-0/. > > Now, on to approving the next set of related standards! > > Thanks all! > > -- Mike > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------060509030505090800030304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Great! Let's celebrate this in Atlanta :-)

best regards,
Torsten.

Am 13.10.2012 01:34, schrieb Mike Jones:

The OAuth 2.0 Core and Bearer specifications are now RFC 6749 and RFC 6750.  Thanks to all of you who brought us to this important milestone!

 

I wrote about this at http://self-issued.info/?p=870 and Dick wrote about it at http://dickhardt.org/2012/10/oauth-2-0/.

 

Now, on to approving the next set of related standards!

 

                                                            Thanks all!

                                                            -- Mike

 



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

--------------060509030505090800030304-- From hannes.tschofenig@gmx.net Sat Oct 13 04:46:53 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE44D21F84F3 for ; Sat, 13 Oct 2012 04:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.094 X-Spam-Level: X-Spam-Status: No, score=-102.094 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcvw4KdAqwxH for ; Sat, 13 Oct 2012 04:46:53 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E395321F84EF for ; Sat, 13 Oct 2012 04:46:52 -0700 (PDT) Received: (qmail invoked by alias); 13 Oct 2012 11:46:51 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.102]) [88.115.216.191] by mail.gmx.net (mp017) with SMTP; 13 Oct 2012 13:46:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX195EnMrxph5fhJ/JpH5zaERQpbebjMpxHBAvtLUlQ x0eymR0CKg6V03 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sat, 13 Oct 2012 14:46:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121012224252.CC54572E038@rfc-editor.org> To: Dick Hardt X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] RFC 6749 on The OAuth 2.0 Authorization Framework X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 11:46:53 -0000 Happy to see the announcement and I am looking forward to a productive = IETF meeting in Atlanta! On Oct 13, 2012, at 2:12 AM, Dick Hardt wrote: > Thanks everyone for all their work! We can now focus on the next = layers in the identity stack. >=20 > -- Dick >=20 > On Oct 12, 2012, at 3:42 PM, rfc-editor@rfc-editor.org wrote: >=20 >>=20 >> A new Request for Comments is now available in online RFC libraries. >>=20 >>=20 >> RFC 6749 >>=20 >> Title: The OAuth 2.0 Authorization Framework=20 >> Author: D. Hardt, Ed. >> Status: Standards Track >> Stream: IETF >> Date: October 2012 >> Mailbox: dick.hardt@gmail.com >> Pages: 76 >> Characters: 163498 >> Obsoletes: RFC5849 >>=20 >> I-D Tag: draft-ietf-oauth-v2-31.txt >>=20 >> URL: http://www.rfc-editor.org/rfc/rfc6749.txt >>=20 >> The OAuth 2.0 authorization framework enables a third-party >> application to obtain limited access to an HTTP service, either on >> behalf of a resource owner by orchestrating an approval interaction >> between the resource owner and the HTTP service, or by allowing the >> third-party application to obtain access on its own behalf. This >> specification replaces and obsoletes the OAuth 1.0 protocol described >> in RFC 5849. [STANDARDS-TRACK] >>=20 >> This document is a product of the Web Authorization Protocol Working = Group of the IETF. >>=20 >> This is now a Proposed Standard Protocol. >>=20 >> 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 = Internet >> Official Protocol Standards (STD 1) for the standardization state and >> status of this protocol. Distribution of this memo is unlimited. >>=20 >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> http://www.ietf.org/mailman/listinfo/ietf-announce >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>=20 >> For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >>=20 >> 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. >>=20 >>=20 >> The RFC Editor Team >> Association Management Solutions, LLC >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From internet-drafts@ietf.org Mon Oct 15 23:30:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045EC21F88F9; Mon, 15 Oct 2012 23:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTM2n5WIhacs; Mon, 15 Oct 2012 23:30:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E18A21F88F5; Mon, 15 Oct 2012 23:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121016063003.29922.81630.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 23:30:03 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-04.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 06:30:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : JSON Web Token (JWT) Author(s) : Michael B. Jones John Bradley Nat Sakimura Filename : draft-ietf-oauth-json-web-token-04.txt Pages : 24 Date : 2012-10-15 Abstract: JSON Web Token (JWT) is a means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JavaScript Object Notation (JSON) object that is digitally signed or MACed using JSON Web Signature (JWS) and/or encrypted using JSON Web Encryption (JWE). The suggested pronunciation of JWT is the same as the English word "jot". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-json-web-token-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Michael.Jones@microsoft.com Mon Oct 15 23:59:28 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E7021F877C for ; Mon, 15 Oct 2012 23:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8+Ve5Q+ybAQ for ; Mon, 15 Oct 2012 23:59:24 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id D395221F8754 for ; Mon, 15 Oct 2012 23:59:23 -0700 (PDT) Received: from mail261-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Oct 2012 06:59:22 +0000 Received: from mail261-va3 (localhost [127.0.0.1]) by mail261-va3-R.bigfish.com (Postfix) with ESMTP id 37F841300154 for ; Tue, 16 Oct 2012 06:59:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202h1d1ah1d2ahzz1033IL17326ah8275eh8275bh8275dha1495iz2fh2a8h668h839hd25hf0ah107ah1288h12a5h12bdh137ah1441h1155h) Received-SPF: pass (mail261-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail261-va3 (localhost.localdomain [127.0.0.1]) by mail261-va3 (MessageSwitch) id 1350370759137513_26062; Tue, 16 Oct 2012 06:59:19 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.253]) by mail261-va3.bigfish.com (Postfix) with ESMTP id 1FC45FC004D for ; Tue, 16 Oct 2012 06:59:19 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Oct 2012 06:59:13 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.33]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Tue, 16 Oct 2012 06:59:11 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: JOSE and JWT specs incorporating working group decisions since IETF 84 Thread-Index: Ac2ra72RfuMr8TT+S3O01zTVz7IV4A== Date: Tue, 16 Oct 2012 06:59:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366853BBD@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366853BBDTK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [OAUTH-WG] JOSE and JWT specs incorporating working group decisions since IETF 84 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 06:59:28 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366853BBDTK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable New versions of the JSON WEB {Signature,Encryption,Key,Algorithms,Token} (J= WS, JWE, JWK, JWA, JWT) specifications have been released. These versions = incorporate the decisions made by the JOSE working group during and since IETF 84. The primary change was revising the JWE format to always use AEAD encryptio= n algorithms. The companion change was defining two new composite AEAD alg= orithms "A128CBC+HS256" and "A256CBC+HS512" that use AES CBC to perform enc= ryption and matching HMAC SHA-2 algorithms to perform an integrity check on= the ciphertext and the parameters used to create it. Other than that, all changes were local in scope, with no changes to JWS - = other than changing the format of the "x5c" (X.509 Certificate Chain) from = a string containing a list of certificate values to an array of strings con= taining certificate values. Likewise, the only changes to JWT were to trac= k changes made in the specs that it uses. Having addressed all the open issues with resolutions with apparent working= group consensus, it's my hope that the working group will decide to send t= hese specifications to working group last call at IETF 85. The companion JWS JSON Serialization and JWE JSON Serialization specs were = also updated. The working group specifications are available at: * http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06 * http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06 * http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 * http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06 * http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04 The individual submission specifications are available at: * http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization= -02 * http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization= -02 The document history entries (also in the specifications) are as follows: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06 * Changed x5c (X.509 Certificate Chain) representation from being a sin= gle string to being an array of strings, each containing a single base64 en= coded DER certificate value, representing elements of the certificate chain= . * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06 * Removed the int and kdf parameters and defined the new composite AEAD= algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of A= ES CBC, which required the use of separate integrity and key derivation fun= ctions. * Included additional values in the Concat KDF calculation -- the desir= ed output size and the algorithm value, and optionally PartyUInfo and Party= VInfo values. Added the optional header parameters apu (agreement PartyUInf= o), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encry= ption PartyVInfo). Updated the KDF examples accordingly. * Promoted Initialization Vector from being a header parameter to being= a top-level JWE element. This saves approximately 16 bytes in the compact = serialization, which is a significant savings for some use cases. Promoting= the Initialization Vector out of the header also avoids repeating this sha= red value in the JSON serialization. * Changed x5c (X.509 Certificate Chain) representation from being a sin= gle string to being an array of strings, each containing a single base64 en= coded DER certificate value, representing elements of the certificate chain= . * Added an AES Key Wrap example. * Reordered the encryption steps so CMK creation is first, when require= d. * Correct statements in examples about which algorithms produce reprodu= cible results. http://tools.ietf.org/html/draft-ietf-jose-json-web-key-06 * Changed the name of the JWK RSA exponent parameter from exp to xpo so= as to allow the potential use of the name exp for a future extension that = might define an expiration parameter for keys. (The exp name is already use= d for this purpose in the JWT specification.) * Clarify that the alg (algorithm family) member is REQUIRED. * Correct an instance of "JWK" that should have been "JWK Set". * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-06 * Removed the int and kdf parameters and defined the new composite AEAD= algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of A= ES CBC, which required the use of separate integrity and key derivation fun= ctions. * Included additional values in the Concat KDF calculation -- the desir= ed output size and the algorithm value, and optionally PartyUInfo and Party= VInfo values. Added the optional header parameters apu (agreement PartyUInf= o), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encry= ption PartyVInfo). * Changed the name of the JWK RSA exponent parameter from exp to xpo so= as to allow the potential use of the name exp for a future extension that = might define an expiration parameter for keys. (The exp name is already use= d for this purpose in the JWT specification.) * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-04 * Promoted Initialization Vector from being a header parameter to being= a top-level JWE element. This saves approximately 16 bytes in the compact = serialization, which is a significant savings for some use cases. Promoting= the Initialization Vector out of the header also avoids repeating this sha= red value in the JSON serialization. * Applied changes made by the RFC Editor to RFC 6749's registry languag= e to this specification. * Reference RFC 6755 -- An IETF URN Sub-Namespace for OAuth. http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-02 * Changed to use an array of structures for per-recipient values, rathe= r than a set of parallel arrays. http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-02 * Changed to use an array of structures for per-recipient values, rathe= r than a set of parallel arrays. * Promoted Initialization Vector from being a header parameter to being= a top-level JWE element. This saves approximately 16 bytes in the compact = serialization, which is a significant savings for some use cases. Promoting= the Initialization Vector out of the header also avoids repeating this sha= red value in the JSON serialization. HTML formatted versions are available at: * http://self-issued.info/docs/draft-ietf-jose-json-web-signature-06= .html * http://self-issued.info/docs/draft-ietf-jose-json-web-encryption-0= 6.html * http://self-issued.info/docs/draft-ietf-jose-json-web-key-06.html * http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-0= 6.html * http://self-issued.info/docs/draft-ietf-oauth-json-web-token-04.ht= ml * http://self-issued.info/docs/draft-jones-jose-jws-json-serializati= on-02.html * http://self-issued.info/docs/draft-jones-jose-jwe-json-serializati= on-02.html -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366853BBDTK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

New versions of the JSON WEB {Signature,Encryption,K= ey,Algorithms,Token} (JWS, JWE, JWK, JWA, JWT) specifications have been rel= eased.  These versions incorporate the decisions made by the JOSE working group dur= ing and since IETF 84.

 

The primary change was revising the JWE format to al= ways use AEAD encryption algorithms.  The companion change was definin= g two new composite AEAD algorithms “A128CBC+HS256” and “A256CBC+HS512” that use AES CBC to perform encryption and matching HMAC SHA-2 algorithms = to perform an integrity check on the ciphertext and the parameters used to = create it.

 

Other than that, all changes were local in scope, wi= th no changes to JWS – other than changing the format of the “<= tt>x5c” (X.5= 09 Certificate Chain) from a string containing a list of certificate values to an array of strings containing certificate values.&n= bsp; Likewise, the only changes to JWT were to track changes made in the sp= ecs that it uses.

 

Having addressed all the open issues with resolution= s with apparent working group consensus, it’s my hope that the workin= g group will decide to send these specifications to working group last call= at IETF 85.

 

The companion JWS JSON Serialization and JWE JSON Se= rialization specs were also updated.

 

The working group specifications are available at:

·        http://tools.ietf.org/html/draft-ietf-jose= -json-web-signature-06

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-encryption-06

·        http://tools.ietf.org/html/draft-ietf-jose-json-= web-key-06

·        http://tools.ietf.org/html/draft-ietf-jos= e-json-web-algorithms-06

·        http://tools.ietf.org/html/draft-ietf-oauth-j= son-web-token-04

 

The individual submission specifications are availab= le at:

·        http://tools.ietf.org/html/draft-jone= s-jose-jws-json-serialization-02

·        http://tools.ietf.org/html/draft-jone= s-jose-jwe-json-serialization-02

 

The document history entries (also in the specificat= ions) are as follows:

 

http://tools.ietf.org/html/draft-ietf-jose-json-we= b-signature-06

  • Changed x5c (X.509 Certificate Chain) representation from = being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the = certificate chain.
  • Applied changes made by the RFC Editor to RFC 674= 9's registry language to this specification.

 

http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-encryption-06

  • Removed the int and kdf parameters and defined the new composite AEAD = algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AE= S CBC, which required the use of separate integrity and key derivation func= tions.
  • Included additional values in the Concat KDF calc= ulation -- the desired output size and the algorithm value, and optionally = PartyUInfo and PartyVInfo values. Added the optional header parameters apu<= /span> (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo). Updated the KDF examp= les accordingly.
  • Promoted Initialization Vector from being a heade= r parameter to being a top-level JWE element. This saves approximately 16 b= ytes in the compact serialization, which is a significant savings for some use cas= es. Promoting the Initialization Vector out of the header also avoids repea= ting this shared value in the JSON serialization.
  • Changed x5c (X.509 Certificate Chain) representation from = being a single string to being an array of strings, each containing a single base64 encoded DER certificate value, representing elements of the = certificate chain.
  • Added an AES Key Wrap example.
  • Reordered the encryption steps so CMK creation is= first, when required.
  • Correct statements in examples about which algori= thms produce reproducible results.

 

http://tools.ietf.org/html/draft-ietf-jose-json-web-key-= 06

  • Changed the name of the JWK RSA exponent parameter from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an ex= piration parameter for keys. (The exp name is already used for this purpose in the J= WT specification.)
  • Clarify that the alg (algorithm family) member is REQUIRED.
  • Correct an instance of "JWK" that shoul= d have been "JWK Set".
  • Applied changes made by the RFC Editor to RFC 674= 9's registry language to this specification.

 

http://tools.ietf.org/html/draft-ietf-jose-json-w= eb-algorithms-06

  • Removed the int and kdf parameters and defined the new composite AEAD = algorithms A128CBC+HS256 and A256CBC+HS512 to replace the former uses of AE= S CBC, which required the use of separate integrity and key derivation func= tions.
  • Included additional values in the Concat KDF calc= ulation -- the desired output size and the algorithm value, and optionally = PartyUInfo and PartyVInfo values. Added the optional header parameters apu<= /span> (agreement PartyUInfo), apv (agreement PartyVInfo), epu (encryption PartyUInfo), and epv (encryption PartyVInfo).
  • Changed the name of the JWK RSA exponent paramete= r from exp to xpo so as to allow the potential use of the name exp for a future extension that might define an ex= piration parameter for keys. (The exp name is already used for this purpose in the J= WT specification.)
  • Applied changes made by the RFC Editor to RFC 674= 9's registry language to this specification.

 

http://tools.ietf.org/html/draft-ietf-oauth-json-web-= token-04

  • Promoted Initialization Vector from being a header parameter to being a = top-level JWE element. This saves approximately 16 bytes in the compact serialization, which is a significant savings for some use cas= es. Promoting the Initialization Vector out of the header also avoids repea= ting this shared value in the JSON serialization.
  • Applied changes made by the RFC Editor to RFC 674= 9's registry language to this specification.
  • Reference RFC 6755 -- An IETF URN Sub-Namespace f= or OAuth.

 

http://tools.ietf.org/html/draft-jones-jose-j= ws-json-serialization-02

  • Changed to use an array of structures for per-recipient values, rather t= han a set of parallel arrays.

 

http://tools.ietf.org/html/draft-jones-jose-j= we-json-serialization-02

  • Changed to use an array of structures for per-recipient values, rather t= han a set of parallel arrays.
  • Promoted Initialization Vector from being a heade= r parameter to being a top-level JWE element. This saves approximately 16 b= ytes in the compact serialization, which is a significant savings for some use cas= es. Promoting the Initialization Vector out of the header also avoids repea= ting this shared value in the JSON serialization.

 

HTML formatted versions are available at:=

·        http://self-issued.info/docs/draft-= ietf-jose-json-web-signature-06.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-encryption-06.html

·        http://self-issued.info/docs/draft-ietf-j= ose-json-web-key-06.html

·        http://self-issued.info/docs/draft= -ietf-jose-json-web-algorithms-06.html

·        http://self-issued.info/docs/draft-iet= f-oauth-json-web-token-04.html

·        http://self-issued.info/docs/d= raft-jones-jose-jws-json-serialization-02.html

·        http://self-issued.info/docs/d= raft-jones-jose-jwe-json-serialization-02.html

 

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

 

--_000_4E1F6AAD24975D4BA5B168042967394366853BBDTK5EX14MBXC284r_-- From zhou.sujing@zte.com.cn Wed Oct 17 19:23:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5118B21F848F for ; Wed, 17 Oct 2012 19:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.708 X-Spam-Level: X-Spam-Status: No, score=-97.708 tagged_above=-999 required=5 tests=[AWL=2.476, BAYES_40=-0.185, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0-fwxMkZLSp for ; Wed, 17 Oct 2012 19:23:35 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 861FC21F844C for ; Wed, 17 Oct 2012 19:23:34 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id BD8AF12611C8; Thu, 18 Oct 2012 10:24:18 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q9I2NOkV086222; Thu, 18 Oct 2012 10:23:24 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: hardjono@MIT.EDU MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 18 Oct 2012 10:23:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-18 10:23:05, Serialize complete at 2012-10-18 10:23:05 Content-Type: multipart/alternative; boundary="=_alternative 000D34F448257A9B_=" X-MAIL: mse01.zte.com.cn q9I2NOkV086222 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 02:23:36 -0000 This is a multipart message in MIME format. --=_alternative 000D34F448257A9B_= Content-Type: text/plain; charset="US-ASCII" Hi, Thomas, Sorry for reply late. I somehow missed the emails from OAUTH list. "What may not be clear up-front from reading the UMA core spec is that there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting Party) and Bob's portal/platform (Requester)). Here's a more accurate picture: - I deposit my Child at the Kindergarten. - I delegate my old Grandmother to pick up the Child. - My Grandmother takes a taxi. - The taxi Driver acts as proxy to my old Grandmother who stays in the taxi. - The taxi Driver needs to show 2 forms of Delegation to the Teacher. - The Taxi driver walks the Child to the taxi. Bear in mind that my Grandmother now has to manage the delegation she gave the taxi Driver (plus the Scopes involved)." If I understand correctly, old Grandma means Bob the requesting Party, the taxi driver means Bob the requester in UMA? Not talking about UMA, Bob is not separate between roles in OAUTH, so don't have to redelegate in OAUTH? --=_alternative 000D34F448257A9B_= Content-Type: text/html; charset="US-ASCII"
Hi, Thomas,

   Sorry for reply late. I somehow missed the emails from OAUTH list.

"What may not be clear up-front from reading the UMA core spec is that
there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting
Party) and Bob's portal/platform (Requester)).

Here's a more accurate picture:

- I deposit my Child at the Kindergarten.
- I delegate my old Grandmother to pick up the Child.
- My Grandmother takes a taxi.
- The taxi Driver acts as proxy to my old Grandmother who stays in the
taxi.
- The taxi Driver needs to show 2 forms of Delegation to the Teacher.
- The Taxi driver walks the Child to the taxi.

Bear in mind that my Grandmother now has to manage the delegation she
gave the taxi Driver (plus the Scopes involved)."


If I understand correctly, old Grandma means Bob the requesting Party,
the taxi driver means Bob the requester in UMA?
Not talking  about UMA, Bob is not separate between roles in OAUTH,
so don't have to redelegate in OAUTH?
--=_alternative 000D34F448257A9B_=-- From barryleiba@gmail.com Wed Oct 17 19:25:18 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D553A21F85A0; Wed, 17 Oct 2012 19:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQ-zbS5vzQt9; Wed, 17 Oct 2012 19:25:17 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F264C21F858F; Wed, 17 Oct 2012 19:25:16 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so9059434vbb.31 for ; Wed, 17 Oct 2012 19:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=wDQUSB9tpDe14FGwx645Vg/vnew7n8nYqFeGQB6O4aE=; b=rzY++5GMc6OqwX7RSVaS0nPa7hZGiYaEfPteBu1izozhiDV8oX3vMDA/cUhjP4/ofb fDLLB3IIn0+mmvfVB6kQgp6IMPufbLHBhLS73XaHs+GOZdn7WkPXNo22dSH8WebcPRGi ypyZ7prrfaAYqaXfcIo4rCIkOZg93lHz+8rZIKqAtd2do3Sgkw+1a25gYF7efyX8XOuJ /WcOeYevY30MH5+sQPxvViYnWkNx/EbGs/06Gr4KkcKWIVJIXUiuBfQu7tjuTAYK8BGw YOhluEo8kV7W3AbBWqjV0K9UzTEFiH93lPknyQSozjviJ3vEluNu6InCEh3kSfhi8oFh DgJg== MIME-Version: 1.0 Received: by 10.220.220.5 with SMTP id hw5mr2987796vcb.53.1350527116394; Wed, 17 Oct 2012 19:25:16 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.58.28.231 with HTTP; Wed, 17 Oct 2012 19:25:16 -0700 (PDT) Date: Wed, 17 Oct 2012 22:25:16 -0400 X-Google-Sender-Auth: FotLzZ0QiWKnuBHTBtR-wzeeV4Y Message-ID: From: Barry Leiba To: http-state@ietf.org, websec@ietf.org, ietf-http-wg@w3.org, apps-discuss@ietf.org, oauth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] Input for conflict review of draft-secure-cookie-session-protocol X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: saag@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 02:25:18 -0000 A document titled "Secure Cookie Sessions for HTTP" has been submitted to the Independent Stream Editor (ISE): http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/ The IESG has been asked to review the document, as specified in RFC 5742, Section 3. The Security and Applications Area Directors are looking for input for that review. Please post any relevant comments to the Security Area list, , as soon as possible, and at least by 1 November 2012. Note: Please do NOT post responses to any of these mailing lists. Respond only to (using the subject line of this message). Please read RFC 5742, Section 3, and be aware that we are not looking for detailed comments on the document itself (see below). We specifically need input on whether this document is in conflict with work that's being done in the IETF. Look at the five possible responses specified in that section, and help us determine whether any of 2 through 5 applies. Please be specific in your response. In addition to this, we're sure that the authors and the ISE would appreciate comments about the document. If you have those, you may send them directly to the authors at and to the ISE at . General discussion of the document on these lists or the saag list will likely not get to the authors or the ISE. Barry Leiba, Applications AD From zhou.sujing@zte.com.cn Wed Oct 17 19:28:59 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AB921F8498 for ; Wed, 17 Oct 2012 19:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.053 X-Spam-Level: X-Spam-Status: No, score=-99.053 tagged_above=-999 required=5 tests=[AWL=3.545, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D47ONvlMGA13 for ; Wed, 17 Oct 2012 19:28:59 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8834B21F8480 for ; Wed, 17 Oct 2012 19:28:54 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 830D012612E9; Thu, 18 Oct 2012 10:29:37 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q9I2SeIx091813; Thu, 18 Oct 2012 10:28:41 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: eve@xmlgrrl.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 18 Oct 2012 10:28:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-18 10:28:22, Serialize complete at 2012-10-18 10:28:22 Content-Type: multipart/alternative; boundary="=_alternative 000DB0DC48257A9B_=" X-MAIL: mse01.zte.com.cn q9I2SeIx091813 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 02:28:59 -0000 This is a multipart message in MIME format. --=_alternative 000DB0DC48257A9B_= Content-Type: text/plain; charset="US-ASCII" Hi, Eve Sorry for reply late. I somehow missed the emails from OAUTH list. "If the client/requesting party is literally acting on behalf of the initial RO, then it would seem to me that this is closer to the discussions of "redelegation" and Twitter Echo and such from the past. UMA's use cases have to do with authorizing delegated access that is performed on behalf of the client itself (the word "autonomous" from OAuth 1.0 springs to mind). Eve" Can you give me the link of discussion in the past you mentioned? The usecase Hardjono rediscribed may not necessarily invloving "redelegation", a more general case would be the Babysitter directly show delegation to the Teacher and walk the child home. --=_alternative 000DB0DC48257A9B_= Content-Type: text/html; charset="US-ASCII"
Hi, Eve

   Sorry for reply late. I somehow missed the emails from OAUTH list.

   "If the client/requesting party is literally acting on behalf of the initial RO, then it would seem to me that this is closer to the discussions of "redelegation" and Twitter Echo and such from the past. UMA's use cases have to do with authorizing delegated access that is performed on behalf of the client itself (the word "autonomous" from OAuth 1.0 springs to mind). Eve"

  Can you give me the link of discussion in the past you mentioned?
  The usecase Hardjono rediscribed may not necessarily invloving "redelegation", a more general case would be the Babysitter directly show delegation to the Teacher and walk the child home.
   
--=_alternative 000DB0DC48257A9B_=-- From zhou.sujing@zte.com.cn Wed Oct 17 19:48:13 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8DC21F85B1 for ; Wed, 17 Oct 2012 19:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.363 X-Spam-Level: X-Spam-Status: No, score=-98.363 tagged_above=-999 required=5 tests=[AWL=2.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4hoArZCQT-e for ; Wed, 17 Oct 2012 19:48:13 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E096C21F85D5 for ; Wed, 17 Oct 2012 19:48:12 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id C4029126182A; Thu, 18 Oct 2012 10:48:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q9I2m0hA021211; Thu, 18 Oct 2012 10:48:00 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: eve@xmlgrrl.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 18 Oct 2012 10:47:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-18 10:47:41, Serialize complete at 2012-10-18 10:47:41 Content-Type: multipart/alternative; boundary="=_alternative 000F756148257A9B_=" X-MAIL: mse01.zte.com.cn q9I2m0hA021211 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 02:48:13 -0000 This is a multipart message in MIME format. --=_alternative 000F756148257A9B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIEV2ZQ0KDQogICBTb3JyeSBmb3IgcmVwbHkgbGF0ZS4gSSBzb21laG93IG1pc3NlZCB0aGUg ZW1haWxzIGZyb20gT0FVVEggbGlzdC4NCg0KICAgobANCihJJ20gbm90IHNlZWluZyAgWmhvdSdz IHJlc3BvbnNlcyB0byB5b3Ugb24gdGhlIGxpc3QsIHNvIEkgZG9uJ3QgaGF2ZSB0aGUgDQpvdGhl ciBwcm9wb3NhbCBoYW5keS4gQ2FuIFpob3Ugb3Igc29tZW9uZSBzaGFyZSB0aGUgbGluaz8pDQqh sQ0KeW91IG1lYW4gdGhlIGZvbGxvd2luZyBsaW5rc6O/DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA5OTU1Lmh0bWwNCg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMDk5NjcuaHRtbA0K IA0K --=_alternative 000F756148257A9B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBFdmU8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyA8L2ZvbnQ+PHR0Pjxm b250IHNpemU9Mz4mbmJzcDtTb3JyeQ0KZm9yIHJlcGx5IGxhdGUuIEkgc29tZWhvdyBtaXNzZWQg dGhlIGVtYWlscyBmcm9tIE9BVVRIIGxpc3QuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDuhsDwvZm9udD4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyPg0KPHRkIHdpZHRoPTEwMCU+PGZvbnQgc2l6ZT0zPihJJ20gbm90IHNl ZWluZyAmbmJzcDtaaG91J3MgcmVzcG9uc2VzIHRvIHlvdQ0Kb24gdGhlIGxpc3QsIHNvIEkgZG9u J3QgaGF2ZSB0aGUgb3RoZXIgcHJvcG9zYWwgaGFuZHkuIENhbiBaaG91IG9yIHNvbWVvbmUNCnNo YXJlIHRoZSBsaW5rPyk8L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+obE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnlv dSBtZWFuIHRoZSBmb2xsb3dpbmcgbGlua3OjvzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L29hdXRoL2N1cnJlbnQvbXNnMDk5NTUuaHRtbDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L29hdXRoL2N1cnJlbnQvbXNnMDk5NjcuaHRtbDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDwvZm9udD4NCg== --=_alternative 000F756148257A9B_=-- From pmhsfelix@gmail.com Thu Oct 18 09:06:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B4F21F885E for ; Thu, 18 Oct 2012 09:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.462 X-Spam-Level: X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tgnv0s9vqGYV for ; Thu, 18 Oct 2012 09:06:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1051F040A for ; Thu, 18 Oct 2012 09:06:17 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so6772393lbo.31 for ; Thu, 18 Oct 2012 09:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+Uaamfcaw3aO/p6FOcvg9yld6T1JXF1TFfQmU6O0bJ4=; b=ChE/tSAMPpQ+BOOtPCMXbdPgieRwzATWi/IydnBJ34C0kygyKuirDBX+0LvWaiwEc2 ruUzJAqUfkMIdp7nO7niiosNZujOQQ1cRv/Z3lXt1lgnO2J4ArWY+JMqXvoxvrCY018U 5VBjZ1OxTpBYZaKZpZTV8uL6rxbj4/Ifu+zkWgM8pFA1kR70cKX6ZBGFdxm9To5zgoAd VLJmT/8hp4U2HqUm2F3exJnoX8C9Fu0UF+gTsKSrGRxftp/p/lok8LKxwjXPsd1xt4MK ehCwT2PlSSvm31lOWu7EhmrVowkC8Aa4gAniqvX1lm8BN0uAxhEyEgnWJ3tTx4u+es2L gfvg== MIME-Version: 1.0 Received: by 10.152.103.18 with SMTP id fs18mr18789577lab.32.1350576376252; Thu, 18 Oct 2012 09:06:16 -0700 (PDT) Received: by 10.112.54.7 with HTTP; Thu, 18 Oct 2012 09:06:16 -0700 (PDT) Date: Thu, 18 Oct 2012 17:06:16 +0100 Message-ID: From: Pedro Felix To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f46d0407139d2608c304cc5791e4 Subject: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:06:20 -0000 --f46d0407139d2608c304cc5791e4 Content-Type: text/plain; charset=ISO-8859-1 Hi, Where can I find more information about the dynamic registration of client application instances? The idea is that each installed application instance has a different id, eventually related to the "general" application id. It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address). Thanks Pedro --f46d0407139d2608c304cc5791e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Where can I find more information about the dy= namic registration of client application instances?
The idea is that ea= ch installed application instance has a different id, eventually related to= the "general" application id.

It also would be interesting if this instance id was th= e result of an activation process, where the instance is attached to a devi= ce or to an user (e.g. confimed email address).

Thanks
Pedro

--f46d0407139d2608c304cc5791e4-- From igor.faynberg@alcatel-lucent.com Thu Oct 18 09:53:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EB921F8778 for ; Thu, 18 Oct 2012 09:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3O3ihlJAwbp for ; Thu, 18 Oct 2012 09:53:18 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0D60F21F86DF for ; Thu, 18 Oct 2012 09:53:15 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q9IGr96s019111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 18 Oct 2012 11:53:09 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q9IGr9RA029587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 18 Oct 2012 11:53:09 -0500 Received: from [135.222.232.243] (USMUYN0L055118.mh.lucent.com [135.222.232.243]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q9IGr8Qf001250; Thu, 18 Oct 2012 11:53:08 -0500 (CDT) Message-ID: <508033F4.1070704@alcatel-lucent.com> Date: Thu, 18 Oct 2012 12:53:08 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: oauth@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060200040004020505010208" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:53:19 -0000 This is a multi-part message in MIME format. --------------060200040004020505010208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Looks like a good description of a new use case to me! Igor On 10/17/2012 10:23 PM, zhou.sujing@zte.com.cn wrote: > > Hi, Thomas, > > Sorry for reply late. I somehow missed the emails from OAUTH list. > > "What may not be clear up-front from reading the UMA core spec is that > there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting > Party) and Bob's portal/platform (Requester)). > > Here's a more accurate picture: > > - I deposit my Child at the Kindergarten. > - I delegate my old Grandmother to pick up the Child. > - My Grandmother takes a taxi. > - The taxi Driver acts as proxy to my old Grandmother who stays in the > taxi. > - The taxi Driver needs to show 2 forms of Delegation to the Teacher. > - The Taxi driver walks the Child to the taxi. > > Bear in mind that my Grandmother now has to manage the delegation she > gave the taxi Driver (plus the Scopes involved)." > > > If I understand correctly, old Grandma means Bob the requesting Party, > the taxi driver means Bob the requester in UMA? > Not talking about UMA, Bob is not separate between roles in OAUTH, > so don't have to redelegate in OAUTH? > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------060200040004020505010208 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Looks like a good description of a new use case to me!

Igor

On 10/17/2012 10:23 PM, zhou.sujing@zte.com.cn wrote:

Hi, Thomas,

   Sorry for reply late. I somehow missed the emails from OAUTH list.

"What may not be clear up-front from reading the UMA core spec is that
there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting
Party) and Bob's portal/platform (Requester)).

Here's a more accurate picture:

- I deposit my Child at the Kindergarten.
- I delegate my old Grandmother to pick up the Child.
- My Grandmother takes a taxi.
- The taxi Driver acts as proxy to my old Grandmother who stays in the
taxi.
- The taxi Driver needs to show 2 forms of Delegation to the Teacher.
- The Taxi driver walks the Child to the taxi.

Bear in mind that my Grandmother now has to manage the delegation she
gave the taxi Driver (plus the Scopes involved)."


If I understand correctly, old Grandma means Bob the requesting Party,
the taxi driver means Bob the requester in UMA?
Not talking  about UMA, Bob is not separate between roles in OAUTH,
so don't have to redelegate in OAUTH?



 

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--------------060200040004020505010208-- From phil.hunt@oracle.com Thu Oct 18 09:59:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B5121F875C for ; Thu, 18 Oct 2012 09:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.358 X-Spam-Level: X-Spam-Status: No, score=-10.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhR1HCR+m94C for ; Thu, 18 Oct 2012 09:59:20 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id EECCD21F8752 for ; Thu, 18 Oct 2012 09:59:19 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9IGxGgn026186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Oct 2012 16:59:17 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9IGxGXG017422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2012 16:59:16 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9IGxFM9030831; Thu, 18 Oct 2012 11:59:15 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Oct 2012 09:59:15 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Phil Hunt In-Reply-To: Date: Thu, 18 Oct 2012 09:59:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> References: To: Pedro Felix X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 16:59:20 -0000 Pedro, AFAIK this is still a TODO within the current charter. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-10-18, at 9:06 AM, Pedro Felix wrote: > Hi, >=20 > Where can I find more information about the dynamic registration of = client application instances? > The idea is that each installed application instance has a different = id, eventually related to the "general" application id. >=20 > It also would be interesting if this instance id was the result of an = activation process, where the instance is attached to a device or to an = user (e.g. confimed email address). >=20 > Thanks > Pedro >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From pmhsfelix@gmail.com Fri Oct 19 07:47:43 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5116E21F85ED for ; Fri, 19 Oct 2012 07:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtwiQ+etsNSy for ; Fri, 19 Oct 2012 07:47:42 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6334321F847B for ; Fri, 19 Oct 2012 07:47:42 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so415128lam.31 for ; Fri, 19 Oct 2012 07:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=6909GQjjOsTpFrFgCsWVlhb/RSQqvc0zLIg3YallNyA=; b=bvpBYIZFJiuvJxIe+9p2EWj9WqIVaKdlFZuFAmLl/luoru/SCj9TDZ22LTOk1Y3/4s yy0Gc0hmb2eoQLXPGGTCFVlb2dBvKwOvaPDfaAuIShfdTOBdt3qUNXkrGPULnDi4pJsG 04i89QgvGnIm97q1/e35vhNkLGQ/toK5gdEPkpmAW3aT9KQ28vPp/Ek/+XWhcwxKmvLf Eh53P68TBL5sD0Qys5tpC6nM5GHOk6N3TacMeQ93W6e0VpJQT/SXWojBIFP5zYlBMcGB QocsqfEv25bGzG0Zca5JfLy8R9TaIQNpHTlpknaVfOVpoVeJvYji1y+0+kmfVryINDo7 +0DA== MIME-Version: 1.0 Received: by 10.152.108.37 with SMTP id hh5mr1375025lab.52.1350658061407; Fri, 19 Oct 2012 07:47:41 -0700 (PDT) Received: by 10.112.54.7 with HTTP; Fri, 19 Oct 2012 07:47:41 -0700 (PDT) In-Reply-To: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> Date: Fri, 19 Oct 2012 15:47:41 +0100 Message-ID: From: Pedro Felix To: oauth@ietf.org Content-Type: multipart/alternative; boundary=bcaec54ee10af6978c04cc6a953a Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 14:47:43 -0000 --bcaec54ee10af6978c04cc6a953a Content-Type: text/plain; charset=ISO-8859-1 Thanks for the response. I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject. What is the best place to follow this discussion? This mailing list? Thanks Pedro On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt wrote: > Pedro, > > AFAIK this is still a TODO within the current charter. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-10-18, at 9:06 AM, Pedro Felix wrote: > > > Hi, > > > > Where can I find more information about the dynamic registration of > client application instances? > > The idea is that each installed application instance has a different id, > eventually related to the "general" application id. > > > > It also would be interesting if this instance id was the result of an > activation process, where the instance is attached to a device or to an > user (e.g. confimed email address). > > > > Thanks > > Pedro > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > --bcaec54ee10af6978c04cc6a953a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for the response.

I know that this area is work i= n progress. However, I've looked into=A0http://tools.ietf.org/html/draft-ietf-o= auth-dyn-reg-00=A0and didn't found much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independenti= d.com
phil.hunt@oracle.com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of cl= ient application instances?
> The idea is that each installed application instance has a different i= d, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of an = activation process, where the instance is attached to a device or to an use= r (e.g. confimed email address).
>
> Thanks
> Pedro
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--bcaec54ee10af6978c04cc6a953a-- From pmhsfelix@gmail.com Fri Oct 19 08:22:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467CB21F8750 for ; Fri, 19 Oct 2012 08:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vXXs8pab6J2U for ; Fri, 19 Oct 2012 08:22:31 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id A785121F8480 for ; Fri, 19 Oct 2012 08:22:31 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so669860oag.31 for ; Fri, 19 Oct 2012 08:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZmseWGGULrmu7dPGf2010L/Lzaa0G9Kx8B0H7kUxOBw=; b=KDhkFFTdg7TrXEd0KJkNEvi/Ah112zeaqq96f7s4G5oyMQoBEX/7iusNB9VcI3Iwik o4AMtKAVbjGtKMU3eaOPAhAR28F49mtb3HSQZhPSMVw91jNt+NEVG5JP8IT9UfSDLlwl FMua24KWmicFPKAj5Jmdd7a1uDTOLw3JoEqU4zl5A2Q/fhch9ssqD401MbHgujOnwQFX iBml6OLrxH8UCX3OjZKmEY82SrE9kXKiGDFx2TcvAghFn7ioOTJVa8LcxFMTt0gUTP9y Wk3IZ8trHNRG7DG+sgg8VTwstTSUOqsQV0omRQLSuxCNXx61r/HchdcifOvLzwg935b6 Ig1w== MIME-Version: 1.0 Received: by 10.182.64.34 with SMTP id l2mr696343obs.28.1350660151228; Fri, 19 Oct 2012 08:22:31 -0700 (PDT) Received: by 10.182.55.33 with HTTP; Fri, 19 Oct 2012 08:22:31 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Oct 2012 16:22:31 +0100 Message-ID: From: Pedro Felix To: oauth@ietf.org Content-Type: multipart/alternative; boundary=14dae93a190986b81004cc6b1299 Cc: Lukasz Moren , Maciej Machulak Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:22:32 -0000 --14dae93a190986b81004cc6b1299 Content-Type: text/plain; charset=ISO-8859-1 I have a native app scenario where - There are multiple app instances - The same user user can have multiple app instances (phone, tablet) - I would want to use confidential clients - the native app instance dynamically receives the client_secret - There should be a way to limit the number of app instances that are created. For instance, one could associate an app instance to the user's email. Namely, I would like to explore the idea that an app instance is something that is simultaneous associated with the client app but also to the user (resource owner). Thanks Pedro On Fri, Oct 19, 2012 at 3:53 PM, Maciej Machulak < maciej.machulak@cloudidentity.co.uk> wrote: > Hi Pedro, > > With reference to your question posted on the OAUTH WG regarding dynamic > registration of OAuth clients, could you please provide us with the > description of your use case. We've implemented dynamic registration on one > of our systems based on the specification that we've co-authored ( > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00). It would be > great to learn more about what you're trying to achieve and if we can help. > > Thanks, > Maciej > --14dae93a190986b81004cc6b1299 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a native app scenario where
- There are multiple app instances
- The same user user can have multiple app instances (phone, tablet)=
- I would want to use confidential clients - the native app inst= ance dynamically receives the client_secret
- There should be a way to limit the number of app instances that are = created. For instance, one could associate an app instance to the user'= s email. Namely, I would like to explore the idea that an app instance is s= omething that is simultaneous associated with the client app but also to th= e user (resource owner).

Thanks
Pedro

On Fri, Oct 19, 2012 at 3:53 PM, Maciej Machulak <maci= ej.machulak@cloudidentity.co.uk> wrote:
Hi Pedro,

With reference = to your question posted on the OAUTH WG regarding dynamic registration of O= Auth clients, could you please provide us with the description of your use = case. We've implemented dynamic registration on one of our systems base= d on the specification that we've co-authored (http://tools.i= etf.org/html/draft-ietf-oauth-dyn-reg-00). It would be great to learn m= ore about what you're trying to achieve and if we can help.

Thanks,
Maciej

--14dae93a190986b81004cc6b1299-- From ve7jtb@ve7jtb.com Fri Oct 19 08:25:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494F421F846C for ; Fri, 19 Oct 2012 08:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gv2HuR+zsiP for ; Fri, 19 Oct 2012 08:25:05 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E599E21F8461 for ; Fri, 19 Oct 2012 08:25:04 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so199022qao.10 for ; Fri, 19 Oct 2012 08:25:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Y3FvHNEh8F6zyTNEnCdbqkKvqcmuy++Zz1+MQgFT26c=; b=BHFCGQUhILkv9TebZ951bDAXJ2JtNJCGcOPQ5J2WXRpUMupnI9LX6MAB5INnCUaTl+ v3HLfNVvNGdeDb7/u1DfAq2s1tV4/8CmuDNTJC9j5E7iX3ERPmQjZu+m2TBz1nWCfyNy /SXGxMctGePfNDgP7/Uv4Opl6BNGtJtLEV0H3Pw3nnQqohO2lDep7P/cp5xj2WTqTma3 kh+kgyE4Y3nykwnAwSS1yX+1OXdaJ7J1hs6VGKXBo73w63nFnVjZGTeHQox5VfvyYDyQ tZFLBfFfhmrT2zCCEP8WcN4qvyIEcWdkt31aMq0OsaDOD4hBrum7CPMCqUrM3lVfBH2P q8Hg== Received: by 10.229.137.73 with SMTP id v9mr179436qct.72.1350660304188; Fri, 19 Oct 2012 08:25:04 -0700 (PDT) Received: from [192.168.1.211] (190-20-34-206.baf.movistar.cl. [190.20.34.206]) by mx.google.com with ESMTPS id fy1sm529045qab.10.2012.10.19.08.24.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 08:25:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2C825516-0382-4BB5-A8D6-064E3F0B6C73" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Fri, 19 Oct 2012 12:24:45 -0300 Message-Id: References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> To: Pedro Felix X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlIeDXnGihSMgcKmW2r4FtwPYbG+O2mKA8fhJUyb1hdW09nI1FgdgFFxUai1FmX5/E5egPH Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 15:25:07 -0000 --Apple-Mail=_2C825516-0382-4BB5-A8D6-064E3F0B6C73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 The client instance registration was something that we discussed and put = into the openID Connect dynamic client registration but has not yet been = put back into the UMA draft. http://openid.bitbucket.org/openid-connect-registration-1_0.html The basic idea is that you can bake a access token into client code and = that client then uses that to get a unique clientID and secret/register = public key. There was a long discussion about this at a IIW about a year ago. =20 In some of the native apps projects I am looking at that are not openID = connect related we are looking at doing the same thing to differentiate = instances of clients. John B. On 2012-10-19, at 11:47 AM, Pedro Felix wrote: > Thanks for the response. >=20 > I know that this area is work in progress. However, I've looked into = http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found = much about this subject. > What is the best place to follow this discussion? This mailing list? >=20 > Thanks > Pedro >=20 > On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt = wrote: > Pedro, >=20 > AFAIK this is still a TODO within the current charter. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-10-18, at 9:06 AM, Pedro Felix wrote: >=20 > > Hi, > > > > Where can I find more information about the dynamic registration of = client application instances? > > The idea is that each installed application instance has a different = id, eventually related to the "general" application id. > > > > It also would be interesting if this instance id was the result of = an activation process, where the instance is attached to a device or to = an user (e.g. confimed email address). > > > > Thanks > > Pedro > > > > _______________________________________________ > > 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=_2C825516-0382-4BB5-A8D6-064E3F0B6C73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 The = client instance registration was something that we discussed and put = into the openID Connect dynamic client registration but has not yet been = put back into the UMA draft.

=

The basic idea is that you can bake a access token = into client code and that client then uses that to get a unique clientID = and secret/register public key.

There was a = long discussion about this at a IIW about a year ago. =   

In some of the native apps = projects I am looking at that are not openID connect related we are = looking at doing the same thing to differentiate instances of = clients.

John = B.



On 2012-10-19, at = 11:47 AM, Pedro Felix <pmhsfelix@gmail.com> = wrote:

Thanks for the response.

I know that = this area is work in progress. However, I've looked into http://too= ls.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found = much about this subject.
What is the best place to follow this discussion? This mailing = list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of = client application instances?
> The idea is that each installed application instance has a = different id, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of = an activation process, where the instance is attached to a device or to = an user (e.g. confimed email address).
>
> Thanks
> Pedro
>
> _______________________________________________
> OAuth mailing 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=_2C825516-0382-4BB5-A8D6-064E3F0B6C73-- From pmhsfelix@gmail.com Fri Oct 19 09:00:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC4E21F87DD for ; Fri, 19 Oct 2012 09:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQk5Lmq3OOgK for ; Fri, 19 Oct 2012 09:00:46 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8147521F879B for ; Fri, 19 Oct 2012 09:00:46 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so714215oag.31 for ; Fri, 19 Oct 2012 09:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pGS+bXFX/mMhDeoEpejSY0/KIEk6JjSf8DxfYHCDIwI=; b=s3kPdykV4ncx9W696M6uyXOhBaHC9HRjmRo1IfmBLKXphbMRQMxqI6No287T97rXHf jdGO5aUQjo5Qu3OITQv7U0OYXX8wtRGC07xV6lnKsmzl63TSx9Xrbmz/sv5jtc7g7OjN xpe+HI9ofk537luCEao2FAh/sw0IxqyrPrgb6/OCBhRaRqglyVrIlyBtJoS5bem+RokW cntgnFbUGHEU4WDJQtWYOndTlD0jNHcqmgx7bftAk1aKKIrjYOBl6VKn9Oe6ahtsLzE0 tjrGU7Hi8PZcKop0wuEEFzV3yXdBOXB5fb+MXoMxFKLXU6UUhQDNvNARbQUTMYJMabiR iXAw== MIME-Version: 1.0 Received: by 10.60.4.136 with SMTP id k8mr1872363oek.94.1350662437930; Fri, 19 Oct 2012 09:00:37 -0700 (PDT) Received: by 10.182.55.33 with HTTP; Fri, 19 Oct 2012 09:00:37 -0700 (PDT) In-Reply-To: References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> Date: Fri, 19 Oct 2012 17:00:37 +0100 Message-ID: From: Pedro Felix To: John Bradley Content-Type: multipart/alternative; boundary=e89a8ff1c5e4d307d804cc6b9a07 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:00:49 -0000 --e89a8ff1c5e4d307d804cc6b9a07 Content-Type: text/plain; charset=ISO-8859-1 And what if the client instance is also connected to some verifiable user attribute, such as an email? Is this a bad idea? Pedro On Fri, Oct 19, 2012 at 4:24 PM, John Bradley wrote: > The client instance registration was something that we discussed and put > into the openID Connect dynamic client registration but has not yet been > put back into the UMA draft. > > http://openid.bitbucket.org/openid-connect-registration-1_0.html > > The basic idea is that you can bake a access token into client code and > that client then uses that to get a unique clientID and secret/register > public key. > > There was a long discussion about this at a IIW about a year ago. > > In some of the native apps projects I am looking at that are not openID > connect related we are looking at doing the same thing to differentiate > instances of clients. > > John B. > > > > On 2012-10-19, at 11:47 AM, Pedro Felix wrote: > > Thanks for the response. > > I know that this area is work in progress. However, I've looked into > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found > much about this subject. > What is the best place to follow this discussion? This mailing list? > > Thanks > Pedro > > On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt wrote: > >> Pedro, >> >> AFAIK this is still a TODO within the current charter. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-10-18, at 9:06 AM, Pedro Felix wrote: >> >> > Hi, >> > >> > Where can I find more information about the dynamic registration of >> client application instances? >> > The idea is that each installed application instance has a different >> id, eventually related to the "general" application id. >> > >> > It also would be interesting if this instance id was the result of an >> activation process, where the instance is attached to a device or to an >> user (e.g. confimed email address). >> > >> > Thanks >> > Pedro >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --e89a8ff1c5e4d307d804cc6b9a07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable And what if the client instance is also connected to some verifiable user a= ttribute, such as an email?
Is this a bad idea?

Pedro

On Fri, Oct 19, 2012 at 4:= 24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The clie= nt instance registration was something that we discussed and put into the o= penID Connect dynamic client registration but has not yet been put back int= o the UMA draft.


The basic idea is tha= t you can bake a access token into client code and that client then uses th= at to get a unique clientID and secret/register public key.

There was a long discussion about this at a IIW about a= year ago. =A0=A0

In some of the native apps proje= cts I am looking at that are not openID connect related we are looking at d= oing the same thing to differentiate instances of clients.

John B.


<= /div>

On 2012-10-19, at 11:47 AM, Pedro Felix <pmhsfelix@gmail.com&g= t; wrote:

Thanks for the response.

I= know that this area is work in progress. However, I've looked into=A0<= a href=3D"http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00" target=3D= "_blank">http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00=A0and d= idn't found much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <phil.hunt@oracle.com<= /a>> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.= com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of cl= ient application instances?
> The idea is that each installed application instance has a different i= d, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of an = activation process, where the instance is attached to a device or to an use= r (e.g. confimed email address).
>
> Thanks
> Pedro
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


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

--e89a8ff1c5e4d307d804cc6b9a07-- From prateek.mishra@oracle.com Fri Oct 19 09:26:33 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E02521F83EF for ; Fri, 19 Oct 2012 09:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYTkbRMhXcf7 for ; Fri, 19 Oct 2012 09:26:32 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 04D5E21F8741 for ; Fri, 19 Oct 2012 09:26:31 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9JGQSFJ018265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Oct 2012 16:26:29 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9JGQSba008256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 16:26:28 GMT Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9JGQRlv018427; Fri, 19 Oct 2012 11:26:27 -0500 Received: from [192.168.1.2] (/173.76.27.93) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Oct 2012 09:26:27 -0700 Message-ID: <50817F2C.604@oracle.com> Date: Fri, 19 Oct 2012 12:26:20 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Pedro Felix References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070706080700070704010501" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:26:33 -0000 This is a multi-part message in MIME format. --------------070706080700070704010501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pedro - the best way to move this forward is to make a proposal or describe some use-cases. My own guess is that we also need a broader discussion of different client-types and their deployment models. For example, there are clients that are delivered through a secured process to tablets or devices or desktops. Another category of clients are services hosted by an application server, these have quite different characteristics as well. - prateek - > Thanks for the response. > > I know that this area is work in progress. However, I've looked into > http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't > found much about this subject. > What is the best place to follow this discussion? This mailing list? > > Thanks > Pedro > > On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt > wrote: > > Pedro, > > AFAIK this is still a TODO within the current charter. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-10-18, at 9:06 AM, Pedro Felix wrote: > > > Hi, > > > > Where can I find more information about the dynamic registration > of client application instances? > > The idea is that each installed application instance has a > different id, eventually related to the "general" application id. > > > > It also would be interesting if this instance id was the result > of an activation process, where the instance is attached to a > device or to an user (e.g. confimed email address). > > > > Thanks > > Pedro > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------070706080700070704010501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pedro - the best way to move this forward is to make a proposal or describe some use-cases.

My own guess is that we also need a broader discussion of different client-types and their deployment models.
For example, there are clients that are delivered  through a secured process to tablets or devices or desktops. Another category of
clients are services hosted by an application server, these have quite different characteristics as well.

- prateek

-

Thanks for the response.

I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of client application instances?
> The idea is that each installed application instance has a different id, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address).
>
> Thanks
> Pedro
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth




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

--------------070706080700070704010501-- From gffletch@aol.com Fri Oct 19 09:40:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F1F21F874E for ; Fri, 19 Oct 2012 09:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X84LG8CYXlmS for ; Fri, 19 Oct 2012 09:40:34 -0700 (PDT) Received: from imr-ma05.mx.aol.com (imr-ma05.mx.aol.com [64.12.100.31]) by ietfa.amsl.com (Postfix) with ESMTP id 76AFD21F874C for ; Fri, 19 Oct 2012 09:40:34 -0700 (PDT) Received: from mtaout-da01.r1000.mx.aol.com (mtaout-da01.r1000.mx.aol.com [172.29.51.129]) by imr-ma05.mx.aol.com (8.14.1/8.14.1) with ESMTP id q9JGe77f005251; Fri, 19 Oct 2012 12:40:07 -0400 Received: from palantir.local (unknown [10.172.6.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mtaout-da01.r1000.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B2426E0000A4; Fri, 19 Oct 2012 12:40:06 -0400 (EDT) Message-ID: <50818266.5010205@aol.com> Date: Fri, 19 Oct 2012 12:40:06 -0400 From: George Fletcher Organization: AOL LLC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Pedro Felix References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050502030101080901010005" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20110426; t=1350664807; bh=FFbsNPCMuiZoTSo0gFUCAgj3Ge/mCM+cogKGWMaqDX0=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=svrbXZcgCZUX6UuAyCD7ANgG0f0LDujzDgU9ZNOVt4WqQ6vztIYit8i+6rmnxWLV0 hm6a3j/7h6gWjVZMZWvrQS1vZTT/mywWb4Q1/LLZnmCPybwrFgr3CzcJMK/C6ZyDas 2oN4+D1xRdkR4p8f5b2SiURXpZ2BKzGWV0EKQB1s= X-AOL-SCOLL-SCORE: 0:2:442047840:93952408 X-AOL-SCOLL-URL_COUNT: 0 x-aol-sid: 3039ac1d3381508182667bcd X-AOL-IP: 10.172.6.127 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:40:35 -0000 This is a multi-part message in MIME format. --------------050502030101080901010005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned. I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope. There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established. Thanks, George On 10/19/12 12:00 PM, Pedro Felix wrote: > And what if the client instance is also connected to some verifiable > user attribute, such as an email? > Is this a bad idea? > > Pedro > > On Fri, Oct 19, 2012 at 4:24 PM, John Bradley > wrote: > > The client instance registration was something that we discussed > and put into the openID Connect dynamic client registration but > has not yet been put back into the UMA draft. > > http://openid.bitbucket.org/openid-connect-registration-1_0.html > > The basic idea is that you can bake a access token into client > code and that client then uses that to get a unique clientID and > secret/register public key. > > There was a long discussion about this at a IIW about a year ago. > > In some of the native apps projects I am looking at that are not > openID connect related we are looking at doing the same thing to > differentiate instances of clients. > > John B. > > > > On 2012-10-19, at 11:47 AM, Pedro Felix > wrote: > >> Thanks for the response. >> >> I know that this area is work in progress. However, I've looked >> into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and >> didn't found much about this subject. >> What is the best place to follow this discussion? This mailing list? >> >> Thanks >> Pedro >> >> On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt > > wrote: >> >> Pedro, >> >> AFAIK this is still a TODO within the current charter. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >> >> >> >> >> >> On 2012-10-18, at 9:06 AM, Pedro Felix wrote: >> >> > Hi, >> > >> > Where can I find more information about the dynamic >> registration of client application instances? >> > The idea is that each installed application instance has a >> different id, eventually related to the "general" application id. >> > >> > It also would be interesting if this instance id was the >> result of an activation process, where the instance is >> attached to a device or to an user (e.g. confimed email address). >> > >> > Thanks >> > Pedro >> > >> > _______________________________________________ >> > OAuth mailing 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 --------------050502030101080901010005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned.

I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope.

There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established.

Thanks,
George

On 10/19/12 12:00 PM, Pedro Felix wrote:
And what if the client instance is also connected to some verifiable user attribute, such as an email?
Is this a bad idea?

Pedro

On Fri, Oct 19, 2012 at 4:24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft.


The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key.

There was a long discussion about this at a IIW about a year ago.   

In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients.

John B.



On 2012-10-19, at 11:47 AM, Pedro Felix <pmhsfelix@gmail.com> wrote:

Thanks for the response.

I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of client application instances?
> The idea is that each installed application instance has a different id, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address).
>
> Thanks
> Pedro
>
> _______________________________________________
> OAuth mailing 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

--------------050502030101080901010005-- From phil.hunt@oracle.com Fri Oct 19 10:39:30 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFDF21F8200 for ; Fri, 19 Oct 2012 10:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.418 X-Spam-Level: X-Spam-Status: No, score=-10.418 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXnH030EwZat for ; Fri, 19 Oct 2012 10:39:28 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1C65821F879C for ; Fri, 19 Oct 2012 10:39:28 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9JHdNUP025778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Oct 2012 17:39:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9JHdMGn014450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 17:39:22 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9JHdL8Q004425; Fri, 19 Oct 2012 12:39:21 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Oct 2012 10:39:21 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_04760FAD-55A3-48EE-B307-FEEA6A0C9A29" From: Phil Hunt In-Reply-To: <50818266.5010205@aol.com> Date: Fri, 19 Oct 2012 10:39:20 -0700 Message-Id: <3E1273EA-B784-485F-97D3-EA09C77E8C28@oracle.com> References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> <50818266.5010205@aol.com> To: George Fletcher X-Mailer: Apple Mail (2.1283) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 17:39:30 -0000 --Apple-Mail=_04760FAD-55A3-48EE-B307-FEEA6A0C9A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Consider that the issues comes from 2 angles: 1. The desire to distinguish between instances of a client app (e.g. on = mobile phones) 2. The desire for the client to register with particular instances of a = resource service. The objective: to establish a unique credential that binds a particular = client instance (or set of clients) with a particular resource service = provider. I note that, per John's suggestion, this is something like what OpenID = Connect attempted to solve with their dynamic registration draft. As further input, during the review of the OAuth Threat Model, there was = significant inquires and discussion about how to assess the legitimacy = or authenticity of a piece of client software. Though we didn't solve = it, there was a lot of requests for finding a way to authenticate client = software as simply being the one made by its developer. Therefore, I think there is requirement to be able to authenticate = software (at some level) that is part of the dynamic registration = process. I think there is a few of steps in dynamic registration. 1. A method to authenticate the software. Is it signed by its publisher? = If the resource being accessed is developed by a single publisher, has = the client been registered with the publisher? Hypothetical examples of = this might be clients designed to work with MS Exchange, or Oracle CRM. 2. Optionally establishing a means to distinguish one client instance = from another. 3. Dynamically issuing the client with a credential (which may or may = not be instance specific) to use with a particular instance of a = resource authorization server. Regarding step 1, I note that in the case OpenID Connect, there is no = single place to even register a client as there is with proprietary = APIs. Not sure if software signing can work here. The same problem will = emerge with any standards based API (e.g. such as SCIM). This is why I = think dynamic registration is of broad interest in the standards = community beyond just OpenID. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-10-19, at 9:40 AM, George Fletcher wrote: > I think it's an interesting idea... I'm just not sure how to tie the = dynamic client registration to a verified user email address. To get a = verified email address, most OAuth2 flows require the client_id to be = already provisioned.=20 >=20 > I do agree that from the AS/OP perspective, we don't want to allow = unlimited client registrations. This could be it's own form of DoS = attack. I suppose if the client has a verifiable token containing the = user attributes, that could be passed optionally to the dynamic client = registration flow. How the client got the verifiable token could be left = out of scope. >=20 > There are probably other ways to protect against abuse and they will = likely be different from OP to OP for a while, until some best practices = are established. >=20 > Thanks, > George >=20 > On 10/19/12 12:00 PM, Pedro Felix wrote: >> And what if the client instance is also connected to some verifiable = user attribute, such as an email? >> Is this a bad idea? >>=20 >> Pedro >>=20 >> On Fri, Oct 19, 2012 at 4:24 PM, John Bradley = wrote: >> The client instance registration was something that we discussed and = put into the openID Connect dynamic client registration but has not yet = been put back into the UMA draft. >>=20 >> http://openid.bitbucket.org/openid-connect-registration-1_0.html >>=20 >> The basic idea is that you can bake a access token into client code = and that client then uses that to get a unique clientID and = secret/register public key. >>=20 >> There was a long discussion about this at a IIW about a year ago. =20= >>=20 >> In some of the native apps projects I am looking at that are not = openID connect related we are looking at doing the same thing to = differentiate instances of clients. >>=20 >> John B. >>=20 >>=20 >>=20 >> On 2012-10-19, at 11:47 AM, Pedro Felix wrote: >>=20 >>> Thanks for the response. >>>=20 >>> I know that this area is work in progress. However, I've looked into = http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found = much about this subject. >>> What is the best place to follow this discussion? This mailing list? >>>=20 >>> Thanks >>> Pedro >>>=20 >>> On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt = wrote: >>> Pedro, >>>=20 >>> AFAIK this is still a TODO within the current charter. >>>=20 >>> Phil >>>=20 >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2012-10-18, at 9:06 AM, Pedro Felix wrote: >>>=20 >>> > Hi, >>> > >>> > Where can I find more information about the dynamic registration = of client application instances? >>> > The idea is that each installed application instance has a = different id, eventually related to the "general" application id. >>> > >>> > It also would be interesting if this instance id was the result of = an activation process, where the instance is attached to a device or to = an user (e.g. confimed email address). >>> > >>> > Thanks >>> > Pedro >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_04760FAD-55A3-48EE-B307-FEEA6A0C9A29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Phil

On 2012-10-19, at 9:40 AM, George Fletcher wrote:

=20 =20
I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned.

I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope.

There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established.

Thanks,
George

On 10/19/12 12:00 PM, Pedro Felix wrote:
And what if the client instance is also connected = to some verifiable user attribute, such as an email?
Is this a bad idea?

Pedro

On Fri, Oct 19, 2012 at 4:24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft.


The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key.

There was a long discussion about this at a IIW about a year ago.   

In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients.

John B.



On 2012-10-19, at 11:47 AM, Pedro Felix <pmhsfelix@gmail.com> wrote:

Thanks for the = response.

I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of client application instances?
> The idea is that each installed application instance has a different id, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address).
>
> Thanks
> Pedro
>
> = _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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




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

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

= --Apple-Mail=_04760FAD-55A3-48EE-B307-FEEA6A0C9A29-- From ve7jtb@ve7jtb.com Fri Oct 19 11:13:10 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4F521F879F for ; Fri, 19 Oct 2012 11:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q8JWvR41Ksm for ; Fri, 19 Oct 2012 11:13:09 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4F71A21F87AA for ; Fri, 19 Oct 2012 11:13:09 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so292647qab.10 for ; Fri, 19 Oct 2012 11:13:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=pK1Xs1MUFMU9qZB4BBiXOB1RoXLEZ9UAhcVdRLCEkUA=; b=iIqw6COwvIMJbJ04UiJ0HU5LN0PHe71y/5Z71MYLBfYdyM4xrcRIkbfHCQGRRB7FvC otfxYa6bYN/eu07A/Y0pY2K0bLUGppKgv8fDh3MdBHOjW780EV27NhGC49vxgRTGUKOV m842OkBt+wp1C9Zt6SuklQVdvadPnWIqLoMSZ9/I596FYlNIQi0rEme2syrrHaXASAZ2 /fiyqi/fRP5TL67FIAT+UKglHgMxCjMXRTsqhud5Jyh6DyGR656FWrh0vY2pWN3eMpl0 AICCKljInglcLy0q7Mlf1Jx2kWxU2+iXFWrEzN2GZuBnL+m7cZlHOeM1Zbum0KXXZRd8 VUYA== Received: by 10.49.103.162 with SMTP id fx2mr1156885qeb.1.1350670388747; Fri, 19 Oct 2012 11:13:08 -0700 (PDT) Received: from [192.168.1.211] (190-20-34-206.baf.movistar.cl. [190.20.34.206]) by mx.google.com with ESMTPS id jw1sm418464qeb.13.2012.10.19.11.12.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 11:13:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AA1981F2-773F-47B1-8CBD-927DCC68311C" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <3E1273EA-B784-485F-97D3-EA09C77E8C28@oracle.com> Date: Fri, 19 Oct 2012 15:12:46 -0300 Message-Id: <29F34899-6CE6-478B-94C1-81B35E2EBA55@ve7jtb.com> References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> <50818266.5010205@aol.com> <3E1273EA-B784-485F-97D3-EA09C77E8C28@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlR+SNfpFg3EDiCPUr2bDEnb9kMEAuEOLEVkAHcfcKTRTt7D27XlFuukHEx15CCpOTqLSY2 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:13:11 -0000 --Apple-Mail=_AA1981F2-773F-47B1-8CBD-927DCC68311C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 It would be nice if software signing could work, however verifying that = over a network connection without some sort of OS level TPM seems overly = ambitious. We were not trying to solve that problem with connect, only find a way = that we could provision a secret for native apps. Certainly the registration token can be stolen and faked by a rogue app. = =20 However with a good app it lets you get a unique client secret for the = app or register a public key (something perhaps useful for Proof of = possession tokens as well) For web server clients this is not a big deal because registration is a = one tie thing. For native apps on phones etc having every one with the same clientID = and password is not a good thing. John B. On 2012-10-19, at 2:39 PM, Phil Hunt wrote: > Consider that the issues comes from 2 angles: > 1. The desire to distinguish between instances of a client app (e.g. = on mobile phones) > 2. The desire for the client to register with particular instances of = a resource service. >=20 > The objective: to establish a unique credential that binds a = particular client instance (or set of clients) with a particular = resource service provider. >=20 > I note that, per John's suggestion, this is something like what OpenID = Connect attempted to solve with their dynamic registration draft. >=20 > As further input, during the review of the OAuth Threat Model, there = was significant inquires and discussion about how to assess the = legitimacy or authenticity of a piece of client software. Though we = didn't solve it, there was a lot of requests for finding a way to = authenticate client software as simply being the one made by its = developer. >=20 > Therefore, I think there is requirement to be able to authenticate = software (at some level) that is part of the dynamic registration = process. >=20 > I think there is a few of steps in dynamic registration. > 1. A method to authenticate the software. Is it signed by its = publisher? If the resource being accessed is developed by a single = publisher, has the client been registered with the publisher? = Hypothetical examples of this might be clients designed to work with MS = Exchange, or Oracle CRM. > 2. Optionally establishing a means to distinguish one client instance = from another. > 3. Dynamically issuing the client with a credential (which may or may = not be instance specific) to use with a particular instance of a = resource authorization server. >=20 > Regarding step 1, I note that in the case OpenID Connect, there is no = single place to even register a client as there is with proprietary = APIs. Not sure if software signing can work here. The same problem will = emerge with any standards based API (e.g. such as SCIM). This is why I = think dynamic registration is of broad interest in the standards = community beyond just OpenID. >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2012-10-19, at 9:40 AM, George Fletcher wrote: >=20 >> I think it's an interesting idea... I'm just not sure how to tie the = dynamic client registration to a verified user email address. To get a = verified email address, most OAuth2 flows require the client_id to be = already provisioned.=20 >>=20 >> I do agree that from the AS/OP perspective, we don't want to allow = unlimited client registrations. This could be it's own form of DoS = attack. I suppose if the client has a verifiable token containing the = user attributes, that could be passed optionally to the dynamic client = registration flow. How the client got the verifiable token could be left = out of scope. >>=20 >> There are probably other ways to protect against abuse and they will = likely be different from OP to OP for a while, until some best practices = are established. >>=20 >> Thanks, >> George >>=20 >> On 10/19/12 12:00 PM, Pedro Felix wrote: >>> And what if the client instance is also connected to some verifiable = user attribute, such as an email? >>> Is this a bad idea? >>>=20 >>> Pedro >>>=20 >>> On Fri, Oct 19, 2012 at 4:24 PM, John Bradley = wrote: >>> The client instance registration was something that we discussed and = put into the openID Connect dynamic client registration but has not yet = been put back into the UMA draft. >>>=20 >>> http://openid.bitbucket.org/openid-connect-registration-1_0.html >>>=20 >>> The basic idea is that you can bake a access token into client code = and that client then uses that to get a unique clientID and = secret/register public key. >>>=20 >>> There was a long discussion about this at a IIW about a year ago. =20= >>>=20 >>> In some of the native apps projects I am looking at that are not = openID connect related we are looking at doing the same thing to = differentiate instances of clients. >>>=20 >>> John B. >>>=20 >>>=20 >>>=20 >>> On 2012-10-19, at 11:47 AM, Pedro Felix wrote: >>>=20 >>>> Thanks for the response. >>>>=20 >>>> I know that this area is work in progress. However, I've looked = into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't = found much about this subject. >>>> What is the best place to follow this discussion? This mailing = list? >>>>=20 >>>> Thanks >>>> Pedro >>>>=20 >>>> On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt = wrote: >>>> Pedro, >>>>=20 >>>> AFAIK this is still a TODO within the current charter. >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2012-10-18, at 9:06 AM, Pedro Felix wrote: >>>>=20 >>>> > Hi, >>>> > >>>> > Where can I find more information about the dynamic registration = of client application instances? >>>> > The idea is that each installed application instance has a = different id, eventually related to the "general" application id. >>>> > >>>> > It also would be interesting if this instance id was the result = of an activation process, where the instance is attached to a device or = to an user (e.g. confimed email address). >>>> > >>>> > Thanks >>>> > Pedro >>>> > >>>> > _______________________________________________ >>>> > OAuth mailing list >>>> > OAuth@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_AA1981F2-773F-47B1-8CBD-927DCC68311C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 It = would be nice if software signing could work, however verifying that = over a network connection without some sort of OS level TPM seems overly = ambitious.

We were not trying to solve that problem = with connect, only find a way that we could provision a secret for = native apps.

Certainly the registration token = can be stolen and faked by a rogue app. =  

However with a good app it lets you get = a unique client secret for the app or register a public key (something = perhaps useful for Proof of possession tokens as = well)

For web server clients this is not a big = deal because registration is a one tie = thing.

For native apps on phones etc having = every one with the same clientID and password is not a good = thing.

John = B.


On 2012-10-19, at = 2:39 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

Consider that the = issues comes from 2 angles:
1. The desire to distinguish = between instances of a client app (e.g. on mobile phones)
2. = The desire for the client to register with particular instances of a = resource service.

The objective:  to = establish a unique credential that binds a particular client instance = (or set of clients) with a particular resource service = provider.

I note that, per John's suggestion, = this is something like what OpenID Connect attempted to solve with their = dynamic registration draft.

As further input, = during the review of the OAuth Threat Model, there was significant = inquires and discussion about how to assess the legitimacy or = authenticity of a piece of client software. Though we didn't solve it, = there was a lot of requests for finding a way to authenticate client = software as simply being the one made by its = developer.

Therefore, I think there is = requirement to be able to authenticate software (at some level) that is = part of the dynamic registration process.

I = think there is a few of steps in dynamic registration.
1. A = method to authenticate the software. Is it signed by its publisher? =  If the resource being accessed is developed by a single publisher, = has the client been registered with the publisher? Hypothetical examples = of this might be clients designed to work with MS Exchange, or Oracle = CRM.
2. Optionally establishing a means to distinguish one = client instance from another.
3. Dynamically issuing the = client with a credential (which may or may not be instance specific) to = use with a particular instance of a resource authorization = server.

Regarding step 1, I note that in the = case OpenID Connect, there is no single place to even register a client = as there is with proprietary APIs. Not sure if software signing can work = here. The same problem will emerge with any standards based API (e.g. = such as SCIM).  This is why I think dynamic registration is of = broad interest in the standards community beyond just = OpenID.

Phil
www.independentid.com
phil.hunt@oracle.com





On 2012-10-19, at 9:40 AM, George Fletcher wrote:

=20 =20
I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned.

I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope.

There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established.

Thanks,
George

On 10/19/12 12:00 PM, Pedro Felix wrote:
And what if the client instance is also connected = to some verifiable user attribute, such as an email?
Is this a bad idea?

Pedro

On Fri, Oct 19, 2012 at 4:24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft.


The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key.

There was a long discussion about this at a IIW about a year ago.   

In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients.

John B.



On 2012-10-19, at 11:47 AM, Pedro Felix <pmhsfelix@gmail.com> wrote:

Thanks for the = response.

I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of client application instances?
> The idea is that each installed application instance has a different id, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address).
>
> Thanks
> Pedro
>
> = _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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




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

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

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

= --Apple-Mail=_AA1981F2-773F-47B1-8CBD-927DCC68311C-- From phil.hunt@oracle.com Fri Oct 19 11:35:36 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B0C21F87A6 for ; Fri, 19 Oct 2012 11:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.438 X-Spam-Level: X-Spam-Status: No, score=-10.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp8WsyUBNUHp for ; Fri, 19 Oct 2012 11:35:32 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id B797A21F879D for ; Fri, 19 Oct 2012 11:35:31 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9JIZSAW018566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Oct 2012 18:35:28 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9JIZR1v025867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 18:35:27 GMT Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9JIZRnO030261; Fri, 19 Oct 2012 13:35:27 -0500 Received: from [192.168.1.8] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Oct 2012 11:35:26 -0700 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_48242975-E0F7-4D5E-ADED-21E523A53261" From: Phil Hunt In-Reply-To: <29F34899-6CE6-478B-94C1-81B35E2EBA55@ve7jtb.com> Date: Fri, 19 Oct 2012 11:35:24 -0700 Message-Id: References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> <50818266.5010205@aol.com> <3E1273EA-B784-485F-97D3-EA09C77E8C28@oracle.com> <29F34899-6CE6-478B-94C1-81B35E2EBA55@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1283) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:35:36 -0000 --Apple-Mail=_48242975-E0F7-4D5E-ADED-21E523A53261 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I agree with your assessment here. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-10-19, at 11:12 AM, John Bradley wrote: > It would be nice if software signing could work, however verifying = that over a network connection without some sort of OS level TPM seems = overly ambitious. >=20 > We were not trying to solve that problem with connect, only find a way = that we could provision a secret for native apps. >=20 > Certainly the registration token can be stolen and faked by a rogue = app. =20 >=20 > However with a good app it lets you get a unique client secret for the = app or register a public key (something perhaps useful for Proof of = possession tokens as well) >=20 > For web server clients this is not a big deal because registration is = a one tie thing. >=20 > For native apps on phones etc having every one with the same clientID = and password is not a good thing. >=20 > John B. >=20 >=20 > On 2012-10-19, at 2:39 PM, Phil Hunt wrote: >=20 >> Consider that the issues comes from 2 angles: >> 1. The desire to distinguish between instances of a client app (e.g. = on mobile phones) >> 2. The desire for the client to register with particular instances of = a resource service. >>=20 >> The objective: to establish a unique credential that binds a = particular client instance (or set of clients) with a particular = resource service provider. >>=20 >> I note that, per John's suggestion, this is something like what = OpenID Connect attempted to solve with their dynamic registration draft. >>=20 >> As further input, during the review of the OAuth Threat Model, there = was significant inquires and discussion about how to assess the = legitimacy or authenticity of a piece of client software. Though we = didn't solve it, there was a lot of requests for finding a way to = authenticate client software as simply being the one made by its = developer. >>=20 >> Therefore, I think there is requirement to be able to authenticate = software (at some level) that is part of the dynamic registration = process. >>=20 >> I think there is a few of steps in dynamic registration. >> 1. A method to authenticate the software. Is it signed by its = publisher? If the resource being accessed is developed by a single = publisher, has the client been registered with the publisher? = Hypothetical examples of this might be clients designed to work with MS = Exchange, or Oracle CRM. >> 2. Optionally establishing a means to distinguish one client instance = from another. >> 3. Dynamically issuing the client with a credential (which may or may = not be instance specific) to use with a particular instance of a = resource authorization server. >>=20 >> Regarding step 1, I note that in the case OpenID Connect, there is no = single place to even register a client as there is with proprietary = APIs. Not sure if software signing can work here. The same problem will = emerge with any standards based API (e.g. such as SCIM). This is why I = think dynamic registration is of broad interest in the standards = community beyond just OpenID. >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2012-10-19, at 9:40 AM, George Fletcher wrote: >>=20 >>> I think it's an interesting idea... I'm just not sure how to tie the = dynamic client registration to a verified user email address. To get a = verified email address, most OAuth2 flows require the client_id to be = already provisioned.=20 >>>=20 >>> I do agree that from the AS/OP perspective, we don't want to allow = unlimited client registrations. This could be it's own form of DoS = attack. I suppose if the client has a verifiable token containing the = user attributes, that could be passed optionally to the dynamic client = registration flow. How the client got the verifiable token could be left = out of scope. >>>=20 >>> There are probably other ways to protect against abuse and they will = likely be different from OP to OP for a while, until some best practices = are established. >>>=20 >>> Thanks, >>> George >>>=20 >>> On 10/19/12 12:00 PM, Pedro Felix wrote: >>>> And what if the client instance is also connected to some = verifiable user attribute, such as an email? >>>> Is this a bad idea? >>>>=20 >>>> Pedro >>>>=20 >>>> On Fri, Oct 19, 2012 at 4:24 PM, John Bradley = wrote: >>>> The client instance registration was something that we discussed = and put into the openID Connect dynamic client registration but has not = yet been put back into the UMA draft. >>>>=20 >>>> http://openid.bitbucket.org/openid-connect-registration-1_0.html >>>>=20 >>>> The basic idea is that you can bake a access token into client code = and that client then uses that to get a unique clientID and = secret/register public key. >>>>=20 >>>> There was a long discussion about this at a IIW about a year ago. =20= >>>>=20 >>>> In some of the native apps projects I am looking at that are not = openID connect related we are looking at doing the same thing to = differentiate instances of clients. >>>>=20 >>>> John B. >>>>=20 >>>>=20 >>>>=20 >>>> On 2012-10-19, at 11:47 AM, Pedro Felix = wrote: >>>>=20 >>>>> Thanks for the response. >>>>>=20 >>>>> I know that this area is work in progress. However, I've looked = into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't = found much about this subject. >>>>> What is the best place to follow this discussion? This mailing = list? >>>>>=20 >>>>> Thanks >>>>> Pedro >>>>>=20 >>>>> On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt = wrote: >>>>> Pedro, >>>>>=20 >>>>> AFAIK this is still a TODO within the current charter. >>>>>=20 >>>>> Phil >>>>>=20 >>>>> @independentid >>>>> www.independentid.com >>>>> phil.hunt@oracle.com >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2012-10-18, at 9:06 AM, Pedro Felix wrote: >>>>>=20 >>>>> > Hi, >>>>> > >>>>> > Where can I find more information about the dynamic registration = of client application instances? >>>>> > The idea is that each installed application instance has a = different id, eventually related to the "general" application id. >>>>> > >>>>> > It also would be interesting if this instance id was the result = of an activation process, where the instance is attached to a device or = to an user (e.g. confimed email address). >>>>> > >>>>> > Thanks >>>>> > Pedro >>>>> > >>>>> > _______________________________________________ >>>>> > OAuth mailing list >>>>> > OAuth@ietf.org >>>>> > https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_48242975-E0F7-4D5E-ADED-21E523A53261 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = agree with your assessment here.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-10-19, at 11:12 AM, John Bradley wrote:

It = would be nice if software signing could work, however verifying that = over a network connection without some sort of OS level TPM seems overly = ambitious.

We were not trying to solve that problem = with connect, only find a way that we could provision a secret for = native apps.

Certainly the registration token = can be stolen and faked by a rogue app. =  

However with a good app it lets you get = a unique client secret for the app or register a public key (something = perhaps useful for Proof of possession tokens as = well)

For web server clients this is not a big = deal because registration is a one tie = thing.

For native apps on phones etc having = every one with the same clientID and password is not a good = thing.

John = B.


On 2012-10-19, at = 2:39 PM, Phil Hunt <phil.hunt@oracle.com> = wrote:

Consider that the = issues comes from 2 angles:
1. The desire to distinguish = between instances of a client app (e.g. on mobile phones)
2. = The desire for the client to register with particular instances of a = resource service.

The objective:  to = establish a unique credential that binds a particular client instance = (or set of clients) with a particular resource service = provider.

I note that, per John's suggestion, = this is something like what OpenID Connect attempted to solve with their = dynamic registration draft.

As further input, = during the review of the OAuth Threat Model, there was significant = inquires and discussion about how to assess the legitimacy or = authenticity of a piece of client software. Though we didn't solve it, = there was a lot of requests for finding a way to authenticate client = software as simply being the one made by its = developer.

Therefore, I think there is = requirement to be able to authenticate software (at some level) that is = part of the dynamic registration process.

I = think there is a few of steps in dynamic registration.
1. A = method to authenticate the software. Is it signed by its publisher? =  If the resource being accessed is developed by a single publisher, = has the client been registered with the publisher? Hypothetical examples = of this might be clients designed to work with MS Exchange, or Oracle = CRM.
2. Optionally establishing a means to distinguish one = client instance from another.
3. Dynamically issuing the = client with a credential (which may or may not be instance specific) to = use with a particular instance of a resource authorization = server.

Regarding step 1, I note that in the = case OpenID Connect, there is no single place to even register a client = as there is with proprietary APIs. Not sure if software signing can work = here. The same problem will emerge with any standards based API (e.g. = such as SCIM).  This is why I think dynamic registration is of = broad interest in the standards community beyond just = OpenID.

Phil
www.independentid.com
phil.hunt@oracle.com





On 2012-10-19, at 9:40 AM, George Fletcher wrote:

=20 =20
I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned.

I do agree that from the AS/OP perspective, we don't want to allow unlimited client registrations. This could be it's own form of DoS attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope.

There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established.

Thanks,
George

On 10/19/12 12:00 PM, Pedro Felix wrote:
And what if the client instance is also connected = to some verifiable user attribute, such as an email?
Is this a bad idea?

Pedro

On Fri, Oct 19, 2012 at 4:24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft.


The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key.

There was a long discussion about this at a IIW about a year ago.   

In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients.

John B.



On 2012-10-19, at 11:47 AM, Pedro Felix <pmhsfelix@gmail.com> wrote:

Thanks for the = response.

I know that this area is work in progress. However, I've looked into http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of client application instances?
> The idea is that each installed application instance has a different id, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address).
>
> Thanks
> Pedro
>
> = _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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




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

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

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


= --Apple-Mail=_48242975-E0F7-4D5E-ADED-21E523A53261-- From jricher@mitre.org Fri Oct 19 12:10:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C10121F876C for ; Fri, 19 Oct 2012 12:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1M2K3hVzRm2 for ; Fri, 19 Oct 2012 12:10:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB121F875A for ; Fri, 19 Oct 2012 12:10:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 97EF71F066B; Fri, 19 Oct 2012 15:10:35 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7DE291F0669; Fri, 19 Oct 2012 15:10:35 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Fri, 19 Oct 2012 15:10:35 -0400 From: "Richer, Justin P." To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Agenda for Atlanta Meeting Thread-Index: AQHNos/0R5eCCH1cbkSmVf7KyytBnJesx4uAgAAdowCAAWRRAIADY9EAgACbDYCAAD5ZAIAO0YwA Date: Fri, 19 Oct 2012 19:10:34 +0000 Message-ID: References: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> <5070654D.40007@lodderstedt.net> <97A330AD-C451-4472-B38C-EF59034EC810@oracle.com> <50753768.5020900@gmx.net> In-Reply-To: <50753768.5020900@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.60.29] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5FB652DBC36018428F1C9412843AB6F2@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:10:44 -0000 On those lines, I've been asked to sign up as co-editor for the dynamic cli= ent registration document, and I'd be OK with that. There are a lot of litt= le side documents that I'd like to see finalized (XML encoding, instance, U= X, dynamic reg, chained auth, MAC). We can discuss details at either IIW or= IETF -- but it's something that I'd definitely like to help see through ho= w I can. -- Justin On Oct 10, 2012, at 4:52 AM, Hannes Tschofenig wrote: > Hi Justin, Hi Torsten, >=20 > We will take care of appropriate time management and agenda topics that h= ave not seen enough presentation on the list will be postponed. >=20 > In fact, I am concerned about the progress with the use cases document an= d the dynamic client registration work. I have notified the authors of my c= oncerns privately already. >=20 > Ciao > Hannes >=20 > On 10/10/2012 08:09 AM, Torsten Lodderstedt wrote: >> +1 >>=20 >>=20 >>=20 >> "Richer, Justin P." schrieb: >>=20 >> Good for me, AS LONG AS we make absolutely SURE that we leave plenty = of time for #8 on the agenda, to the point of cutting off and tabling other= discussions ahead of time. There are a lot of ancillary documents in vario= us states of use/neglect that shouldn't be left aside by the WG, and this i= s a good venue for all of that. >>=20 >> -- Justin >>=20 >> On Oct 7, 2012, at 12:08 PM, Zeltsan, Zachary (Zachary) wrote: >>=20 >> +1 >>=20 >> Zachary >>=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf Of Phil Hunt >> Sent: Saturday, October 06, 2012 2:54 PM >> To: Torsten Lodderstedt >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting >>=20 >> +1 >>=20 >> Phil >>=20 >> On 2012-10-06, at 10:07, Torsten Lodderstedt >> wrote: >>=20 >> fine for me >>=20 >> Am 05.10.2012 10:03, schrieb Hannes Tschofenig: >>=20 >> Hi all, >>=20 >> here is an agenda proposal for the Atlanta IETF meeting: >> (The indicated names are proposals.) >>=20 >> ------ >> Agenda: >>=20 >> 1. Status Update, Agenda Bashing (Chairs) >> 2. Token Revocation (Thorsten) >> 3. Assertions (Brian + Mike) >> 4. OAuth Use Cases (Zachary) >> 5. JWT (Mike) >> 6. Security (Phil) >> 7. Dynamic Client Registration (Thomas) >> 8. Roadmap >> ------ >>=20 >> In the last item we would like to discuss the bigger >> picture of how to get OAuth 2.0 deployment improved. >> There are at least 2 parts to this, namely (a) what >> other specifications do we need to work on, and (b) how >> do we improve interoperability. >>=20 >> Let us know whether you think that this fits your needs. >>=20 >> Ciao >> Hannes & Derek >>=20 >> PS: I am hoping to see daft updates of the WG items soon. >>=20 >> ---------------------------------------------------------= --------------- >>=20 >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >> -------------------------------------------------------------= ----------- >>=20 >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> -----------------------------------------------------------------= ------- >>=20 >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> -----------------------------------------------------------------= ------- >>=20 >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 From phil.hunt@oracle.com Fri Oct 19 12:43:23 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21A821F8778 for ; Fri, 19 Oct 2012 12:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.756 X-Spam-Level: X-Spam-Status: No, score=-9.756 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hK7dky8kw38f for ; Fri, 19 Oct 2012 12:43:22 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 7381121F874B for ; Fri, 19 Oct 2012 12:43:22 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q9JJhAQA028794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Oct 2012 19:43:11 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q9JJhAvE017514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 19:43:10 GMT Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q9JJhAhr008511; Fri, 19 Oct 2012 14:43:10 -0500 Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 19 Oct 2012 12:43:09 -0700 References: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> <5070654D.40007@lodderstedt.net> <97A330AD-C451-4472-B38C-EF59034EC810@oracle.com> <50753768.5020900@gmx.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <683CFDC4-331A-4FD3-95D8-BC60D9440585@oracle.com> X-Mailer: iPhone Mail (10A403) From: Phil Hunt Date: Fri, 19 Oct 2012 12:43:09 -0700 To: "Richer, Justin P." X-Source-IP: acsinet21.oracle.com [141.146.126.237] Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 19:43:23 -0000 I will be at iiw on tues/wed.=20 Phil On 2012-10-19, at 12:10, "Richer, Justin P." wrote: > On those lines, I've been asked to sign up as co-editor for the dynamic cl= ient registration document, and I'd be OK with that. There are a lot of litt= le side documents that I'd like to see finalized (XML encoding, instance, UX= , dynamic reg, chained auth, MAC). We can discuss details at either IIW or I= ETF -- but it's something that I'd definitely like to help see through how I= can. >=20 > -- Justin >=20 > On Oct 10, 2012, at 4:52 AM, Hannes Tschofenig wrote: >=20 >> Hi Justin, Hi Torsten, >>=20 >> We will take care of appropriate time management and agenda topics that h= ave not seen enough presentation on the list will be postponed. >>=20 >> In fact, I am concerned about the progress with the use cases document an= d the dynamic client registration work. I have notified the authors of my co= ncerns privately already. >>=20 >> Ciao >> Hannes >>=20 >> On 10/10/2012 08:09 AM, Torsten Lodderstedt wrote: >>> +1 >>>=20 >>>=20 >>>=20 >>> "Richer, Justin P." schrieb: >>>=20 >>> Good for me, AS LONG AS we make absolutely SURE that we leave plenty o= f time for #8 on the agenda, to the point of cutting off and tabling other d= iscussions ahead of time. There are a lot of ancillary documents in various s= tates of use/neglect that shouldn't be left aside by the WG, and this is a g= ood venue for all of that. >>>=20 >>> -- Justin >>>=20 >>> On Oct 7, 2012, at 12:08 PM, Zeltsan, Zachary (Zachary) wrote: >>>=20 >>> +1 >>>=20 >>> Zachary >>>=20 >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>> Behalf Of Phil Hunt >>> Sent: Saturday, October 06, 2012 2:54 PM >>> To: Torsten Lodderstedt >>> Cc: oauth@ietf.org WG >>> Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting >>>=20 >>> +1 >>>=20 >>> Phil >>>=20 >>> On 2012-10-06, at 10:07, Torsten Lodderstedt >>> wrote: >>>=20 >>> fine for me >>>=20 >>> Am 05.10.2012 10:03, schrieb Hannes Tschofenig: >>>=20 >>> Hi all, >>>=20 >>> here is an agenda proposal for the Atlanta IETF meeting: >>> (The indicated names are proposals.) >>>=20 >>> ------ >>> Agenda: >>>=20 >>> 1. Status Update, Agenda Bashing (Chairs) >>> 2. Token Revocation (Thorsten) >>> 3. Assertions (Brian + Mike) >>> 4. OAuth Use Cases (Zachary) >>> 5. JWT (Mike) >>> 6. Security (Phil) >>> 7. Dynamic Client Registration (Thomas) >>> 8. Roadmap >>> ------ >>>=20 >>> In the last item we would like to discuss the bigger >>> picture of how to get OAuth 2.0 deployment improved. >>> There are at least 2 parts to this, namely (a) what >>> other specifications do we need to work on, and (b) how >>> do we improve interoperability. >>>=20 >>> Let us know whether you think that this fits your needs. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>> PS: I am hoping to see daft updates of the WG items soon. >>>=20 >>> ----------------------------------------------------------= -------------- >>>=20 >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>> --------------------------------------------------------------= ---------- >>>=20 >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> ------------------------------------------------------------------= ------ >>>=20 >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> ------------------------------------------------------------------= ------ >>>=20 >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From sakimura@gmail.com Sat Oct 20 21:37:49 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E53C21F8481 for ; Sat, 20 Oct 2012 21:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFJq6mnjfuqA for ; Sat, 20 Oct 2012 21:37:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3482C21F8470 for ; Sat, 20 Oct 2012 21:37:47 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so1153573qcg.31 for ; Sat, 20 Oct 2012 21:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=URvIeZuXZlIajHDRqxP25AhPmQzA3PL3gnV9kxOHXCg=; b=MIyDR76sH9yO1af5qsjZYw28ghPgOJJrnqAVGUMOUcDU0hwJt/jgZ2Ixa5Bfszw/ou TZLbA/ANPnoIb7286hYWckDNsh/R9DOXjr4h58haNoKxsBdSH6YNxUjxDZGmnkIuwO+R xtu3rQ7K6zS4K2HLpVPFofBpd4fNZ9p+30RIJTZNh+qZLgzLUs9A8hf34+zqMHMgbaMn GtbVJwhEiAwhS4x0QH1M5nmZb8AWVIMuVyZVZ1ohPo3s/eFqZN1eVUgd0MxMqJ2T/hYf hrzscCHwvgNmZpfsOLK+nAxnl6ZJqkXo2kNue76BNr5LmJIoOk0etveb8fOOS76OcQKa c1UA== MIME-Version: 1.0 Received: by 10.49.81.161 with SMTP id b1mr3032095qey.21.1350794266647; Sat, 20 Oct 2012 21:37:46 -0700 (PDT) Received: by 10.229.111.194 with HTTP; Sat, 20 Oct 2012 21:37:46 -0700 (PDT) In-Reply-To: References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> <50818266.5010205@aol.com> <3E1273EA-B784-485F-97D3-EA09C77E8C28@oracle.com> <29F34899-6CE6-478B-94C1-81B35E2EBA55@ve7jtb.com> Date: Sun, 21 Oct 2012 13:37:46 +0900 Message-ID: From: Nat Sakimura To: Phil Hunt Content-Type: multipart/alternative; boundary=047d7b6d84ce6d9d9f04cc8a4cfd Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 04:37:49 -0000 --047d7b6d84ce6d9d9f04cc8a4cfd Content-Type: text/plain; charset=ISO-8859-1 On the instance identification purpose, it may be interesting to generate a key-pair and register the public key out of it to the server, similar to what we do in the case of Self-Issued OP in OpenID Connect. So, the app will have the client_id, which is pre-provisioned to the same app as a "class", and the app, when first registering itself to the server will generate the "instance id" which is tied to the secret key that is typically stored in key-chain or similar devices. Note that the key generation has to be done for each server or server groups as otherwise it will become trivial to track the user across. Nat On Sat, Oct 20, 2012 at 3:35 AM, Phil Hunt wrote: > I agree with your assessment here. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-10-19, at 11:12 AM, John Bradley wrote: > > It would be nice if software signing could work, however verifying that > over a network connection without some sort of OS level TPM seems overly > ambitious. > > We were not trying to solve that problem with connect, only find a way > that we could provision a secret for native apps. > > Certainly the registration token can be stolen and faked by a rogue app. > > However with a good app it lets you get a unique client secret for the app > or register a public key (something perhaps useful for Proof of possession > tokens as well) > > For web server clients this is not a big deal because registration is a > one tie thing. > > For native apps on phones etc having every one with the same clientID and > password is not a good thing. > > John B. > > > On 2012-10-19, at 2:39 PM, Phil Hunt wrote: > > Consider that the issues comes from 2 angles: > 1. The desire to distinguish between instances of a client app (e.g. on > mobile phones) > 2. The desire for the client to register with particular instances of a > resource service. > > The objective: to establish a unique credential that binds a particular > client instance (or set of clients) with a particular resource service > provider. > > I note that, per John's suggestion, this is something like what OpenID > Connect attempted to solve with their dynamic registration draft. > > As further input, during the review of the OAuth Threat Model, there was > significant inquires and discussion about how to assess the legitimacy or > authenticity of a piece of client software. Though we didn't solve it, > there was a lot of requests for finding a way to authenticate client > software as simply being the one made by its developer. > > Therefore, I think there is requirement to be able to authenticate > software (at some level) that is part of the dynamic registration process. > > I think there is a few of steps in dynamic registration. > 1. A method to authenticate the software. Is it signed by its publisher? > If the resource being accessed is developed by a single publisher, has the > client been registered with the publisher? Hypothetical examples of this > might be clients designed to work with MS Exchange, or Oracle CRM. > 2. Optionally establishing a means to distinguish one client instance from > another. > 3. Dynamically issuing the client with a credential (which may or may not > be instance specific) to use with a particular instance of a resource > authorization server. > > Regarding step 1, I note that in the case OpenID Connect, there is no > single place to even register a client as there is with proprietary APIs. > Not sure if software signing can work here. The same problem will emerge > with any standards based API (e.g. such as SCIM). This is why I think > dynamic registration is of broad interest in the standards community beyond > just OpenID. > > Phil > > @independentid > www.independentid.com > phil.hunt@oracle.com > > > > > > On 2012-10-19, at 9:40 AM, George Fletcher wrote: > > I think it's an interesting idea... I'm just not sure how to tie the > dynamic client registration to a verified user email address. To get a > verified email address, most OAuth2 flows require the client_id to be > already provisioned. > > I do agree that from the AS/OP perspective, we don't want to allow > unlimited client registrations. This could be it's own form of DoS attack. > I suppose if the client has a verifiable token containing the user > attributes, that could be passed optionally to the dynamic client > registration flow. How the client got the verifiable token could be left > out of scope. > > There are probably other ways to protect against abuse and they will > likely be different from OP to OP for a while, until some best practices > are established. > > Thanks, > George > > On 10/19/12 12:00 PM, Pedro Felix wrote: > > And what if the client instance is also connected to some verifiable user > attribute, such as an email? > Is this a bad idea? > > Pedro > > On Fri, Oct 19, 2012 at 4:24 PM, John Bradley wrote: > >> The client instance registration was something that we discussed and put >> into the openID Connect dynamic client registration but has not yet been >> put back into the UMA draft. >> >> http://openid.bitbucket.org/openid-connect-registration-1_0.html >> >> The basic idea is that you can bake a access token into client code and >> that client then uses that to get a unique clientID and secret/register >> public key. >> >> There was a long discussion about this at a IIW about a year ago. >> >> In some of the native apps projects I am looking at that are not openID >> connect related we are looking at doing the same thing to differentiate >> instances of clients. >> >> John B. >> >> >> >> On 2012-10-19, at 11:47 AM, Pedro Felix wrote: >> >> Thanks for the response. >> >> I know that this area is work in progress. However, I've looked into >> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found >> much about this subject. >> What is the best place to follow this discussion? This mailing list? >> >> Thanks >> Pedro >> >> On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt wrote: >> >>> Pedro, >>> >>> AFAIK this is still a TODO within the current charter. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.hunt@oracle.com >>> >>> >>> >>> >>> >>> On 2012-10-18, at 9:06 AM, Pedro Felix wrote: >>> >>> > Hi, >>> > >>> > Where can I find more information about the dynamic registration of >>> client application instances? >>> > The idea is that each installed application instance has a different >>> id, eventually related to the "general" application id. >>> > >>> > It also would be interesting if this instance id was the result of an >>> activation process, where the instance is attached to a device or to an >>> user (e.g. confimed email address). >>> > >>> > Thanks >>> > Pedro >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b6d84ce6d9d9f04cc8a4cfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On the instance identification purpose, it may be interesting to generate a= key-pair and register the public key out of it to the server, similar to w= hat we do in the case of Self-Issued OP in OpenID Connect.=A0

So, the app will have the client_id, which is pre-provisioned to the s= ame app as a "class", and the app, when first registering itself = to the server will generate the "instance id" which is tied to th= e secret key that is typically stored in key-chain or similar devices.=A0

Note that the key generation has to be done for each se= rver or server groups as otherwise it will become trivial to track the user= across.=A0

Nat

On Sat, Oct 20, 2012 at 3:35 AM, Phil Hunt <phil.hunt@oracle.com>= ; wrote:
I agree with your assessment here.
=

On 2012-10-19, at 11:12 AM, John Bradley wrote:

It would be nice = if software signing could work, however verifying that over a network conne= ction without some sort of OS level TPM seems overly ambitious.

We were not trying to solve that problem with connect, only = find a way that we could provision a secret for native apps.

=
Certainly the registration token can be stolen and faked by a ro= gue app. =A0

However with a good app it lets you get a unique client= secret for the app or register a public key (something perhaps useful for = Proof of possession tokens as well)

For web server= clients this is not a big deal because registration is a one tie thing.

For native apps on phones etc having every one with the= same clientID and password is not a good thing.

J= ohn B.


On 2012-10-19, at = 2:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Cons= ider that the issues comes from 2 angles:
1. The desire to distin= guish between instances of a client app (e.g. on mobile phones)
2= . The desire for the client to register with particular instances of a reso= urce service.

The objective: =A0to establish a unique credential that= binds a particular client instance (or set of clients) with a particular r= esource service provider.

I note that, per John= 9;s suggestion, this is something like what OpenID Connect attempted to sol= ve with their dynamic registration draft.

As further input, during the review of the OAuth Threat= Model, there was significant inquires and discussion about how to assess t= he legitimacy or authenticity of a piece of client software. Though we didn= 't solve it, there was a lot of requests for finding a way to authentic= ate client software as simply being the one made by its developer.

Therefore, I think there is requirement to be able to a= uthenticate software (at some level) that is part of the dynamic registrati= on process.

I think there is a few of steps in dyn= amic registration.
1. A method to authenticate the software. Is it signed by its publishe= r? =A0If the resource being accessed is developed by a single publisher, ha= s the client been registered with the publisher? Hypothetical examples of t= his might be clients designed to work with MS Exchange, or Oracle CRM.
2. Optionally establishing a means to distinguish one client instance = from another.
3. Dynamically issuing the client with a credential= (which may or may not be instance specific) to use with a particular insta= nce of a resource authorization server.

Regarding step 1, I note that in the case OpenID Connec= t, there is no single place to even register a client as there is with prop= rietary APIs. Not sure if software signing can work here. The same problem = will emerge with any standards based API (e.g. such as SCIM). =A0This is wh= y I think dynamic registration is of broad interest in the standards commun= ity beyond just OpenID.

Phil

@independentid
<= a href=3D"mailto:phil.hunt@oracle.com" target=3D"_blank">phil.hunt@oracle.c= om





On 2012-10-19, at 9:40 AM, George Fletcher wrote:

=20 =20 =20
I think it's an interesting idea... I'm just not sure how to tie the dynamic client registration to a verified user email address. To get a verified email address, most OAuth2 flows require the client_id to be already provisioned.

I do agree that from the AS/OP perspective, we don't want to allo= w unlimited client registrations. This could be it's own form of Do= S attack. I suppose if the client has a verifiable token containing the user attributes, that could be passed optionally to the dynamic client registration flow. How the client got the verifiable token could be left out of scope.

There are probably other ways to protect against abuse and they will likely be different from OP to OP for a while, until some best practices are established.

Thanks,
George

On 10/19/12 12:00 PM, Pedro Felix wrote:
And what if the client instance is also conne= cted to some verifiable user attribute, such as an email?
Is this a bad idea?

Pedro

On Fri, Oct 19, 2012 at 4:24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
The client instance registration was something that we discussed and put into the openID Connect dynamic client registration but has not yet been put back into the UMA draft.


The basic idea is that you can bake a access token into client code and that client then uses that to get a unique clientID and secret/register public key.

There was a long discussion about this at a IIW about a year ago. =A0=A0

In some of the native apps projects I am looking at that are not openID connect related we are looking at doing the same thing to differentiate instances of clients.

John B.



On 2012-10-19, at 11:47 AM, Pedro Felix <pmhsfelix@gmail.com> wrote:

Thanks for the response.

I know that this area is work in progress. However, I've looked into=A0http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00=A0and didn't found much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt = <phil.hunt@ora= cle.com> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of client application instances?
> The idea is that each installed application instance has a different id, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of an activation process, where the instance is attached to a device or to an user (e.g. confimed email address).
>
> Thanks
> Pedro
>
> ___________________________________________= ____
> 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/oauth 




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

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

________________________________________= _______
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h



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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
--047d7b6d84ce6d9d9f04cc8a4cfd-- From internet-drafts@ietf.org Mon Oct 22 11:48:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9AB11E80EE; Mon, 22 Oct 2012 11:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4pWF-ReVkbF; Mon, 22 Oct 2012 11:48:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5954311E80F7; Mon, 22 Oct 2012 11:48:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022184810.15523.65255.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 11:48:10 -0700 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-use-cases-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:48:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth Use Cases Author(s) : George Fletcher Torsten Lodderstedt Zachary Zeltsan Filename : draft-ietf-oauth-use-cases-03.txt Pages : 24 Date : 2012-10-22 Abstract: This document lists the OAuth use cases. The provided list is based on the Internet Drafts of the OAUTH working group and discussions on the group's mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-use-cases-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-use-cases-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zachary.zeltsan@alcatel-lucent.com Mon Oct 22 11:56:21 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713D421F88BE for ; Mon, 22 Oct 2012 11:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.915 X-Spam-Level: X-Spam-Status: No, score=-9.915 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZAHwsPzSd-H for ; Mon, 22 Oct 2012 11:56:19 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEB021F8880 for ; Mon, 22 Oct 2012 11:56:16 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q9MItjBM012272 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 22 Oct 2012 20:56:10 +0200 Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 22 Oct 2012 20:56:08 +0200 Received: from US70TWXCHMBA09.zam.alcatel-lucent.com ([169.254.3.198]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Mon, 22 Oct 2012 14:56:05 -0400 From: "Zeltsan, Zachary (Zachary)" To: "'oauth@ietf.org'" Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-use-cases-03.txt Thread-Index: AQHNsIXbG5M/JzQFz0G0ZS3QfazEnpfFqr8A Date: Mon, 22 Oct 2012 18:56:04 +0000 Message-ID: References: <20121022184810.15523.65255.idtracker@ietfa.amsl.com> In-Reply-To: <20121022184810.15523.65255.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-use-cases-03.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:56:21 -0000 In this version the example URLs have been changed as suggested in http://www.ietf.org/mail-archive/web/oauth/current/msg09978.html . There are no other changes. Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Monday, October 22, 2012 2:48 PM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-use-cases-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Authorization Protocol Working Group = of the IETF. Title : OAuth Use Cases Author(s) : George Fletcher Torsten Lodderstedt Zachary Zeltsan Filename : draft-ietf-oauth-use-cases-03.txt Pages : 24 Date : 2012-10-22 Abstract: This document lists the OAuth use cases. The provided list is based on the Internet Drafts of the OAUTH working group and discussions on the group's mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-oauth-use-cases-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-use-cases-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From pmhsfelix@gmail.com Tue Oct 23 10:37:14 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F071F0C89 for ; Tue, 23 Oct 2012 10:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnhyhD7A2o2r for ; Tue, 23 Oct 2012 10:37:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3C71F0419 for ; Tue, 23 Oct 2012 10:37:12 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so600421lbo.31 for ; Tue, 23 Oct 2012 10:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QiPE1QzqsBf0Ou8X5Bd4izq5e1ANwDKaaDeZ3tVkMfc=; b=x3sQJabGVdD7frQOYL03XvbgSL6o0uloACEx9/IFDr+HSrY//H6iXz1Tnhf05Fyerl eVzjMKGcojwLtEX/3LXERcQdIJ5Vy3siSIbMkuZbbVlYWCRi2f4uOAAZGYjLcdBk2r1x 8m1PfcUYshkr1RpIb4NDgBnH7SgjkJG7creS7MyYSi4alRabq9T2sXnhC9eHFBoQU57V 9AY+AL4UbcYMdsHldRUIFWqTPOMwp1JZ5ceh+1V9SuzkwvnT3XCUZIyNcsR7lfuu42hQ wXKYWlibaL+c2AFVITj3Uq+tjk1MWGcFfNoWXzovJrdpdMnz4yfLXfdUYsRwvPuAaJ3E 5YhA== MIME-Version: 1.0 Received: by 10.152.135.139 with SMTP id ps11mr12006929lab.29.1351013827978; Tue, 23 Oct 2012 10:37:07 -0700 (PDT) Received: by 10.112.54.7 with HTTP; Tue, 23 Oct 2012 10:37:07 -0700 (PDT) Date: Tue, 23 Oct 2012 18:37:07 +0100 Message-ID: From: Pedro Felix To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f46d0435bf4e4da3fa04ccbd6b4c Subject: [OAUTH-WG] MAC Access Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 17:37:14 -0000 --f46d0435bf4e4da3fa04ccbd6b4c Content-Type: text/plain; charset=ISO-8859-1 What is the future of http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-01, which already expired? Is it going forward? Thanks Pedro --f46d0435bf4e4da3fa04ccbd6b4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is the future of=A0http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac= -01, which already expired? Is it going forward?

Tha= nks
Pedro
--f46d0435bf4e4da3fa04ccbd6b4c-- From eve@xmlgrrl.com Tue Oct 23 16:24:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC0511E80D7 for ; Tue, 23 Oct 2012 16:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8j1mVgvEfaj for ; Tue, 23 Oct 2012 16:24:10 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4914811E80E3 for ; Tue, 23 Oct 2012 16:24:08 -0700 (PDT) Received: from [172.19.131.103] ([199.106.165.39]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q9NNNh77010560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Oct 2012 16:23:56 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_1DFE0D07-058C-449B-8202-3BBFF23D0CEC" From: Eve Maler In-Reply-To: Date: Tue, 23 Oct 2012 16:23:40 -0700 Message-Id: <5A9D1949-9CD2-479D-85C0-3E726207DC05@xmlgrrl.com> References: To: zhou.sujing@zte.com.cn X-Mailer: Apple Mail (2.1499) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:24:11 -0000 --Apple-Mail=_1DFE0D07-058C-449B-8202-3BBFF23D0CEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sorry for the delay. Here's what I was thinking about: https://dev.twitter.com/docs/auth/oauth/oauth-echo -- The delegation = here (using OAuth V1) is about client 1 delegating to client 2, still = presumably operated by the same human user throughout. http://tools.ietf.org/html/draft-vrancken-oauth-redelegation-01 - I've = never fully understood this one, to be honest, but it seems different = from Echo. There's also this: http://tools.ietf.org/html/draft-richer-oauth-chain-00 - This is, I = believe, explicitly for scoping the delegated access smaller than it was = originally. And this: http://tools.ietf.org/html/draft-hunt-oauth-chain-00 - Yet a different = pattern from what I can see. I'll try and answer your other emails as soon as I can... Eve On 17 Oct 2012, at 7:28 PM, zhou.sujing@zte.com.cn wrote: >=20 > Hi, Eve=20 >=20 > Sorry for reply late. I somehow missed the emails from OAUTH list.=20= >=20 > "If the client/requesting party is literally acting on behalf of = the initial RO, then it would seem to me that this is closer to the = discussions of "redelegation" and Twitter Echo and such from the past. = UMA's use cases have to do with authorizing delegated access that is = performed on behalf of the client itself (the word "autonomous" from = OAuth 1.0 springs to mind). Eve"=20 >=20 > Can you give me the link of discussion in the past you mentioned?=20 > The usecase Hardjono rediscribed may not necessarily invloving = "redelegation", a more general case would be the Babysitter directly = show delegation to the Teacher and walk the child home.=20 > =20 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_1DFE0D07-058C-449B-8202-3BBFF23D0CEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://dev.tw= itter.com/docs/auth/oauth/oauth-echo -- The delegation here (using = OAuth V1) is about client 1 delegating to client 2, still presumably = operated by the same human user throughout.
h= ttp://tools.ietf.org/html/draft-vrancken-oauth-redelegation-01 - = I've never fully understood this one, to be honest, but it seems = different from Echo.

There's also = this:

http://too= ls.ietf.org/html/draft-richer-oauth-chain-00 - This is, I believe, = explicitly for scoping the delegated access smaller than it was = originally.

And = this:

http://tools= .ietf.org/html/draft-hunt-oauth-chain-00 - Yet a different pattern = from what I can see.

I'll try and answer your = other emails as soon as I can...

= Eve

On 17 Oct 2012, at 7:28 PM, zhou.sujing@zte.com.cn = wrote:


Hi, Eve

   Sorry for reply late. I somehow missed the emails from OAUTH list.

   "If the client/requesting party is literally acting on behalf of the initial RO, then it would seem to me that this is closer to the discussions of "redelegation" and Twitter Echo and such from the past. UMA's use cases have to do with = authorizing delegated access that is performed on behalf of the client itself (the word "autonomous" from OAuth 1.0 springs to mind). Eve"

  Can you give me the link = of discussion in the past you mentioned?
  The usecase Hardjono = rediscribed may not necessarily invloving "redelegation", a more general case would be the Babysitter directly show delegation to the Teacher and walk the child home.
   


Eve Maler       =                     =        http://www.xmlgrrl.com/blog
+1= 425 345 6756                 =         http://www.twitter.com/xmlgrrl=


= --Apple-Mail=_1DFE0D07-058C-449B-8202-3BBFF23D0CEC-- From eve@xmlgrrl.com Tue Oct 23 16:37:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA85F1F0C3A for ; Tue, 23 Oct 2012 16:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.292 X-Spam-Level: X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll0dSOctb5Ak for ; Tue, 23 Oct 2012 16:37:06 -0700 (PDT) Received: from promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id D4E2A21F8776 for ; Tue, 23 Oct 2012 16:37:06 -0700 (PDT) Received: from [172.19.131.103] ([199.106.165.39]) (authenticated bits=0) by promanage-inc.com (8.14.4/8.14.4) with ESMTP id q9NNapnX010932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Oct 2012 16:36:59 -0700 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_4A969C70-3D8A-4833-BDD5-EC93E1F66B49" From: Eve Maler In-Reply-To: <508033F4.1070704@alcatel-lucent.com> Date: Tue, 23 Oct 2012 16:36:48 -0700 Message-Id: References: <508033F4.1070704@alcatel-lucent.com> To: igor.faynberg@alcatel-lucent.com X-Mailer: Apple Mail (2.1499) Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 23:37:07 -0000 --Apple-Mail=_4A969C70-3D8A-4833-BDD5-EC93E1F66B49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Igor-- If you mean enabling (um) Grandma Goldie to delegate child = pickup duties to Tom the Taxi Driver after having been herself delegated = to pick up the child by Peter Parent, then -- as long as we're focusing = on policy-based claims-tested authorization for requesting party access, = then UMA would likely treat both cases of delegation as the normal = course of business since the UMA host (RS) doesn't care how the current = authorizing user (RO) "won" its own access in the first place. If we're only talking about the realm of client app (UMA requester) = identities and not an actual legally liable third party, there are a = number of OAuth profiling tricks that can be, and seem to have been, = proposed... For folks interested in the use cases with the legally liable parties, = you can find a passel of them here: http://docs.kantarainitiative.org/uma/draft-uma-trust.html (particularly = the Use Cases section: = http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1) = http://kantarainitiative.org/confluence/download/attachments/62324760/UMA_= Personal_Loan_v01.pdf - explores RO-to-organization sharing in detail These are, of course, in addition to the original (now pretty old) use = cases doc I've mentioned on this list before: = http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+= Cases Eve On 18 Oct 2012, at 9:53 AM, Igor Faynberg = wrote: > Looks like a good description of a new use case to me! >=20 > Igor >=20 > On 10/17/2012 10:23 PM, zhou.sujing@zte.com.cn wrote: >>=20 >>=20 >> Hi, Thomas,=20 >>=20 >> Sorry for reply late. I somehow missed the emails from OAUTH list.=20= >>=20 >> "What may not be clear up-front from reading the UMA core spec is = that >> there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting >> Party) and Bob's portal/platform (Requester)). >>=20 >> Here's a more accurate picture: >>=20 >> - I deposit my Child at the Kindergarten. >> - I delegate my old Grandmother to pick up the Child. >> - My Grandmother takes a taxi. >> - The taxi Driver acts as proxy to my old Grandmother who stays in = the >> taxi. >> - The taxi Driver needs to show 2 forms of Delegation to the Teacher. >> - The Taxi driver walks the Child to the taxi. >>=20 >> Bear in mind that my Grandmother now has to manage the delegation she >> gave the taxi Driver (plus the Scopes involved)."=20 >>=20 >>=20 >> If I understand correctly, old Grandma means Bob the requesting = Party,=20 >> the taxi driver means Bob the requester in UMA?=20 >> Not talking about UMA, Bob is not separate between roles in OAUTH,=20= >> so don't have to redelegate in OAUTH? >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl --Apple-Mail=_4A969C70-3D8A-4833-BDD5-EC93E1F66B49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

If we're only talking about the realm of = client app (UMA requester) identities and not an actual legally liable = third party, there are a number of OAuth profiling tricks that can be, = and seem to have been, proposed...

For folks = interested in the use cases with the legally liable parties, you can = find a passel of them here:

http:/= /docs.kantarainitiative.org/uma/draft-uma-trust.html (particularly = the Use Cases section: http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1)<= /div>

These are, = of course, in addition to the original (now pretty old) use cases doc = I've mentioned on this list before:


= Eve

On 18 Oct 2012, at 9:53 AM, Igor Faynberg = <igor.faynberg@alcatel-luc= ent.com> wrote:

=20 =20 =20
Looks like a good description of a new use case to me!

Igor

On 10/17/2012 10:23 PM, zhou.sujing@zte.com.cn wrote:

Hi, Thomas,

   Sorry for reply late. I somehow missed the emails from OAUTH list.

"What may not be clear up-front from reading the UMA core spec is that
there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting
Party) and Bob's portal/platform (Requester)).

Here's a more accurate picture:

- I deposit my Child at the Kindergarten.
- I delegate my old Grandmother to pick up the Child.
- My Grandmother takes a taxi.
- The taxi Driver acts as proxy to my old Grandmother who stays in the
taxi.
- The taxi Driver needs to show 2 forms of Delegation to the Teacher.
- The Taxi driver walks the Child to the taxi.

Bear in mind that my Grandmother now has to manage the delegation she
gave the taxi Driver (plus the Scopes involved)."


If I understand correctly, old Grandma means Bob the requesting Party,
the taxi driver means Bob the requester in UMA?
Not talking  about UMA, Bob is not separate between roles in OAUTH,
so don't have to redelegate in 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


Eve Maler       =                     =        http://www.xmlgrrl.com/blog
+1= 425 345 6756                 =         http://www.twitter.com/xmlgrrl=


= --Apple-Mail=_4A969C70-3D8A-4833-BDD5-EC93E1F66B49-- From jricher@mitre.org Tue Oct 23 23:21:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903CB21F8CC3 for ; Tue, 23 Oct 2012 23:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3FvV5q1KRlb for ; Tue, 23 Oct 2012 23:21:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8526C21F8CBF for ; Tue, 23 Oct 2012 23:21:18 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A4DF51F050F; Wed, 24 Oct 2012 02:21:17 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 91E9E1F050B; Wed, 24 Oct 2012 02:21:17 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Wed, 24 Oct 2012 02:21:17 -0400 From: "Richer, Justin P." To: Pedro Felix Thread-Topic: [OAUTH-WG] MAC Access Authentication Thread-Index: AQHNsUUMSk1LcwMkeEWPw4uKeS0rXJfIQA8A Date: Wed, 24 Oct 2012 06:21:16 +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: [172.31.61.76] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06842C82IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] MAC Access Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 06:21:19 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06842C82IMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It's officially still "up in the air", as the WG and its chairs are trying = to figure out whether the MAC draft is worth resurrecting as-is or if there= 's another, more general solution to signing-based tokens that can work. Current thinking, after a session at an IIW earlier today on this very topi= c, seems to be that there may be room for several parallel token types to a= ddress different use cases. But, like I said, we all still have to iron tha= t out. My personal preference would be to take the MAC draft, clean it up, and get= it finished ASAP while other drafts, like several holder-of-key ideas, als= o get worked out. -- Justin On Oct 23, 2012, at 10:37 AM, Pedro Felix wrote: What is the future of http://tools.ietf.org/html/draft-ietf-oauth-v2-http-m= ac-01, which already expired? Is it going forward? Thanks Pedro _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E06842C82IMCMBX01MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9549DDBFDF6C6D4F9FB529875FB2FAEE@imc.mitre.org> Content-Transfer-Encoding: quoted-printable It's officially still "up in the air", as the WG and its chairs a= re trying to figure out whether the MAC draft is worth resurrecting as-is o= r if there's another, more general solution to signing-based tokens that ca= n work.

Current thinking, after a session at an IIW earlier today on this very= topic, seems to be that there may be room for several parallel token types= to address different use cases. But, like I said, we all still have to iro= n that out.

My personal preference would be to take the MAC draft, clean it up, an= d get it finished ASAP while other drafts, like several holder-of-key ideas= , also get worked out.

 -- Justin

On Oct 23, 2012, at 10:37 AM, Pedro Felix wrote:

What is the future of http://tools.ietf.org/html= /draft-ietf-oauth-v2-http-mac-01, which already expired? Is it going fo= rward?

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

--_000_B33BFB58CCC8BE4998958016839DE27E06842C82IMCMBX01MITREOR_-- From jricher@mitre.org Tue Oct 23 23:33:20 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F8921F8D3C for ; Tue, 23 Oct 2012 23:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dc5xqrv7sr3n for ; Tue, 23 Oct 2012 23:33:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95521F8D33 for ; Tue, 23 Oct 2012 23:33:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B162453100B2; Wed, 24 Oct 2012 02:33:14 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9AA03531009B; Wed, 24 Oct 2012 02:33:14 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.132]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Wed, 24 Oct 2012 02:33:13 -0400 From: "Richer, Justin P." To: Nat Sakimura Thread-Topic: [OAUTH-WG] Dynamic registration of client application instances Thread-Index: AQHNrUrucjSuzItl/kWRCdt1oXVQqZe/jEUAgAFtlICAAApbgIAACgaAgAALCACAABCMAIAACVgAgAAGUwCAAjqhAIAE1z8A Date: Wed, 24 Oct 2012 06:33:13 +0000 Message-ID: References: <69257CDC-072D-4648-9922-1A6DACFC90C9@oracle.com> <50818266.5010205@aol.com> <3E1273EA-B784-485F-97D3-EA09C77E8C28@oracle.com> <29F34899-6CE6-478B-94C1-81B35E2EBA55@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.61.76] Content-Type: multipart/alternative; boundary="_000_B33BFB58CCC8BE4998958016839DE27E06843D91IMCMBX01MITREOR_" MIME-Version: 1.0 Cc: "" Subject: Re: [OAUTH-WG] Dynamic registration of client application instances X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 06:33:20 -0000 --_000_B33BFB58CCC8BE4998958016839DE27E06843D91IMCMBX01MITREOR_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There's also this means of providing identifying instance information for a= single client registration: http://tools.ietf.org/html/draft-richer-oauth-instance-00 This is solving a different need and can be used in tandem with, or in lieu= of, the dynamic registration per-client, depending on your use case. Somet= imes you're happy with just one registered client_id but want to track mult= iple copies of it getting tokens -- that's what this extension is for. -- Justin On Oct 20, 2012, at 9:37 PM, Nat Sakimura wrote: On the instance identification purpose, it may be interesting to generate a= key-pair and register the public key out of it to the server, similar to w= hat we do in the case of Self-Issued OP in OpenID Connect. So, the app will have the client_id, which is pre-provisioned to the same a= pp as a "class", and the app, when first registering itself to the server w= ill generate the "instance id" which is tied to the secret key that is typi= cally stored in key-chain or similar devices. Note that the key generation has to be done for each server or server group= s as otherwise it will become trivial to track the user across. Nat On Sat, Oct 20, 2012 at 3:35 AM, Phil Hunt > wrote: I agree with your assessment here. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-10-19, at 11:12 AM, John Bradley wrote: It would be nice if software signing could work, however verifying that ove= r a network connection without some sort of OS level TPM seems overly ambit= ious. We were not trying to solve that problem with connect, only find a way that= we could provision a secret for native apps. Certainly the registration token can be stolen and faked by a rogue app. However with a good app it lets you get a unique client secret for the app = or register a public key (something perhaps useful for Proof of possession = tokens as well) For web server clients this is not a big deal because registration is a one= tie thing. For native apps on phones etc having every one with the same clientID and p= assword is not a good thing. John B. On 2012-10-19, at 2:39 PM, Phil Hunt > wrote: Consider that the issues comes from 2 angles: 1. The desire to distinguish between instances of a client app (e.g. on mob= ile phones) 2. The desire for the client to register with particular instances of a res= ource service. The objective: to establish a unique credential that binds a particular cl= ient instance (or set of clients) with a particular resource service provid= er. I note that, per John's suggestion, this is something like what OpenID Conn= ect attempted to solve with their dynamic registration draft. As further input, during the review of the OAuth Threat Model, there was si= gnificant inquires and discussion about how to assess the legitimacy or aut= henticity of a piece of client software. Though we didn't solve it, there w= as a lot of requests for finding a way to authenticate client software as s= imply being the one made by its developer. Therefore, I think there is requirement to be able to authenticate software= (at some level) that is part of the dynamic registration process. I think there is a few of steps in dynamic registration. 1. A method to authenticate the software. Is it signed by its publisher? I= f the resource being accessed is developed by a single publisher, has the c= lient been registered with the publisher? Hypothetical examples of this mig= ht be clients designed to work with MS Exchange, or Oracle CRM. 2. Optionally establishing a means to distinguish one client instance from = another. 3. Dynamically issuing the client with a credential (which may or may not b= e instance specific) to use with a particular instance of a resource author= ization server. Regarding step 1, I note that in the case OpenID Connect, there is no singl= e place to even register a client as there is with proprietary APIs. Not su= re if software signing can work here. The same problem will emerge with any= standards based API (e.g. such as SCIM). This is why I think dynamic regi= stration is of broad interest in the standards community beyond just OpenID= . Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-10-19, at 9:40 AM, George Fletcher wrote: I think it's an interesting idea... I'm just not sure how to tie the dynami= c client registration to a verified user email address. To get a verified e= mail address, most OAuth2 flows require the client_id to be already provisi= oned. I do agree that from the AS/OP perspective, we don't want to allow unlimite= d client registrations. This could be it's own form of DoS attack. I suppos= e if the client has a verifiable token containing the user attributes, that= could be passed optionally to the dynamic client registration flow. How th= e client got the verifiable token could be left out of scope. There are probably other ways to protect against abuse and they will likely= be different from OP to OP for a while, until some best practices are esta= blished. Thanks, George On 10/19/12 12:00 PM, Pedro Felix wrote: And what if the client instance is also connected to some verifiable user a= ttribute, such as an email? Is this a bad idea? Pedro On Fri, Oct 19, 2012 at 4:24 PM, John Bradley > wrote: The client instance registration was something that we discussed and put in= to the openID Connect dynamic client registration but has not yet been put = back into the UMA draft. http://openid.bitbucket.org/openid-connect-registration-1_0.html The basic idea is that you can bake a access token into client code and tha= t client then uses that to get a unique clientID and secret/register public= key. There was a long discussion about this at a IIW about a year ago. In some of the native apps projects I am looking at that are not openID con= nect related we are looking at doing the same thing to differentiate instan= ces of clients. John B. On 2012-10-19, at 11:47 AM, Pedro Felix > wrote: Thanks for the response. I know that this area is work in progress. However, I've looked into http:/= /tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00 and didn't found much abou= t this subject. What is the best place to follow this discussion? This mailing list? Thanks Pedro On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt > wrote: Pedro, AFAIK this is still a TODO within the current charter. Phil @independentid www.independentid.com phil.hunt@oracle.com On 2012-10-18, at 9:06 AM, Pedro Felix wrote: > Hi, > > Where can I find more information about the dynamic registration of clien= t application instances? > The idea is that each installed application instance has a different id, = eventually related to the "general" application id. > > It also would be interesting if this instance id was the result of an act= ivation process, where the instance is attached to a device or to an user (= e.g. confimed email address). > > Thanks > Pedro > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_B33BFB58CCC8BE4998958016839DE27E06843D91IMCMBX01MITREOR_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable There's also this means of providing identifying instance information for a= single client registration:


This is solving a different need and can be used in tandem with, or in= lieu of, the dynamic registration per-client, depending on your use case. = Sometimes you're happy with just one registered client_id but want to track= multiple copies of it getting tokens -- that's what this extension is for.

 -- Justin

On Oct 20, 2012, at 9:37 PM, Nat Sakimura wrote:

On the instance identification purpose, it may be= interesting to generate a key-pair and register the public key out of it t= o the server, similar to what we do in the case of Self-Issued OP in OpenID= Connect. 

So, the app will have the client_id, which is pre-provisioned to the s= ame app as a "class", and the app, when first registering itself = to the server will generate the "instance id" which is tied to th= e secret key that is typically stored in key-chain or similar devices. 

Note that the key generation has to be done for each server or server = groups as otherwise it will become trivial to track the user across. <= /div>

Nat

On Sat, Oct 20, 2012 at 3:35 AM, Phil Hunt <phil.hunt@ora= cle.com> wrote:
I agree with your assessment here.


On 2012-10-19, at 11:12 AM, John Bradley wrote:

It would be nice if software signing co= uld work, however verifying that over a network connection without some sor= t of OS level TPM seems overly ambitious.

We were not trying to solve that problem with connect, only find a way= that we could provision a secret for native apps.

Certainly the registration token can be stolen and faked by a rogue ap= p.  

However with a good app it lets you get a unique client secret for the= app or register a public key (something perhaps useful for Proof of posses= sion tokens as well)

For web server clients this is not a big deal because registration is = a one tie thing.

For native apps on phones etc having every one with the same clientID = and password is not a good thing.

John B.


On 2012-10-19, at 2:39 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

Consider that the issues comes from 2 angles:
1. The desire to distinguish between instances of a client app (e.g. o= n mobile phones)
2. The desire for the client to register with particular instances of = a resource service.

The objective:  to establish a unique credential that binds a par= ticular client instance (or set of clients) with a particular resource serv= ice provider.

I note that, per John's suggestion, this is something like what OpenID= Connect attempted to solve with their dynamic registration draft.

As further input, during the review of the OAuth Threat Model, there w= as significant inquires and discussion about how to assess the legitimacy o= r authenticity of a piece of client software. Though we didn't solve it, th= ere was a lot of requests for finding a way to authenticate client software as simply being the one made by its = developer.

Therefore, I think there is requirement to be able to authenticate sof= tware (at some level) that is part of the dynamic registration process.

I think there is a few of steps in dynamic registration.
1. A method to authenticate the software. Is it signed by its publishe= r?  If the resource being accessed is developed by a single publisher,= has the client been registered with the publisher? Hypothetical examples o= f this might be clients designed to work with MS Exchange, or Oracle CRM.
2. Optionally establishing a means to distinguish one client instance = from another.
3. Dynamically issuing the client with a credential (which may or may = not be instance specific) to use with a particular instance of a resource a= uthorization server.

Regarding step 1, I note that in the case OpenID Connect, there is no = single place to even register a client as there is with proprietary APIs. N= ot sure if software signing can work here. The same problem will emerge wit= h any standards based API (e.g. such as SCIM).  This is why I think dynamic registration is of broad = interest in the standards community beyond just OpenID.

Phil

On 2012-10-19, at 9:40 AM, George Fletcher wrote:

I think it's an interesting idea... I'm just not sure how to tie= the dynamic client registration to a verified user email address. To get a= verified email address, most OAuth2 flows require the client_id to be already provisioned.

I do agree that from the AS/OP perspective, we don't want to allow unlimite= d client registrations. This could be it's own form of DoS attack. I suppos= e if the client has a verifiable token containing the user attributes, that= could be passed optionally to the dynamic client registration flow. How the client got the verifiable token = could be left out of scope.

There are probably other ways to protect against abuse and they will likely= be different from OP to OP for a while, until some best practices are esta= blished.

Thanks,
George

On 10/19/12 12:00 PM, Pedro Felix wrote:
And what if the client instance is also connected= to some verifiable user attribute, such as an email?
Is this a bad idea?

Pedro

On Fri, Oct 19, 2012 at 4:24 PM, John Bradley <ve7jtb@ve7jtb.co= m> wrote:
The client instance registration was so= mething that we discussed and put into the openID Connect dynamic client re= gistration but has not yet been put back into the UMA draft.


The basic idea is that you can bake a access token into client code an= d that client then uses that to get a unique clientID and secret/register p= ublic key.

There was a long discussion about this at a IIW about a year ago. &nbs= p; 

In some of the native apps projects I am looking at that are not openI= D connect related we are looking at doing the same thing to differentiate i= nstances of clients.

John B.



On 2012-10-19, at 11:47 AM, Pedro Felix <pmhsfelix@gmail.com> wrote:

Thanks for the response.

I know that this area is work in progress. However, I've looked into&n= bsp;http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-00&nb= sp;and didn't found much about this subject.
What is the best place to follow this discussion? This mailing list?

Thanks
Pedro

On Thu, Oct 18, 2012 at 5:59 PM, Phil Hunt <phil.hunt@ora= cle.com> wrote:
Pedro,

AFAIK this is still a TODO within the current charter.

Phil

@independentid
www.independent= id.com
phil.hunt@oracle.= com





On 2012-10-18, at 9:06 AM, Pedro Felix wrote:

> Hi,
>
> Where can I find more information about the dynamic registration of cl= ient application instances?
> The idea is that each installed application instance has a different i= d, eventually related to the "general" application id.
>
> It also would be interesting if this instance id was the result of an = activation process, where the instance is attached to a device or to an use= r (e.g. confimed email address).
>
> Thanks
> Pedro
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth


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




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

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

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



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




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

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

--_000_B33BFB58CCC8BE4998958016839DE27E06843D91IMCMBX01MITREOR_-- From igor.faynberg@alcatel-lucent.com Wed Oct 24 06:08:32 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A9321F88DD for ; Wed, 24 Oct 2012 06:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.995 X-Spam-Level: X-Spam-Status: No, score=-6.995 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3tLTy1OO36S for ; Wed, 24 Oct 2012 06:08:31 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 20D0921F88B4 for ; Wed, 24 Oct 2012 06:08:30 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q9OD8P0Q027965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 Oct 2012 08:08:26 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q9OD8P8E012696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Oct 2012 08:08:25 -0500 Received: from [135.244.9.100] (faynberg.lra.lucent.com [135.244.9.100]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q9OD8NQo011280; Wed, 24 Oct 2012 08:08:24 -0500 (CDT) Message-ID: <5087E847.9080207@alcatel-lucent.com> Date: Wed, 24 Oct 2012 09:08:23 -0400 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eve Maler References: <508033F4.1070704@alcatel-lucent.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000509080501020705020401" X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 13:08:32 -0000 This is a multi-part message in MIME format. --------------000509080501020705020401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks, Eve! Igor On 10/23/2012 7:36 PM, Eve Maler wrote: > Hi Igor-- If you mean enabling (um) Grandma Goldie to delegate child > pickup duties to Tom the Taxi Driver after having been herself > delegated to pick up the child by Peter Parent, then -- as long as > we're focusing on policy-based claims-tested authorization for > requesting party access, then UMA would likely treat both cases of > delegation as the normal course of business since the UMA host (RS) > doesn't care how the current authorizing user (RO) "won" its own > access in the first place. > > If we're only talking about the realm of client app (UMA requester) > identities and not an actual legally liable third party, there are a > number of OAuth profiling tricks that can be, and seem to have been, > proposed... > > For folks interested in the use cases with the legally liable parties, > you can find a passel of them here: > > http://docs.kantarainitiative.org/uma/draft-uma-trust.html > (particularly the Use Cases section: > http://docs.kantarainitiative.org/uma/draft-uma-trust.html#anchor1) > http://kantarainitiative.org/confluence/download/attachments/62324760/UMA_Personal_Loan_v01.pdf > - explores RO-to-organization sharing in detail > > These are, of course, in addition to the original (now pretty old) use > cases doc I've mentioned on this list before: > > http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases > > Eve > > On 18 Oct 2012, at 9:53 AM, Igor Faynberg > > wrote: > >> Looks like a good description of a new use case to me! >> >> Igor >> >> On 10/17/2012 10:23 PM, zhou.sujing@zte.com.cn wrote: >>> >>> Hi, Thomas, >>> >>> Sorry for reply late. I somehow missed the emails from OAUTH list. >>> >>> "What may not be clear up-front from reading the UMA core spec is that >>> there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting >>> Party) and Bob's portal/platform (Requester)). >>> >>> Here's a more accurate picture: >>> >>> - I deposit my Child at the Kindergarten. >>> - I delegate my old Grandmother to pick up the Child. >>> - My Grandmother takes a taxi. >>> - The taxi Driver acts as proxy to my old Grandmother who stays in the >>> taxi. >>> - The taxi Driver needs to show 2 forms of Delegation to the Teacher. >>> - The Taxi driver walks the Child to the taxi. >>> >>> Bear in mind that my Grandmother now has to manage the delegation she >>> gave the taxi Driver (plus the Scopes involved)." >>> >>> >>> If I understand correctly, old Grandma means Bob the requesting Party, >>> the taxi driver means Bob the requester in UMA? >>> Not talking about UMA, Bob is not separate between roles in OAUTH, >>> so don't have to redelegate in 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 > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > --------------000509080501020705020401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks, Eve!

Igor

On 10/23/2012 7:36 PM, Eve Maler wrote:
Hi Igor-- If you mean enabling (um) Grandma Goldie to delegate child pickup duties to Tom the Taxi Driver after having been herself delegated to pick up the child by Peter Parent, then -- as long as we're focusing on policy-based claims-tested authorization for requesting party access, then UMA would likely treat both cases of delegation as the normal course of business since the UMA host (RS) doesn't care how the current authorizing user (RO) "won" its own access in the first place.

If we're only talking about the realm of client app (UMA requester) identities and not an actual legally liable third party, there are a number of OAuth profiling tricks that can be, and seem to have been, proposed...

For folks interested in the use cases with the legally liable parties, you can find a passel of them here:


These are, of course, in addition to the original (now pretty old) use cases doc I've mentioned on this list before:


Eve

On 18 Oct 2012, at 9:53 AM, Igor Faynberg <igor.faynberg@alcatel-lucent.com> wrote:

Looks like a good description of a new use case to me!

Igor

On 10/17/2012 10:23 PM, zhou.sujing@zte.com.cn wrote:

Hi, Thomas,

   Sorry for reply late. I somehow missed the emails from OAUTH list.

"What may not be clear up-front from reading the UMA core spec is that
there are 5 parties involved (AM, Alice/RO, Host, Bob (Requesting
Party) and Bob's portal/platform (Requester)).

Here's a more accurate picture:

- I deposit my Child at the Kindergarten.
- I delegate my old Grandmother to pick up the Child.
- My Grandmother takes a taxi.
- The taxi Driver acts as proxy to my old Grandmother who stays in the
taxi.
- The taxi Driver needs to show 2 forms of Delegation to the Teacher.
- The Taxi driver walks the Child to the taxi.

Bear in mind that my Grandmother now has to manage the delegation she
gave the taxi Driver (plus the Scopes involved)."


If I understand correctly, old Grandma means Bob the requesting Party,
the taxi driver means Bob the requester in UMA?
Not talking  about UMA, Bob is not separate between roles in OAUTH,
so don't have to redelegate in 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


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

--------------000509080501020705020401-- From Michael.Jones@microsoft.com Wed Oct 24 13:09:35 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2147621F866B for ; Wed, 24 Oct 2012 13:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.056 X-Spam-Level: X-Spam-Status: No, score=-3.056 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz-WE5RJQAjk for ; Wed, 24 Oct 2012 13:09:34 -0700 (PDT) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3F03621F8869 for ; Wed, 24 Oct 2012 13:09:34 -0700 (PDT) Received: from BY2FFO11FD001.protection.gbl (10.1.15.201) by BY2FFO11HUB015.protection.gbl (10.1.14.88) with Microsoft SMTP Server (TLS) id 15.0.545.8; Wed, 24 Oct 2012 20:09:24 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Wed, 24 Oct 2012 20:09:24 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Wed, 24 Oct 2012 20:09:06 +0000 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org WG" Thread-Topic: [OAUTH-WG] Agenda for Atlanta Meeting Thread-Index: AQHNos/5M9xbEndwiU2HUtvzz+V4lZfJANqQ Date: Wed, 24 Oct 2012 20:09:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436687BBC7@TK5EX14MBXC285.redmond.corp.microsoft.com> References: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> In-Reply-To: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(57704001)(497574001)(13464001)(54356001)(51856001)(33656001)(54316001)(53806001)(8716001)(16406001)(46102001)(5343655001)(20776001)(16826001)(44976002)(16696001)(4196001)(49866001)(50466001)(48376001)(2666001)(47736001)(47976001)(50986001)(74502001)(1076001)(31966008)(4396001)(47776002)(47446002)(3846001)(74662001)(316001)(3746001)(3556001); DIR:OUT; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0644578634 Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 20:09:35 -0000 One thing I'd like us to explicitly consider is to take JWT and the JWT Ass= ertion Profile to working group last call. That would make particular sens= e if the JOSE WG also takes the JOSE specs to WGLC at the same time, which = I'm asking them to consider doing in Atlanta. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Friday, October 05, 2012 1:04 AM To: oauth@ietf.org WG Subject: [OAUTH-WG] Agenda for Atlanta Meeting Hi all,=20 here is an agenda proposal for the Atlanta IETF meeting:=20 (The indicated names are proposals.) ------ Agenda: 1. Status Update, Agenda Bashing (Chairs) 2. Token Revocation (Thorsten) 3.= Assertions (Brian + Mike) 4. OAuth Use Cases (Zachary) 5. JWT (Mike) 6. Se= curity (Phil) 7. Dynamic Client Registration (Thomas) 8. Roadmap ------ In the last item we would like to discuss the bigger picture of how to get = OAuth 2.0 deployment improved. There are at least 2 parts to this, namely (= a) what other specifications do we need to work on, and (b) how do we impro= ve interoperability.=20 Let us know whether you think that this fits your needs.=20 Ciao Hannes & Derek PS: I am hoping to see daft updates of the WG items soon.=20 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From drobin1437@gmail.com Mon Oct 29 09:57:05 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B65821F874A for ; Mon, 29 Oct 2012 09:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj9CRDKqL7Hu for ; Mon, 29 Oct 2012 09:57:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 818EC21F8749 for ; Mon, 29 Oct 2012 09:57:04 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so5413459obq.31 for ; Mon, 29 Oct 2012 09:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nVq7HhdWg0ubpTEsOcseAcNHg1pnowZ9Gubs3JTFUu4=; b=ps4aoi8q6TJzXOoIxHoplAlMpas371tnT7+/44xfaNNc9dNEOPfpE46cTCSavV4O4g noe3B859cMsQz4rWcnydvGDOiFnVXtLozXRATOWDFDExVGOaqPGcfzP+dewsS928+MZh Pst19cuSmMQ7UG7hUmcpe0qqZWuvnmonJVhciP0kC4JQJr9MebFJWpop3tR4kWsS21PZ lDe9BGUe09WtoKBFggZwnjYrt2dItd0HPdXushOcIhzvVXfEY7yQUSpXgqFNvDEcxu1e ymaWyAC7RChQiJnJz0+425Rfldt/X0CBDJer3XOk7u6bk5Pe3HBigVRSny9J/gZLoD1M GKAg== MIME-Version: 1.0 Received: by 10.182.78.137 with SMTP id b9mr25660655obx.94.1351529824024; Mon, 29 Oct 2012 09:57:04 -0700 (PDT) Received: by 10.76.82.169 with HTTP; Mon, 29 Oct 2012 09:57:04 -0700 (PDT) Date: Mon, 29 Oct 2012 12:57:04 -0400 Message-ID: From: David Robinson To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f46d0444009410791904cd358f8c Subject: [OAUTH-WG] minor typo in Assertion Framework - v06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 16:57:05 -0000 --f46d0444009410791904cd358f8c Content-Type: text/plain; charset=ISO-8859-1 If already reported, then sorry for the duplication. Section 3 - Where the text talks about the two general types of assertions - Item 2 - Holder-of-Key-Assertions - the first sentence looks like it should read: To access the associated..... --f46d0444009410791904cd358f8c Content-Type: text/html; charset=ISO-8859-1 If already reported, then sorry for the duplication.

Section 3 - Where the text talks about the two general types of assertions -
Item 2 - Holder-of-Key-Assertions - the first sentence looks like it should read:

To access the associated.....
--f46d0444009410791904cd358f8c-- From Adam.Lewis@motorolasolutions.com Wed Oct 31 10:01:47 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECA521F877B for ; Wed, 31 Oct 2012 10:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZFSlIxCo9Yc for ; Wed, 31 Oct 2012 10:01:45 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id DD0D721F861A for ; Wed, 31 Oct 2012 10:01:23 -0700 (PDT) Received: from mail114-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 17:01:22 +0000 Received: from mail114-tx2 (localhost [127.0.0.1]) by mail114-tx2-R.bigfish.com (Postfix) with ESMTP id D59B18051D for ; Wed, 31 Oct 2012 17:01:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1202h1d1ah1d2ahzz17326ah8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received-SPF: pass (mail114-tx2: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT003.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail114-tx2 (localhost.localdomain [127.0.0.1]) by mail114-tx2 (MessageSwitch) id 1351702880112049_15351; Wed, 31 Oct 2012 17:01:20 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.241]) by mail114-tx2.bigfish.com (Postfix) with ESMTP id 169B93800C5 for ; Wed, 31 Oct 2012 17:01:20 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 17:01:18 +0000 Received: from il06msg01.mot-solutions.com (il06vts01.mot.com [129.188.137.141]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q9VHrwYE007303 for ; Wed, 31 Oct 2012 12:53:58 -0500 (CDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q9VHqOTK007088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Oct 2012 12:53:58 -0500 (CDT) Received: from mail15-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE008.bigfish.com (10.3.84.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 17:00:54 +0000 Received: from mail15-db3 (localhost [127.0.0.1]) by mail15-db3-R.bigfish.com (Postfix) with ESMTP id 826274803FD for ; Wed, 31 Oct 2012 17:00:54 +0000 (UTC) Received: from mail15-db3 (localhost.localdomain [127.0.0.1]) by mail15-db3 (MessageSwitch) id 135170285262973_979; Wed, 31 Oct 2012 17:00:52 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.247]) by mail15-db3.bigfish.com (Postfix) with ESMTP id 032A22E0053 for ; Wed, 31 Oct 2012 17:00:52 +0000 (UTC) Received: from BY2PRD0411HT003.namprd04.prod.outlook.com (157.56.237.133) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 17:00:51 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.11.21]) by BY2PRD0411HT003.namprd04.prod.outlook.com ([10.255.128.38]) with mapi id 14.16.0233.002; Wed, 31 Oct 2012 17:00:50 +0000 From: Lewis Adam-CAL022 To: "oauth@ietf.org" Thread-Topic: access tokens & refresh tokens of different scopes Thread-Index: Ac23iUqZfwSnaVIuTgOMlO1uFR1N8w== Date: Wed, 31 Oct 2012 17:00:50 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {054A8959-3D78-41F4-8578-1A60C3597970} x-cr-hashedpuzzle: At/g CD4Q CHKh CS/+ CylH C4fo DOk4 Dwuz DzrE EGod EZxn E6NP FbgC H1T9 KR9p LT5v; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {054A8959-3D78-41F4-8578-1A60C3597970}; YQBkAGEAbQAuAGwAZQB3AGkAcwBAAG0AbwB0AG8AcgBvAGwAYQBzAG8AbAB1AHQAaQBvAG4AcwAuAGMAbwBtAA==; Wed, 31 Oct 2012 17:00:55 GMT; YQBjAGMAZQBzAHMAIAB0AG8AawBlAG4AcwAgACYAIAByAGUAZgByAGUAcwBoACAAdABvAGsAZQBuAHMAIABvAGYAIABkAGkAZgBmAGUAcgBlAG4AdAAgAHMAYwBvAHAAZQBzAA== x-originating-ip: [184.78.105.93] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A92F166F7FBY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Subject: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 17:01:47 -0000 --_000_59E470B10C4630419ED717AC79FCF9A92F166F7FBY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a use case where I would like to request both an access token and a = refresh token, but I would like the access token to have a scope less than = that of the refresh token. It is standard OAuth behavior for using the ref= resh token to request additional access tokens (of equal or lesser scope) b= ut the first access token that comes back always has the "master scope" of = the refresh token. For various security concerns, I always want my access tokens to be of a st= ricter scope that the refresh token. For example, consider the scenario of= a structured (JWT) access token that does not require the RS to call back = to the AS introspection endpoint. Following typical OAuth guidance, it is = best practice to use short lived access tokens with long lived refresh toke= ns. But I'd rather a compromised access token not compromise access to ALL= my resource servers. Using the existing standard I could simply destroy the first access token w= hen it is received and then request another of lesser scope using the refre= sh token, but now I've just wasted a round trip over the air, consuming ban= dwidth and adding latency to the end user experience. Is there anybody in the working group that feels this would be valuable? adam --_000_59E470B10C4630419ED717AC79FCF9A92F166F7FBY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have a use case w= here I would like to request both an access token and a refresh token, but = I would like the access token to have a scope less than that of the refresh= token.  It is standard OAuth behavior for using the refresh token to request additional access tokens (of equal = or lesser scope) but the first access token that comes back always has the = “master scope” of the refresh token. 

 

For various securit= y concerns, I always want my access tokens to be of a stricter scope that t= he refresh token.  For example, consider the scenario of a structured = (JWT) access token that does not require the RS to call back to the AS introspection endpoint.  Following typi= cal OAuth guidance, it is best practice to use short lived access tokens wi= th long lived refresh tokens.  But I’d rather a compromised acce= ss token not compromise access to ALL my resource servers.

 

Using the existing = standard I could simply destroy the first access token when it is received = and then request another of lesser scope using the refresh token, but now I= ’ve just wasted a round trip over the air, consuming bandwidth and adding latency to the end user experience.

 

Is there anybody in= the working group that feels this would be valuable?

 

 

adam

 

--_000_59E470B10C4630419ED717AC79FCF9A92F166F7FBY2PRD0411MB441_-- From Adam.Lewis@motorolasolutions.com Wed Oct 31 12:54:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C0121F8810 for ; Wed, 31 Oct 2012 12:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9lvySdX054e for ; Wed, 31 Oct 2012 12:54:49 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 32FCA21F87B6 for ; Wed, 31 Oct 2012 12:54:48 -0700 (PDT) Received: from mail146-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 19:54:47 +0000 Received: from mail146-ch1 (localhost [127.0.0.1]) by mail146-ch1-R.bigfish.com (Postfix) with ESMTP id 8217A600CA for ; Wed, 31 Oct 2012 19:54:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371Ic85fhzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received-SPF: pass (mail146-ch1: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT003.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail146-ch1 (localhost.localdomain [127.0.0.1]) by mail146-ch1 (MessageSwitch) id 1351713285737939_20757; Wed, 31 Oct 2012 19:54:45 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail146-ch1.bigfish.com (Postfix) with ESMTP id B24E12C0045 for ; Wed, 31 Oct 2012 19:54:45 +0000 (UTC) Received: from il06msg01.mot-solutions.com (129.188.136.17) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 19:54:43 +0000 Received: from il06msg01.mot-solutions.com (il06vts03.mot.com [129.188.137.143]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q9VKlSrB006011 for ; Wed, 31 Oct 2012 15:47:28 -0500 (CDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q9VKlQZ2006002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Oct 2012 15:47:27 -0500 (CDT) Received: from mail53-co1-R.bigfish.com (10.243.78.252) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 19:54:40 +0000 Received: from mail53-co1 (localhost [127.0.0.1]) by mail53-co1-R.bigfish.com (Postfix) with ESMTP id 3C71A68008C for ; Wed, 31 Oct 2012 19:54:40 +0000 (UTC) Received: from mail53-co1 (localhost.localdomain [127.0.0.1]) by mail53-co1 (MessageSwitch) id 1351713277891095_31681; Wed, 31 Oct 2012 19:54:37 +0000 (UTC) Received: from CO1EHSMHS026.bigfish.com (unknown [10.243.78.228]) by mail53-co1.bigfish.com (Postfix) with ESMTP id CDEF7100059; Wed, 31 Oct 2012 19:54:37 +0000 (UTC) Received: from BY2PRD0411HT003.namprd04.prod.outlook.com (157.56.237.133) by CO1EHSMHS026.bigfish.com (10.243.66.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 19:54:36 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.11.21]) by BY2PRD0411HT003.namprd04.prod.outlook.com ([10.255.128.38]) with mapi id 14.16.0233.002; Wed, 31 Oct 2012 19:54:34 +0000 From: Lewis Adam-CAL022 To: Dick Hardt Thread-Topic: [OAUTH-WG] access tokens & refresh tokens of different scopes Thread-Index: AQHNt511vMvKMVfMaEeBhwOb4WD1tJfT04sw Date: Wed, 31 Oct 2012 19:54:35 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> In-Reply-To: <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.78.105.93] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A92F166FF5BY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 19:54:51 -0000 --_000_59E470B10C4630419ED717AC79FCF9A92F166FF5BY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dick, I guess one thing that didn't quite come out in my first explanation is tha= t the scopes could belong to different resource servers. So I'd rather not= hand RS1 an access token that can be used to access protected resources on= RS2 or RS3. That is too much power for any RS to have :) Granted if I were using a holder of key profile of OAuth (something I am al= so very interested in) that could prevent such a thing from happening. But= even with that in place, it seems ugly to send a set of scopes to an RS th= at only supports a subset of those scopes (though I know it's done that way= today). I know a lot of my use cases are a bit atypical for the wg, but It still se= ems to me to be in line with the OAuth spirit to keep the access token as r= estricted as possible (both in terms of lifetime and in terms of scope). adam From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Wednesday, October 31, 2012 12:19 PM To: Lewis Adam-CAL022 Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes If the latency is important, you can deal with the latency by making the fi= rst call to the RS with the original access token while you are waiting for= the stricter scoped access token to come back. Once you have a stricter sc= ope access token, you can replace the original access token. In practice, I don't think the latency is going to be an issue, and myself,= I would be making a call to get a new access token just before I was going= to do some work since the access token is very short lived. -- Dick On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 > wrote: I have a use case where I would like to request both an access token and a = refresh token, but I would like the access token to have a scope less than = that of the refresh token. It is standard OAuth behavior for using the ref= resh token to request additional access tokens (of equal or lesser scope) b= ut the first access token that comes back always has the "master scope" of = the refresh token. For various security concerns, I always want my access tokens to be of a st= ricter scope that the refresh token. For example, consider the scenario of= a structured (JWT) access token that does not require the RS to call back = to the AS introspection endpoint. Following typical OAuth guidance, it is = best practice to use short lived access tokens with long lived refresh toke= ns. But I'd rather a compromised access token not compromise access to ALL= my resource servers. Using the existing standard I could simply destroy the first access token w= hen it is received and then request another of lesser scope using the refre= sh token, but now I've just wasted a round trip over the air, consuming ban= dwidth and adding latency to the end user experience. Is there anybody in the working group that feels this would be valuable? adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A92F166FF5BY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dick,

 

I guess one thing that didn’t quite co= me out in my first explanation is that the scopes could belong to different= resource servers.  So I’d rather not hand RS1 an access token that can be used to access protected resources on RS2 or RS3.  That i= s too much power for any RS to have :)

 

Granted if I were using a holder of key prof= ile of OAuth (something I am also very interested in) that could prevent su= ch a thing from happening.  But even with that in place, it seems ugly to send a set of scopes to an RS that only supports a subset= of those scopes (though I know it’s done that way today).

 

I know a lot of my use cases are a bit atypi= cal for the wg, but It still seems to me to be in line with the OAuth spiri= t to keep the access token as restricted as possible (both in terms of lifetime and in terms of scope).

 

adam

 

 

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Wednesday, October 31, 2012 12:19 PM
To: Lewis Adam-CAL022
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of differ= ent scopes

 

If the latency is important, you can deal with the l= atency by making the first call to the RS with the original access token wh= ile you are waiting for the stricter scoped access token to come back. Once= you have a stricter scope access token, you can replace the original access token. 

 

In practice, I don't think the latency is going to b= e an issue, and myself, I would be making a call to get a new access token = just before I was going to do some work since the access token is very shor= t lived.

 

-- Dick

 

On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 <= Adam.Lewis@motorolasolu= tions.com> wrote:



I have a use case where I would like to request both an = access token and a refresh token, but I would like the access token to have= a scope less than that of the refresh token.  It is standard OAuth behavior for using the refresh token to request additional access to= kens (of equal or lesser scope) but the first access token that comes back = always has the “master scope” of the refresh token. 

 

For various security concerns, I always want my access t= okens to be of a stricter scope that the refresh token.  For example, = consider the scenario of a structured (JWT) access token that does not require the RS to call back to the AS introspection endpoint.&nbs= p; Following typical OAuth guidance, it is best practice to use short lived= access tokens with long lived refresh tokens.  But I’d rather a= compromised access token not compromise access to ALL my resource servers.

 

Using the existing standard I could simply destroy the f= irst access token when it is received and then request another of lesser sc= ope using the refresh token, but now I’ve just wasted a round trip over the air, consuming bandwidth and adding latency to the end= user experience.

 

Is there anybody in the working group that feels this wo= uld be valuable?

 

 

adam

 

_____________________________________= __________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth=

 

--_000_59E470B10C4630419ED717AC79FCF9A92F166FF5BY2PRD0411MB441_-- From dick.hardt@gmail.com Wed Oct 31 13:11:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD4421F8721 for ; Wed, 31 Oct 2012 13:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oh2JU-FXwPG7 for ; Wed, 31 Oct 2012 13:11:18 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE30121F871E for ; Wed, 31 Oct 2012 13:11:18 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1229434pbb.31 for ; Wed, 31 Oct 2012 13:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=y/R9zw6gTh/fWnBeYQalTiJsUuvmz1jLZXO+qDBG3Ss=; b=NsuIS1HRI/NEg6UX1GTph/pHJwuY1IcM0RTzgHubhVRmJAkqln+Dyj83xsATMKb9T/ e1Sc6iZ9E6uBy31lbabLV/Zps82xqFh96wcCY/mk9gP0IZUEyWz2rSpq0Xyk8B49q1TC vZIXxeW7HSDDpewY590h05My32PJo6XFeRHP4P+sVciR82znNIfmkqgDNIff6V7f6ZlP fNIxVVz/ol/acH+qtGNL0BrVBqGrp74iJ3Iai8tTEl668HKIWuK0VAdJq6DC2tCz0A98 G3W5/T9Faeb2eyLaeTAKa+7nEtcyKFu8Ujz8KPn31EsSytiLZo7ooo6bDOKiY/P6uap1 H2DQ== Received: by 10.68.245.167 with SMTP id xp7mr53327823pbc.75.1351714278550; Wed, 31 Oct 2012 13:11:18 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id pv7sm2765086pbc.20.2012.10.31.13.10.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 13:11:09 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5C372362-2183-498E-85FB-B5B82D2C25FB" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> Date: Wed, 31 Oct 2012 13:10:56 -0700 Message-Id: <433A47F7-EED9-4BB7-B781-95430B204D75@gmail.com> References: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1499) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:11:19 -0000 --Apple-Mail=_5C372362-2183-498E-85FB-B5B82D2C25FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Adam Give your clarification, why not have 3 different calls to the AS so = that there are separate refresh tokens for each RS?=20 If you don't want to do that, then you will need to make the second = call. I'm not too keen on making the protocol more complicated for an = edge case. btw: the only AS I know that uses refresh tokens in the social web is = Google. All others have long lived access tokens IF the user granted = long lived access. -- Dick On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 = wrote: > Hi Dick, > =20 > I guess one thing that didn=92t quite come out in my first explanation = is that the scopes could belong to different resource servers. So I=92d = rather not hand RS1 an access token that can be used to access protected = resources on RS2 or RS3. That is too much power for any RS to have :) > =20 > Granted if I were using a holder of key profile of OAuth (something I = am also very interested in) that could prevent such a thing from = happening. But even with that in place, it seems ugly to send a set of = scopes to an RS that only supports a subset of those scopes (though I = know it=92s done that way today).=20 > =20 > I know a lot of my use cases are a bit atypical for the wg, but It = still seems to me to be in line with the OAuth spirit to keep the access = token as restricted as possible (both in terms of lifetime and in terms = of scope). > =20 > adam > =20 > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Wednesday, October 31, 2012 12:19 PM > To: Lewis Adam-CAL022 > Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different = scopes > =20 > If the latency is important, you can deal with the latency by making = the first call to the RS with the original access token while you are = waiting for the stricter scoped access token to come back. Once you have = a stricter scope access token, you can replace the original access = token.=20 > =20 > In practice, I don't think the latency is going to be an issue, and = myself, I would be making a call to get a new access token just before I = was going to do some work since the access token is very short lived. > =20 > -- Dick > =20 > On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 = wrote: >=20 >=20 > I have a use case where I would like to request both an access token = and a refresh token, but I would like the access token to have a scope = less than that of the refresh token. It is standard OAuth behavior for = using the refresh token to request additional access tokens (of equal or = lesser scope) but the first access token that comes back always has the = =93master scope=94 of the refresh token.=20 > =20 > For various security concerns, I always want my access tokens to be of = a stricter scope that the refresh token. For example, consider the = scenario of a structured (JWT) access token that does not require the RS = to call back to the AS introspection endpoint. Following typical OAuth = guidance, it is best practice to use short lived access tokens with long = lived refresh tokens. But I=92d rather a compromised access token not = compromise access to ALL my resource servers. > =20 > Using the existing standard I could simply destroy the first access = token when it is received and then request another of lesser scope using = the refresh token, but now I=92ve just wasted a round trip over the air, = consuming bandwidth and adding latency to the end user experience. > =20 > Is there anybody in the working group that feels this would be = valuable? > =20 > =20 > adam > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_5C372362-2183-498E-85FB-B5B82D2C25FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Adam

Give = your clarification, why not have 3 different calls to the AS so that = there are separate refresh tokens for each = RS? 

If you don't want to do that, then = you will need to make the second call. I'm not too keen on making the = protocol more complicated for an edge = case.

btw: the only AS I know that uses refresh = tokens in the social web is Google. All others have long lived access = tokens IF the user granted long lived = access.

-- Dick

On Oct = 31, 2012, at 12:54 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasoluti= ons.com> wrote:

Hi = Dick,
I guess one thing that didn=92t = quite come out in my first explanation is that the scopes could belong = to different resource servers.  So I=92d rather not hand RS1 an = access token that can be used to access protected resources on RS2 or = RS3.  That is too much power for any RS to have = :)
Granted if I were using a holder = of key profile of OAuth (something I am also very interested in) that = could prevent such a thing from happening.  But even with that in = place, it seems ugly to send a set of scopes to an RS that only supports = a subset of those scopes (though I know it=92s done that way = today). 
 
I = know a lot of my use cases are a bit atypical for the wg, but It still = seems to me to be in line with the OAuth spirit to keep the access token = as restricted as possible (both in terms of lifetime and in terms of = scope).
adam
 
From: Dick Hardt = [mailto:dick.hardt@gmail.com] 
Sent: Wednesday, October 31, 2012 = 12:19 PM
To: Lewis = Adam-CAL022
Subject: Re: [OAUTH-WG] access = tokens & refresh tokens of different = scopes
If the latency = is important, you can deal with the latency by making the first call to = the RS with the original access token while you are waiting for the = stricter scoped access token to come back. Once you have a stricter = scope access token, you can replace the original access = token. 
In = practice, I don't think the latency is going to be an issue, and myself, = I would be making a call to get a new access token just before I was = going to do some work since the access token is very short = lived.
-- = Dick
On = Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> = wrote:
I have a use case = where I would like to request both an access token and a refresh token, = but I would like the access token to have a scope less than that of the = refresh token.  It is standard OAuth behavior for using the refresh = token to request additional access tokens (of equal or lesser scope) but = the first access token that comes back always has the =93master scope=94 = of the refresh token.  For various = security concerns, I always want my access tokens to be of a stricter = scope that the refresh token.  For example, consider the scenario = of a structured (JWT) access token that does not require the RS to call = back to the AS introspection endpoint.  Following typical OAuth = guidance, it is best practice to use short lived access tokens with long = lived refresh tokens.  But I=92d rather a compromised access token = not compromise access to ALL my resource servers. Using the existing = standard I could simply destroy the first access token when it is = received and then request another of lesser scope using the refresh = token, but now I=92ve just wasted a round trip over the air, consuming = bandwidth and adding latency to the end user experience. Is there anybody in = the working group that feels this would be valuable?  adam  Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:30:04 -0000 --_000_59E470B10C4630419ED717AC79FCF9A92F167058BY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dick, Totally agree about keeping things simple :) I'll be the first to admit that many of my use cases are edge cases, but I = was sort of hoping that "this one" might find some common mindshare within = the community. Maybe it is just Google using refresh tokens today on the s= ocial web, but I think we all know that OAuth is going to have life well be= yond the social web. Whether that's good or bad has of course been the fou= ndation of so much of the recent "entertainment" in the OAuth blogsphere :) If I can't find anybody else in the community to agree that what I propose = is useful, then I'll cry uncle and let it rest. Btw, in response to your question "why not have 3 different calls to the AS= so that there are separate refresh tokens for each RS? " ... it all comes = down to end user experience / latency. -adam From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Wednesday, October 31, 2012 3:11 PM To: Lewis Adam-CAL022 Cc: Dick Hardt; oauth@ietf.org Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes Hi Adam Give your clarification, why not have 3 different calls to the AS so that t= here are separate refresh tokens for each RS? If you don't want to do that, then you will need to make the second call. I= 'm not too keen on making the protocol more complicated for an edge case. btw: the only AS I know that uses refresh tokens in the social web is Googl= e. All others have long lived access tokens IF the user granted long lived = access. -- Dick On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 > wrote: Hi Dick, I guess one thing that didn't quite come out in my first explanation is tha= t the scopes could belong to different resource servers. So I'd rather not= hand RS1 an access token that can be used to access protected resources on= RS2 or RS3. That is too much power for any RS to have :) Granted if I were using a holder of key profile of OAuth (something I am al= so very interested in) that could prevent such a thing from happening. But= even with that in place, it seems ugly to send a set of scopes to an RS th= at only supports a subset of those scopes (though I know it's done that way= today). I know a lot of my use cases are a bit atypical for the wg, but It still se= ems to me to be in line with the OAuth spirit to keep the access token as r= estricted as possible (both in terms of lifetime and in terms of scope). adam From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Wednesday, October 31, 2012 12:19 PM To: Lewis Adam-CAL022 Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes If the latency is important, you can deal with the latency by making the fi= rst call to the RS with the original access token while you are waiting for= the stricter scoped access token to come back. Once you have a stricter sc= ope access token, you can replace the original access token. In practice, I don't think the latency is going to be an issue, and myself,= I would be making a call to get a new access token just before I was going= to do some work since the access token is very short lived. -- Dick On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 > wrote: I have a use case where I would like to request both an access token and a = refresh token, but I would like the access token to have a scope less than = that of the refresh token. It is standard OAuth behavior for using the ref= resh token to request additional access tokens (of equal or lesser scope) b= ut the first access token that comes back always has the "master scope" of = the refresh token. For various security concerns, I always want my access tokens to be of a st= ricter scope that the refresh token. For example, consider the scenario of= a structured (JWT) access token that does not require the RS to call back = to the AS introspection endpoint. Following typical OAuth guidance, it is = best practice to use short lived access tokens with long lived refresh toke= ns. But I'd rather a compromised access token not compromise access to ALL= my resource servers. Using the existing standard I could simply destroy the first access token w= hen it is received and then request another of lesser scope using the refre= sh token, but now I've just wasted a round trip over the air, consuming ban= dwidth and adding latency to the end user experience. Is there anybody in the working group that feels this would be valuable? adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_59E470B10C4630419ED717AC79FCF9A92F167058BY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dick,

 

Totally agree about keeping things simple :)=

 

I’ll be the first to admit that many o= f my use cases are edge cases, but I was sort of hoping that “this on= e” might find some common mindshare within the community.  Maybe= it is just Google using refresh tokens today on the social web, but I think w= e all know that OAuth is going to have life well beyond the social web.&nbs= p; Whether that’s good or bad has of course been the foundation of so= much of the recent “entertainment” in the OAuth blogsphere :)

 

If I can’t find anybody else in the co= mmunity to agree that what I propose is useful, then I’ll cry uncle a= nd let it rest.

 

Btw, in response to your question “why not have 3 different calls to the AS so that there are separate ref= resh tokens for each RS? ” … it all comes down to end user experience / latency. 

 

 

-adam

 

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Wednesday, October 31, 2012 3:11 PM
To: Lewis Adam-CAL022
Cc: Dick Hardt; oauth@ietf.org
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of differ= ent scopes

 

Hi Adam

 

Give your clarification, why not have 3 different ca= lls to the AS so that there are separate refresh tokens for each RS? <= o:p>

 

If you don't want to do that, then you will need to = make the second call. I'm not too keen on making the protocol more complica= ted for an edge case.

 

btw: the only AS I know that uses refresh tokens in = the social web is Google. All others have long lived access tokens IF the u= ser granted long lived access.

 

-- Dick

 

On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 <= Adam.Lewis@motorolasolu= tions.com> wrote:



Hi Dick,

 

I guess one thing that didn’t quite co= me out in my first explanation is that the scopes could belong to different= resource servers.  So I’d rather not hand RS1 an access token that can be used to access protected resources on RS2 or RS3.  That i= s too much power for any RS to have :)

 

Granted if I were using a holder of key prof= ile of OAuth (something I am also very interested in) that could prevent su= ch a thing from happening.  But even with that in place, it seems ugly to send a set of scopes to an RS that only supports a subset= of those scopes (though I know it’s done that way today). 

 

I know a lot of my use cases are a bit atypi= cal for the wg, but It still seems to me to be in line with the OAuth spiri= t to keep the access token as restricted as possible (both in terms of lifetime and in terms of scope).

 

adam

 

 

From: Dick Hardt [mailto:dick.hardt@gmail.com] 
Sent: Wednesday, O= ctober 31, 2012 12:19 PM
To: Lewis Adam-CAL= 022
Subject: Re: [OAUT= H-WG] access tokens & refresh tokens of different scopes

 

If the latency is important, you can deal with the l= atency by making the first call to the RS with the original access token wh= ile you are waiting for the stricter scoped access token to come back. Once= you have a stricter scope access token, you can replace the original access token. 

 

In practice, I don't think the latency is going to b= e an issue, and myself, I would be making a call to get a new access token = just before I was going to do some work since the access token is very shor= t lived.

 

-- Dick

 

On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 <= Adam.Lewis@motorolasolutions.com> wrote:




I have a use case where I would like to request both an = access token and a refresh token, but I would like the access token to have= a scope less than that of the refresh token.  It is standard OAuth behavior for using the refresh token to request additional access to= kens (of equal or lesser scope) but the first access token that comes back = always has the “master scope” of the refresh token. 

 

For various security concerns, I always want my access t= okens to be of a stricter scope that the refresh token.  For example, = consider the scenario of a structured (JWT) access token that does not require the RS to call back to the AS introspection endpoint.&nbs= p; Following typical OAuth guidance, it is best practice to use short lived= access tokens with long lived refresh tokens.  But I’d rather a= compromised access token not compromise access to ALL my resource servers.

 

Using the existing standard I could simply destroy the f= irst access token when it is received and then request another of lesser sc= ope using the refresh token, but now I’ve just wasted a round trip over the air, consuming bandwidth and adding latency to the end= user experience.

 

Is there anybody in the working group that feels this wo= uld be valuable?

 

 

adam

 

_____________________________________= __________
OAuth mailing list
OAuth@ietf.o= rg
https://www.ietf.org/mailman/listinfo/oauth

 

--_000_59E470B10C4630419ED717AC79FCF9A92F167058BY2PRD0411MB441_-- From ppatterson@salesforce.com Wed Oct 31 13:38:04 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A28821F849A for ; Wed, 31 Oct 2012 13:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGKvWqeE0YhQ for ; Wed, 31 Oct 2012 13:38:03 -0700 (PDT) Received: from exprod8og112.obsmtp.com (exprod8og112.obsmtp.com [64.18.3.24]) by ietfa.amsl.com (Postfix) with SMTP id BECFA21F8499 for ; Wed, 31 Oct 2012 13:38:02 -0700 (PDT) Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob112.postini.com ([64.18.7.12]) with SMTP ID DSNKUJGMKsji0LNtHtLGIE3ZFZdZngJU36w3@postini.com; Wed, 31 Oct 2012 13:38:02 PDT Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.57]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Wed, 31 Oct 2012 13:38:02 -0700 From: Pat Patterson To: Lewis Adam-CAL022 Date: Wed, 31 Oct 2012 13:36:41 -0700 Thread-Topic: [OAUTH-WG] access tokens & refresh tokens of different scopes Thread-Index: Ac23p57qH8bwGnojRrCNSOiwEofcjA== Message-ID: <69F31F86-D6BD-4DEE-B4EA-8D109D1F92AA@salesforce.com> References: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> <433A47F7-EED9-4BB7-B781-95430B204D75@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_69F31F86D6BD4DEEB4EA8D109D1F92AAsalesforcecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 20:38:04 -0000 --_000_69F31F86D6BD4DEEB4EA8D109D1F92AAsalesforcecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Away from the social web, Salesforce issues refresh tokens - see http://wik= i.developerforce.com/page/Digging_Deeper_into_OAuth_2.0_on_Force.com Cheers, Pat -- Pat Patterson | Principal Developer Evangelist | 408-849-4681 | http://abou= t.me/patpatterson On Oct 31, 2012, at 1:29 PM, Lewis Adam-CAL022 wrote: Hi Dick, Totally agree about keeping things simple :) I=92ll be the first to admit that many of my use cases are edge cases, but = I was sort of hoping that =93this one=94 might find some common mindshare w= ithin the community. Maybe it is just Google using refresh tokens today on= the social web, but I think we all know that OAuth is going to have life w= ell beyond the social web. Whether that=92s good or bad has of course been= the foundation of so much of the recent =93entertainment=94 in the OAuth b= logsphere :) If I can=92t find anybody else in the community to agree that what I propos= e is useful, then I=92ll cry uncle and let it rest. Btw, in response to your question =93why not have 3 different calls to the = AS so that there are separate refresh tokens for each RS? =94 =85 it all co= mes down to end user experience / latency. -adam From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Wednesday, October 31, 2012 3:11 PM To: Lewis Adam-CAL022 Cc: Dick Hardt; oauth@ietf.org Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes Hi Adam Give your clarification, why not have 3 different calls to the AS so that t= here are separate refresh tokens for each RS? If you don't want to do that, then you will need to make the second call. I= 'm not too keen on making the protocol more complicated for an edge case. btw: the only AS I know that uses refresh tokens in the social web is Googl= e. All others have long lived access tokens IF the user granted long lived = access. -- Dick On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 > wrote: Hi Dick, I guess one thing that didn=92t quite come out in my first explanation is t= hat the scopes could belong to different resource servers. So I=92d rather= not hand RS1 an access token that can be used to access protected resource= s on RS2 or RS3. That is too much power for any RS to have :) Granted if I were using a holder of key profile of OAuth (something I am al= so very interested in) that could prevent such a thing from happening. But= even with that in place, it seems ugly to send a set of scopes to an RS th= at only supports a subset of those scopes (though I know it=92s done that w= ay today). I know a lot of my use cases are a bit atypical for the wg, but It still se= ems to me to be in line with the OAuth spirit to keep the access token as r= estricted as possible (both in terms of lifetime and in terms of scope). adam From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Wednesday, October 31, 2012 12:19 PM To: Lewis Adam-CAL022 Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes If the latency is important, you can deal with the latency by making the fi= rst call to the RS with the original access token while you are waiting for= the stricter scoped access token to come back. Once you have a stricter sc= ope access token, you can replace the original access token. In practice, I don't think the latency is going to be an issue, and myself,= I would be making a call to get a new access token just before I was going= to do some work since the access token is very short lived. -- Dick On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 > wrote: I have a use case where I would like to request both an access token and a = refresh token, but I would like the access token to have a scope less than = that of the refresh token. It is standard OAuth behavior for using the ref= resh token to request additional access tokens (of equal or lesser scope) b= ut the first access token that comes back always has the =93master scope=94= of the refresh token. For various security concerns, I always want my access tokens to be of a st= ricter scope that the refresh token. For example, consider the scenario of= a structured (JWT) access token that does not require the RS to call back = to the AS introspection endpoint. Following typical OAuth guidance, it is = best practice to use short lived access tokens with long lived refresh toke= ns. But I=92d rather a compromised access token not compromise access to A= LL my resource servers. Using the existing standard I could simply destroy the first access token w= hen it is received and then request another of lesser scope using the refre= sh token, but now I=92ve just wasted a round trip over the air, consuming b= andwidth and adding latency to the end user experience. Is there anybody in the working group that feels this would be valuable? adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_69F31F86D6BD4DEEB4EA8D109D1F92AAsalesforcecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable http://wiki.developerforce.com/page/Digging_Deeper_into_OAuth= _2.0_on_Force.com

Cheers,

Pat
-- 
Pat Patterson | Princi= pal Developer Evangelist | 408-849-4681 | http://about.me/patpatterson

On Oct 31, 2012, at 1:29 PM, Lewis Adam-CAL022 wrote:
<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"word-wrap: break= -word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><= div class=3D"WordSection1" style=3D"page: WordSection1; ">
Hi Dick,=
 
Totally agree about keeping things simple :)
I=92ll be the first to admit that many of my use cas= es are edge cases, but I was sort of hoping that =93this one=94 might find = some common mindshare within the community.  Maybe it is just Google u= sing refresh tokens today on the social web, but I think we all know that O= Auth is going to have life well beyond the social web.  Whether that= =92s good or bad has of course been the foundation of so much of the recent= =93entertainment=94 in the OAuth blogsphere :)
 
If I can=92t find anybody else in the community to agree that what = I propose is useful, then I=92ll cry uncle and let it rest.
<= o:p> 
Btw, in response to your question =93why not hav= e 3 different calls to the AS so that there are separate refresh tokens for= each RS? =94 =85 it all comes down to end user experience / latency. =
 
 
-adam
<= o:p> 
From: Dick Hardt [mailto:dick.hardt@gmail.com] 
Sent: Wednesday, October 31, 2012 3:11 PM
To:=  Lewis Adam-CAL022
= Cc: Dick Hardt; oauth@ietf.org<= br>Subject: Re: [O= AUTH-WG] access tokens & refresh tokens of different scopes<= /span>
 
Hi Adam
 
Give your clarification, why not hav= e 3 different calls to the AS so that there are separate refresh tokens for= each RS? 
 
If you don't want to do that, then you will need to make the second cal= l. I'm not too keen on making the protocol more complicated for an edge cas= e.
 
btw: the = only AS I know that uses refresh tokens in the social web is Google. All ot= hers have long lived access tokens IF the user granted long lived access.
 
-- Dick<= /o:p>
 
On Oct 31, 2012, a= t 12:54 PM, Lewis Adam-CAL022 <Adam.Lewis@m= otorolasolutions.com> wrote:


Hi Dick,
 
<= /div>
I guess one thing that didn=92t quite come out in my first explanation is = that the scopes could belong to different resource servers.  So I=92d = rather not hand RS1 an access token that can be used to access protected re= sources on RS2 or RS3.  That is too much power for any RS to have :)
 
Granted if I were u= sing a holder of key profile of OAuth (something I am also very interested = in) that could prevent such a thing from happening.  But even with tha= t in place, it seems ugly to send a set of scopes to an RS that only suppor= ts a subset of those scopes (though I know it=92s done that way today). 
&n= bsp;
I know a lot of my use cases are a bit atypic= al for the wg, but It still seems to me to be in line with the OAuth spirit= to keep the access token as restricted as possible (both in terms of lifet= ime and in terms of scope).
 
adam
 
&n= bsp;


<= br>
I have a use case where I would like to request both an a= ccess token and a refresh token, but I would like the access token to have = a scope less than that of the refresh token.  It is standard OAuth beh= avior for using the refresh token to request additional access tokens (of e= qual or lesser scope) but the first access token that comes back always has= the =93master scope=94 of the refresh token. 
=
&= nbsp;
For various security concerns, I always want my= access tokens to be of a stricter scope that the refresh token.  For = example, consider the scenario of a structured (JWT) access token that does= not require the RS to call back to the AS introspection endpoint.  Fo= llowing typical OAuth guidance, it is best practice to use short lived acce= ss tokens with long lived refresh tokens.  But I=92d rather a compromi= sed access token not compromise access to ALL my resource servers.
 
Using the existing standard I co= uld simply destroy the first access token when it is received and then requ= est another of lesser scope using the refresh token, but now I=92ve just wa= sted a round trip over the air, consuming bandwidth and adding latency to t= he end user experience.
 
= Is there anybody in the working group that feels this would be valuable?
 
 
 
= _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.iet= f.org/mailman/listinfo/oauth
=
 
_________= ______________________________________
OAuth mailing list
= OAuth@ietf.org
https://www.ietf.org= /mailman/listinfo/oauth

= --_000_69F31F86D6BD4DEEB4EA8D109D1F92AAsalesforcecom_-- From dick.hardt@gmail.com Wed Oct 31 14:07:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972A521F870B for ; Wed, 31 Oct 2012 14:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giFZyvShZrbz for ; Wed, 31 Oct 2012 14:07:45 -0700 (PDT) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 079E021F868C for ; Wed, 31 Oct 2012 14:07:44 -0700 (PDT) Received: by mail-da0-f44.google.com with SMTP id h15so824088dan.31 for ; Wed, 31 Oct 2012 14:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=WwCszGwPvCBu1Sr3BXdAhyvt8eS2SC2yt3+BFvdMbVE=; b=gVlOGLgnPAbSUBiMM86jyRWoSt/0Nhr63Xdkg48z9oPO+X36cnHgszGtM4kkbm0SSy kYMTwkCVDsuIsFfL3hLl+U07xP6acyPYxIhJV+BqQDI6tQNCDFeaTVr1GZ3KTPlw06uI wgnVRGR8x+6z+gkx6YGP1HMVT73Z+V6apSbx+8t4bxtWZfeuQVoi2RsloAXr3tX6tg5k FlD7Ayjf5BbcY4JyBy6UO9J/mr1xFzKrCsZgdinwA7Axj2D324IrVCrB3e8QMHzCR89F /c3W1ZNv5vnDiXzRtuLbqwWZbJiDHEYJcUeGw4lysCDonSX31Wxk0MDnPTw6Vd870EOn BHLA== Received: by 10.68.195.9 with SMTP id ia9mr117988951pbc.74.1351717664256; Wed, 31 Oct 2012 14:07:44 -0700 (PDT) Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id jx4sm2824237pbc.27.2012.10.31.14.07.20 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 14:07:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C33AE6B3-02BA-4ED7-8349-4D1C0930EED9" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> Date: Wed, 31 Oct 2012 14:07:19 -0700 Message-Id: References: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> <433A47F7-EED9-4BB7-B781-95430B204D75@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.1499) Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 21:07:45 -0000 --Apple-Mail=_C33AE6B3-02BA-4ED7-8349-4D1C0930EED9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 31, 2012, at 1:29 PM, Lewis Adam-CAL022 = wrote: > Hi Dick, > =20 > Totally agree about keeping things simple :) > =20 > I=92ll be the first to admit that many of my use cases are edge cases, = but I was sort of hoping that =93this one=94 might find some common = mindshare within the community. Maybe it is just Google using refresh = tokens today on the social web, but I think we all know that OAuth is = going to have life well beyond the social web. Whether that=92s good or = bad has of course been the foundation of so much of the recent = =93entertainment=94 in the OAuth blogsphere :) FYI: A design goal of WRAP, and hence OAuth 2.0 was to support a number = of enterprise use cases. I expect people will use it in ways not = imagined, which *may* require additions. I point out the non refresh token implementations to highlight that = numerous implementors have not felt the added security is worth the = extra client developer overhead in case you felt that it was a = requirement. > =20 > If I can=92t find anybody else in the community to agree that what I = propose is useful, then I=92ll cry uncle and let it rest. It will be interesting to see if others have the same use case. > Btw, in response to your question =93why not have 3 different calls to = the AS so that there are separate refresh tokens for each RS? =94 =85 it = all comes down to end user experience / latency.=20 Could you not make all three calls in parallel, and then you get the = access token that you want right away with no latency? --Apple-Mail=_C33AE6B3-02BA-4ED7-8349-4D1C0930EED9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Oct 31, 2012, = at 1:29 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasoluti= ons.com> wrote:

Hi = Dick,
Totally agree about keeping things = simple :)
I=92ll be the first to admit that = many of my use cases are edge cases, but I was sort of hoping that =93this= one=94 might find some common mindshare within the community.  = Maybe it is just Google using refresh tokens today on the social web, = but I think we all know that OAuth is going to have life well beyond the = social web.  Whether that=92s good or bad has of course been the = foundation of so much of the recent =93entertainment=94 in the OAuth = blogsphere = :)

FYI: A = design goal of WRAP, and hence OAuth 2.0 was to support a number of = enterprise use cases. I expect people will use it in ways not imagined, = which *may* require additions.

I point out the = non refresh token implementations to highlight that numerous = implementors have not felt the added security is worth the extra client = developer overhead in case you felt that it was a = requirement.

 
If I = can=92t find anybody else in the community to agree that what I propose = is useful, then I=92ll cry uncle and let it = rest.

It will = be interesting to see if others have the same use = case.

Btw, in response to your question =93why not have = 3 different calls to the AS so that there are separate refresh tokens = for each RS? =94 =85 it all comes down to end user experience / = latency. 

Could = you not make all three calls in parallel, and then you get the access = token that you want right away with no = latency?


= --Apple-Mail=_C33AE6B3-02BA-4ED7-8349-4D1C0930EED9-- From Adam.Lewis@motorolasolutions.com Wed Oct 31 14:41:26 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351B221F879E for ; Wed, 31 Oct 2012 14:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.466 X-Spam-Level: X-Spam-Status: No, score=-1.466 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqkU0+SkQPlJ for ; Wed, 31 Oct 2012 14:41:24 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 388C821F85A8 for ; Wed, 31 Oct 2012 14:41:23 -0700 (PDT) Received: from mail96-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 21:41:20 +0000 Received: from mail96-ch1 (localhost [127.0.0.1]) by mail96-ch1-R.bigfish.com (Postfix) with ESMTP id ECD30380255 for ; Wed, 31 Oct 2012 21:41:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:192.160.210.14; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg02.am.mot-solutions.com; RD:ct11msg02.mot-solutions.com; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic85fh1b0bIzz1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh1155h) Received-SPF: pass (mail96-ch1: domain of motorolasolutions.com designates 192.160.210.14 as permitted sender) client-ip=192.160.210.14; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg02.am.mot-solutions.com ; olutions.com ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT004.namprd04.prod.outlook.com; R:internal; EFV:INT Received: from mail96-ch1 (localhost.localdomain [127.0.0.1]) by mail96-ch1 (MessageSwitch) id 1351719678885494_423; Wed, 31 Oct 2012 21:41:18 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail96-ch1.bigfish.com (Postfix) with ESMTP id CBC6780116 for ; Wed, 31 Oct 2012 21:41:18 +0000 (UTC) Received: from ct11msg02.am.mot-solutions.com (192.160.210.14) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 21:41:18 +0000 Received: from ct11msg02.am.mot-solutions.com (ct11vts02.am.mot.com [10.177.16.160]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q9VLmWN1021943 for ; Wed, 31 Oct 2012 17:48:32 -0400 (EDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id q9VLmV02021939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Oct 2012 17:48:32 -0400 (EDT) Received: from mail104-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 31 Oct 2012 21:41:15 +0000 Received: from mail104-am1 (localhost [127.0.0.1]) by mail104-am1-R.bigfish.com (Postfix) with ESMTP id AE8C6340148 for ; Wed, 31 Oct 2012 21:41:15 +0000 (UTC) Received: from mail104-am1 (localhost.localdomain [127.0.0.1]) by mail104-am1 (MessageSwitch) id 1351719672382977_10672; Wed, 31 Oct 2012 21:41:12 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.245]) by mail104-am1.bigfish.com (Postfix) with ESMTP id 5B4C04E004B; Wed, 31 Oct 2012 21:41:12 +0000 (UTC) Received: from BY2PRD0411HT004.namprd04.prod.outlook.com (157.56.237.133) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 31 Oct 2012 21:41:12 +0000 Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.11.21]) by BY2PRD0411HT004.namprd04.prod.outlook.com ([10.255.128.39]) with mapi id 14.16.0233.002; Wed, 31 Oct 2012 21:41:02 +0000 From: Lewis Adam-CAL022 To: Dick Hardt Thread-Topic: [OAUTH-WG] access tokens & refresh tokens of different scopes Thread-Index: AQHNt6vR6QY+tO/6l0C3kf8asw9cT5fT71Mg Date: Wed, 31 Oct 2012 21:41:03 +0000 Message-ID: <59E470B10C4630419ED717AC79FCF9A92F1670F6@BY2PRD0411MB441.namprd04.prod.outlook.com> References: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> <433A47F7-EED9-4BB7-B781-95430B204D75@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.78.105.93] Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A92F1670F6BY2PRD0411MB441_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%GMAIL.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn% X-CFilter-Loop: Reflected X-OriginatorOrg: motorolasolutions.com Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 21:41:26 -0000 --_000_59E470B10C4630419ED717AC79FCF9A92F1670F6BY2PRD0411MB441_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dick, "Could you not make all three calls in parallel, and then you get the acces= s token that you want right away with no latency?" Yes but it's the response time for bootstrapping the first request that is = my concern. It takes a total of 4 round trips to obtain the first down-sco= ped access_token (three OAuth trips + one primary authentication to the AS)= . I'm really hoping more folks chime in with some interest on this one. The = security thought process behind the refresh token is sound, and I think mor= e people will begin to adopt it. We've got Salesforce as probably the larg= est enterprise using it, we've got people looking at OAuth for public safet= y / first responder use cases (myself), and we have FICAM profiling it as w= ell. I think this is just the beginning. Just my 2 cents, it's free :) adam From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Wednesday, October 31, 2012 4:07 PM To: Lewis Adam-CAL022 Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes On Oct 31, 2012, at 1:29 PM, Lewis Adam-CAL022 > wrote: Hi Dick, Totally agree about keeping things simple :) I'll be the first to admit that many of my use cases are edge cases, but I = was sort of hoping that "this one" might find some common mindshare within = the community. Maybe it is just Google using refresh tokens today on the s= ocial web, but I think we all know that OAuth is going to have life well be= yond the social web. Whether that's good or bad has of course been the fou= ndation of so much of the recent "entertainment" in the OAuth blogsphere :) FYI: A design goal of WRAP, and hence OAuth 2.0 was to support a number of = enterprise use cases. I expect people will use it in ways not imagined, whi= ch *may* require additions. I point out the non refresh token implementations to highlight that numerou= s implementors have not felt the added security is worth the extra client d= eveloper overhead in case you felt that it was a requirement. If I can't find anybody else in the community to agree that what I propose = is useful, then I'll cry uncle and let it rest. It will be interesting to see if others have the same use case. Btw, in response to your question "why not have 3 different calls to the AS= so that there are separate refresh tokens for each RS? " ... it all comes = down to end user experience / latency. Could you not make all three calls in parallel, and then you get the access= token that you want right away with no latency? --_000_59E470B10C4630419ED717AC79FCF9A92F1670F6BY2PRD0411MB441_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dick,

 

“Could you not make all three calls in paralle= l, and then you get the access token that you want right away with no laten= cy?”

 

Yes but it’s the response time for boo= tstrapping the first request that is my concern.  It takes a total of = 4 round trips to obtain the first down-scoped access_token (three OAuth trips + one primary authentication to the AS).

 

I’m really hoping more folks chime in = with some interest on this one.  The security thought process behind t= he refresh token is sound, and I think more people will begin to adopt it.  We’ve got Salesforce as probably the largest enterprise us= ing it, we’ve got people looking at OAuth for public safety / first r= esponder use cases (myself), and we have FICAM profiling it as well.  = I think this is just the beginning. 

 

Just my 2 cents, it’s free :)

adam

 

 

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Wednesday, October 31, 2012 4:07 PM
To: Lewis Adam-CAL022
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of differ= ent scopes

 

 

On Oct 31, 2012, at 1:29 PM, Lewis Adam-CAL022 <<= a href=3D"mailto:Adam.Lewis@motorolasolutions.com">Adam.Lewis@motorolasolut= ions.com> wrote:



Hi Dick,

 

Totally agree about keeping things simple :)=

 

I’ll be the first to admit that many o= f my use cases are edge cases, but I was sort of hoping that “this on= e” might find some common mindshare within the community.  Maybe= it is just Google using refresh tokens today on the social web, but I think w= e all know that OAuth is going to have life well beyond the social web.&nbs= p; Whether that’s good or bad has of course been the foundation of so= much of the recent “entertainment” in the OAuth blogsphere :)

 

FYI: A design goal of WRAP, and hence OAuth 2.0= was to support a number of enterprise use cases. I expect people will use = it in ways not imagined, which *may* require additions.

 

I point out the non refresh token implementations to= highlight that numerous implementors have not felt the added security is w= orth the extra client developer overhead in case you felt that it was a req= uirement.



 

If I can’t find anybody else in the co= mmunity to agree that what I propose is useful, then I’ll cry uncle a= nd let it rest.

 

It will be interesting to see if others have the sam= e use case.



Btw, in response to your question “why not have 3 different calls to the AS so that there are separate ref= resh tokens for each RS? ” … it all comes down to end user experience / latency. 

 

Could you not make all three calls in parallel, and = then you get the access token that you want right away with no latency?

 

 

--_000_59E470B10C4630419ED717AC79FCF9A92F1670F6BY2PRD0411MB441_-- From James.H.Manger@team.telstra.com Wed Oct 31 18:00:56 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668BD21F88B8 for ; Wed, 31 Oct 2012 18:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.029 X-Spam-Level: X-Spam-Status: No, score=0.029 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ov1+z5ZHDJT for ; Wed, 31 Oct 2012 18:00:55 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id F1F3E21F88B4 for ; Wed, 31 Oct 2012 18:00:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,690,1344175200"; d="scan'208,217";a="102244299" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 01 Nov 2012 12:00:54 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6882"; a="95551519" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdvi.tcif.telstra.com.au with ESMTP; 01 Nov 2012 12:00:51 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Thu, 1 Nov 2012 12:00:53 +1100 From: "Manger, James H" To: Lewis Adam-CAL022 Date: Thu, 1 Nov 2012 12:00:51 +1100 Thread-Topic: [OAUTH-WG] access tokens & refresh tokens of different scopes Thread-Index: AQHNt6vR6QY+tO/6l0C3kf8asw9cT5fT71MggAAruyA= Message-ID: <255B9BB34FB7D647A506DC292726F6E114FFCE6960@WSMSG3153V.srv.dir.telstra.com> References: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> <433A47F7-EED9-4BB7-B781-95430B204D75@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> <59E470B10C4630419ED717AC79FCF9A92F1670F6@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F1670F6@BY2PRD0411MB441.namprd04.prod.outlook.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FFCE6960WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 01:00:56 -0000 --_000_255B9BB34FB7D647A506DC292726F6E114FFCE6960WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRhbSwNCg0KSeKAmWxsIGNoaW1lIGluIGFuZCBzYXkgeW91IGhhdmUgYSByZWFzb25hYmxlIHJl cXVpcmVtZW50IChnZXR0aW5nIHRva2VucyB3aXRoIGRpZmZlcmVudCBzY29wZXMgKGZvciBkaWZm ZXJlbnQgcmVzb3VyY2Ugc2VydmVycykgZWZmaWNpZW50bHkpLiBPdmVyIHRoZSBsYXN0IGZldyB5 ZWFycyB0aGVyZSBoYXZlIGJlZW4gYSBudW1iZXIgb2YgcHJvcG9zYWxzIGZvciBPQXV0aCB0byBz dXBwb3J0IHRoaXMgKGJ5IGFsbG93aW5nIGFuIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIHJldHVy biBtdWx0aXBsZSB0b2tlbnMsIGVhY2ggd2l0aCB0aGVpciBvd24gc2NvcGUpLiBVbmZvcnR1bmF0 ZWx5LCBkZXNwaXRlIHNvbWUgc3VwcG9ydCwgdGhlIHByb3Bvc2FscyB3ZXJlIHJlamVjdGVkIGZv ciB0aGUgY29yZSBzcGVjLiBUaGVyZSB3YXMgc3Ryb25nIHJlc2lzdGFuY2UgdG8gYW55IGNvbXBs ZXhpdHkgdGhhdCB3YXNu4oCZdCBhYnNvbHV0ZWx5IG5lY2Vzc2FyeSBmb3IgdGhlIGJhc2ljIHVz ZSBjYXNlIOKAlCBhbmQgZmxleGliaWxpdHkgZm9yIGxpa2VseSAodGhvdWdoIG1heWJlIG5pY2hl KSBzY2VuYXJpb3Mgc3VjaCBhcyB5b3VycyB3YXMgbm90IHN1ZmZpY2llbnQgbW90aXZhdGlvbi4N Cg0KQXMgaXQgdHVybnMgb3V0LCBvbmUgc2lnbmlmaWNhbnQgZWFybHkgdXNlIG9mIE9BdXRoMiBk b2VzIG5lZWQgYW4gZXh0cmEgdG9rZW4gKHRoZSBJRCB0b2tlbiBpbiBPcGVuSUQgQ29ubmVjdCku IFRoYXQgaXMgYmVpbmcgc3VwcG9ydGVkIHdpdGggc29tZSBhZGRpdGlvbnMgdG8gT0F1dGgyIHRo YXQgYXJlIGhpZ2hseSBzcGVjaWZpYyB0byBPcGVuSUQgQ29ubmVjdCBzbyBpdCBkb2VzIG5vdCBo ZWxwIHlvdXIgcmVxdWlyZW1lbnQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTogb2F1dGgt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBMZXdpcyBBZGFtLUNBTDAyMg0KU2VudDogVGh1cnNkYXksIDEgTm92ZW1iZXIgMjAxMiA0 OjAxIEFNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gYWNjZXNzIHRv a2VucyAmIHJlZnJlc2ggdG9rZW5zIG9mIGRpZmZlcmVudCBzY29wZXMNCg0KSSBoYXZlIGEgdXNl IGNhc2Ugd2hlcmUgSSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgYm90aCBhbiBhY2Nlc3MgdG9rZW4g YW5kIGEgcmVmcmVzaCB0b2tlbiwgYnV0IEkgd291bGQgbGlrZSB0aGUgYWNjZXNzIHRva2VuIHRv IGhhdmUgYSBzY29wZSBsZXNzIHRoYW4gdGhhdCBvZiB0aGUgcmVmcmVzaCB0b2tlbi4gIEl0IGlz IHN0YW5kYXJkIE9BdXRoIGJlaGF2aW9yIGZvciB1c2luZyB0aGUgcmVmcmVzaCB0b2tlbiB0byBy ZXF1ZXN0IGFkZGl0aW9uYWwgYWNjZXNzIHRva2VucyAob2YgZXF1YWwgb3IgbGVzc2VyIHNjb3Bl KSBidXQgdGhlIGZpcnN0IGFjY2VzcyB0b2tlbiB0aGF0IGNvbWVzIGJhY2sgYWx3YXlzIGhhcyB0 aGUg4oCcbWFzdGVyIHNjb3Bl4oCdIG9mIHRoZSByZWZyZXNoIHRva2VuLg0KDQpGb3IgdmFyaW91 cyBzZWN1cml0eSBjb25jZXJucywgSSBhbHdheXMgd2FudCBteSBhY2Nlc3MgdG9rZW5zIHRvIGJl IG9mIGEgc3RyaWN0ZXIgc2NvcGUgdGhhdCB0aGUgcmVmcmVzaCB0b2tlbi4gIEZvciBleGFtcGxl LCBjb25zaWRlciB0aGUgc2NlbmFyaW8gb2YgYSBzdHJ1Y3R1cmVkIChKV1QpIGFjY2VzcyB0b2tl biB0aGF0IGRvZXMgbm90IHJlcXVpcmUgdGhlIFJTIHRvIGNhbGwgYmFjayB0byB0aGUgQVMgaW50 cm9zcGVjdGlvbiBlbmRwb2ludC4gIEZvbGxvd2luZyB0eXBpY2FsIE9BdXRoIGd1aWRhbmNlLCBp dCBpcyBiZXN0IHByYWN0aWNlIHRvIHVzZSBzaG9ydCBsaXZlZCBhY2Nlc3MgdG9rZW5zIHdpdGgg bG9uZyBsaXZlZCByZWZyZXNoIHRva2Vucy4gIEJ1dCBJ4oCZZCByYXRoZXIgYSBjb21wcm9taXNl ZCBhY2Nlc3MgdG9rZW4gbm90IGNvbXByb21pc2UgYWNjZXNzIHRvIEFMTCBteSByZXNvdXJjZSBz ZXJ2ZXJzLg0KDQpVc2luZyB0aGUgZXhpc3Rpbmcgc3RhbmRhcmQgSSBjb3VsZCBzaW1wbHkgZGVz dHJveSB0aGUgZmlyc3QgYWNjZXNzIHRva2VuIHdoZW4gaXQgaXMgcmVjZWl2ZWQgYW5kIHRoZW4g cmVxdWVzdCBhbm90aGVyIG9mIGxlc3NlciBzY29wZSB1c2luZyB0aGUgcmVmcmVzaCB0b2tlbiwg YnV0IG5vdyBJ4oCZdmUganVzdCB3YXN0ZWQgYSByb3VuZCB0cmlwIG92ZXIgdGhlIGFpciwgY29u c3VtaW5nIGJhbmR3aWR0aCBhbmQgYWRkaW5nIGxhdGVuY3kgdG8gdGhlIGVuZCB1c2VyIGV4cGVy aWVuY2UuDQoNCklzIHRoZXJlIGFueWJvZHkgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgdGhhdCBmZWVs cyB0aGlzIHdvdWxkIGJlIHZhbHVhYmxlPw0KDQoNCmFkYW0NCg== --_000_255B9BB34FB7D647A506DC292726F6E114FFCE6960WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1tc2c6 Ly8yNjg0LyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjgu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOm9saXZlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250 LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCnNwYW4uQmFsbG9v blRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFkYW0sPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5J4oCZbGwgY2hpbWUgaW4gYW5kIHNheSB5b3UgaGF2ZSBhIHJlYXNv bmFibGUgcmVxdWlyZW1lbnQgKGdldHRpbmcgdG9rZW5zIHdpdGggZGlmZmVyZW50IHNjb3BlcyAo Zm9yIGRpZmZlcmVudCByZXNvdXJjZSBzZXJ2ZXJzKSBlZmZpY2llbnRseSkuIE92ZXIgdGhlIGxh c3QgZmV3IHllYXJzIHRoZXJlIGhhdmUgYmVlbiBhIG51bWJlciBvZiBwcm9wb3NhbHMgZm9yIE9B dXRoIHRvIHN1cHBvcnQgdGhpcyAoYnkgYWxsb3dpbmcgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIg dG8gcmV0dXJuIG11bHRpcGxlIHRva2VucywgZWFjaCB3aXRoIHRoZWlyIG93biBzY29wZSkuIFVu Zm9ydHVuYXRlbHksIGRlc3BpdGUgc29tZSBzdXBwb3J0LCB0aGUgcHJvcG9zYWxzIHdlcmUgcmVq ZWN0ZWQgZm9yIHRoZSBjb3JlIHNwZWMuIFRoZXJlIHdhcyBzdHJvbmcgcmVzaXN0YW5jZSB0byBh bnkgY29tcGxleGl0eSB0aGF0IHdhc27igJl0IGFic29sdXRlbHkgbmVjZXNzYXJ5IGZvciB0aGUg YmFzaWMgdXNlIGNhc2Ug4oCUIGFuZCBmbGV4aWJpbGl0eSBmb3IgbGlrZWx5ICh0aG91Z2ggbWF5 YmUgbmljaGUpIHNjZW5hcmlvcyBzdWNoIGFzIHlvdXJzIHdhcyBub3Qgc3VmZmljaWVudCBtb3Rp dmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QXMgaXQgdHVybnMgb3V0LCBvbmUgc2lnbmlmaWNh bnQgZWFybHkgdXNlIG9mIE9BdXRoMiBkb2VzIG5lZWQgYW4gZXh0cmEgdG9rZW4gKHRoZSBJRCB0 b2tlbiBpbiBPcGVuSUQgQ29ubmVjdCkuIFRoYXQgaXMgYmVpbmcgc3VwcG9ydGVkIHdpdGggc29t ZSBhZGRpdGlvbnMgdG8gT0F1dGgyIHRoYXQgYXJlIGhpZ2hseSBzcGVjaWZpYyB0byBPcGVuSUQg Q29ubmVjdCBzbyBpdCBkb2VzIG5vdCBoZWxwIHlvdXIgcmVxdWlyZW1lbnQuPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5MZXdpcyBB ZGFtLUNBTDAyMjxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIDEgTm92ZW1iZXIgMjAxMiA0OjAx IEFNPGJyPjxiPlRvOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFtPQVVU SC1XR10gYWNjZXNzIHRva2VucyAmYW1wOyByZWZyZXNoIHRva2VucyBvZiBkaWZmZXJlbnQgc2Nv cGVzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5JIGhhdmUgYSB1c2Ug Y2FzZSB3aGVyZSBJIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBib3RoIGFuIGFjY2VzcyB0b2tlbiBh bmQgYSByZWZyZXNoIHRva2VuLCBidXQgSSB3b3VsZCBsaWtlIHRoZSBhY2Nlc3MgdG9rZW4gdG8g aGF2ZSBhIHNjb3BlIGxlc3MgdGhhbiB0aGF0IG9mIHRoZSByZWZyZXNoIHRva2VuLiZuYnNwOyBJ dCBpcyBzdGFuZGFyZCBPQXV0aCBiZWhhdmlvciBmb3IgdXNpbmcgdGhlIHJlZnJlc2ggdG9rZW4g dG8gcmVxdWVzdCBhZGRpdGlvbmFsIGFjY2VzcyB0b2tlbnMgKG9mIGVxdWFsIG9yIGxlc3NlciBz Y29wZSkgYnV0IHRoZSBmaXJzdCBhY2Nlc3MgdG9rZW4gdGhhdCBjb21lcyBiYWNrIGFsd2F5cyBo YXMgdGhlIOKAnG1hc3RlciBzY29wZeKAnSBvZiB0aGUgcmVmcmVzaCB0b2tlbi4mbmJzcDsgPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUz5Gb3IgdmFyaW91cyBzZWN1cml0eSBjb25jZXJucywgSSBhbHdheXMgd2FudCBteSBhY2Nl c3MgdG9rZW5zIHRvIGJlIG9mIGEgc3RyaWN0ZXIgc2NvcGUgdGhhdCB0aGUgcmVmcmVzaCB0b2tl bi4mbmJzcDsgRm9yIGV4YW1wbGUsIGNvbnNpZGVyIHRoZSBzY2VuYXJpbyBvZiBhIHN0cnVjdHVy ZWQgKEpXVCkgYWNjZXNzIHRva2VuIHRoYXQgZG9lcyBub3QgcmVxdWlyZSB0aGUgUlMgdG8gY2Fs bCBiYWNrIHRvIHRoZSBBUyBpbnRyb3NwZWN0aW9uIGVuZHBvaW50LiZuYnNwOyBGb2xsb3dpbmcg dHlwaWNhbCBPQXV0aCBndWlkYW5jZSwgaXQgaXMgYmVzdCBwcmFjdGljZSB0byB1c2Ugc2hvcnQg bGl2ZWQgYWNjZXNzIHRva2VucyB3aXRoIGxvbmcgbGl2ZWQgcmVmcmVzaCB0b2tlbnMuJm5ic3A7 IEJ1dCBJ4oCZZCByYXRoZXIgYSBjb21wcm9taXNlZCBhY2Nlc3MgdG9rZW4gbm90IGNvbXByb21p c2UgYWNjZXNzIHRvIEFMTCBteSByZXNvdXJjZSBzZXJ2ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+VXNpbmcgdGhlIGV4 aXN0aW5nIHN0YW5kYXJkIEkgY291bGQgc2ltcGx5IGRlc3Ryb3kgdGhlIGZpcnN0IGFjY2VzcyB0 b2tlbiB3aGVuIGl0IGlzIHJlY2VpdmVkIGFuZCB0aGVuIHJlcXVlc3QgYW5vdGhlciBvZiBsZXNz ZXIgc2NvcGUgdXNpbmcgdGhlIHJlZnJlc2ggdG9rZW4sIGJ1dCBub3cgSeKAmXZlIGp1c3Qgd2Fz dGVkIGEgcm91bmQgdHJpcCBvdmVyIHRoZSBhaXIsIGNvbnN1bWluZyBiYW5kd2lkdGggYW5kIGFk ZGluZyBsYXRlbmN5IHRvIHRoZSBlbmQgdXNlciBleHBlcmllbmNlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+SXMgdGhlcmUg YW55Ym9keSBpbiB0aGUgd29ya2luZyBncm91cCB0aGF0IGZlZWxzIHRoaXMgd291bGQgYmUgdmFs dWFibGU/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVM+YWRhbTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E114FFCE6960WSMSG3153Vsrv_-- From torsten@lodderstedt.net Wed Oct 31 23:47:29 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846D121F8524 for ; Wed, 31 Oct 2012 23:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rGltZKBICm9 for ; Wed, 31 Oct 2012 23:47:26 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1880021F8511 for ; Wed, 31 Oct 2012 23:47:25 -0700 (PDT) Received: from [79.253.45.155] (helo=[192.168.71.42]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TToYk-00014C-RO; Thu, 01 Nov 2012 07:47:23 +0100 Message-ID: <50921AF7.5090302@lodderstedt.net> Date: Thu, 01 Nov 2012 07:47:19 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Lewis Adam-CAL022 References: <59E470B10C4630419ED717AC79FCF9A92F166F7F@BY2PRD0411MB441.namprd04.prod.outlook.com> <5BFC7B8F-8E2E-40B5-A0BD-769DCFC3DA2A@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F166FF5@BY2PRD0411MB441.namprd04.prod.outlook.com> <433A47F7-EED9-4BB7-B781-95430B204D75@gmail.com> <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F167058@BY2PRD0411MB441.namprd04.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------050700000907070405080508" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 06:47:29 -0000 This is a multi-part message in MIME format. --------------050700000907070405080508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adam, our OAuth implementations at Deutsche Telekom issue refresh tokens and we use different access tokens for different RS (for privacy and security reasons). Today, there is a one-to-one relation between access and refresh token, which means a client needs to acquire and retain several refresh tokens. In our experience, this increases complexitity for the developer and causes them to use other patterns. They use a master access token and exchange this for other access tokens using a custom assertion grant type. In my opinion, it would be much simpler to use a refresh token instead. So we consider to use one refresh token per client, which can be associated with several services and thus can be used to obtain access tokens with different scope. I support your requirement and would like to discuss it in the WG. regards, Torsten. Am 31.10.2012 21:29, schrieb Lewis Adam-CAL022: > > Hi Dick, > > Totally agree about keeping things simple :) > > I'll be the first to admit that many of my use cases are edge cases, > but I was sort of hoping that "this one" might find some common > mindshare within the community. Maybe it is just Google using refresh > tokens today on the social web, but I think we all know that OAuth is > going to have life well beyond the social web. Whether that's good or > bad has of course been the foundation of so much of the recent > "entertainment" in the OAuth blogsphere :) > > If I can't find anybody else in the community to agree that what I > propose is useful, then I'll cry uncle and let it rest. > > Btw, in response to your question "why not have 3 different calls to > the AS so that there are separate refresh tokens for each RS? " ... it > all comes down to end user experience / latency. > > -adam > > *From:*Dick Hardt [mailto:dick.hardt@gmail.com] > *Sent:* Wednesday, October 31, 2012 3:11 PM > *To:* Lewis Adam-CAL022 > *Cc:* Dick Hardt; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] access tokens & refresh tokens of different > scopes > > Hi Adam > > Give your clarification, why not have 3 different calls to the AS so > that there are separate refresh tokens for each RS? > > If you don't want to do that, then you will need to make the second > call. I'm not too keen on making the protocol more complicated for an > edge case. > > btw: the only AS I know that uses refresh tokens in the social web is > Google. All others have long lived access tokens IF the user granted > long lived access. > > -- Dick > > On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 > > wrote: > > > > Hi Dick, > > I guess one thing that didn't quite come out in my first explanation > is that the scopes could belong to different resource servers. So I'd > rather not hand RS1 an access token that can be used to access > protected resources on RS2 or RS3. That is too much power for any RS > to have :) > > Granted if I were using a holder of key profile of OAuth (something I > am also very interested in) that could prevent such a thing from > happening. But even with that in place, it seems ugly to send a set > of scopes to an RS that only supports a subset of those scopes (though > I know it's done that way today). > > I know a lot of my use cases are a bit atypical for the wg, but It > still seems to me to be in line with the OAuth spirit to keep the > access token as restricted as possible (both in terms of lifetime and > in terms of scope). > > adam > > *From:*Dick Hardt [mailto:dick.hardt@gmail.com ] > *Sent:*Wednesday, October 31, 2012 12:19 PM > *To:*Lewis Adam-CAL022 > *Subject:*Re: [OAUTH-WG] access tokens & refresh tokens of different > scopes > > If the latency is important, you can deal with the latency by making > the first call to the RS with the original access token while you are > waiting for the stricter scoped access token to come back. Once you > have a stricter scope access token, you can replace the original > access token. > > In practice, I don't think the latency is going to be an issue, and > myself, I would be making a call to get a new access token just before > I was going to do some work since the access token is very short lived. > > -- Dick > > On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 > > wrote: > > > > > I have a use case where I would like to request both an access token > and a refresh token, but I would like the access token to have a scope > less than that of the refresh token. It is standard OAuth behavior > for using the refresh token to request additional access tokens (of > equal or lesser scope) but the first access token that comes back > always has the "master scope" of the refresh token. > > For various security concerns, I always want my access tokens to be of > a stricter scope that the refresh token. For example, consider the > scenario of a structured (JWT) access token that does not require the > RS to call back to the AS introspection endpoint. Following typical > OAuth guidance, it is best practice to use short lived access tokens > with long lived refresh tokens. But I'd rather a compromised access > token not compromise access to ALL my resource servers. > > Using the existing standard I could simply destroy the first access > token when it is received and then request another of lesser scope > using the refresh token, but now I've just wasted a round trip over > the air, consuming bandwidth and adding latency to the end user > experience. > > Is there anybody in the working group that feels this would be valuable? > > adam > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050700000907070405080508 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Adam,

our OAuth implementations at Deutsche Telekom issue refresh tokens and we use different access tokens for different RS (for privacy and security reasons). Today, there is a one-to-one relation between access and refresh token, which means a client needs to acquire and retain several refresh tokens. In our experience, this increases complexitity for the developer and causes them to use other patterns. They use a master access token and exchange this for other access tokens using a custom assertion grant type. In my opinion, it would be much simpler to use a refresh token instead. So we consider to use one refresh token per client, which can be associated with several services and thus can be used to obtain access tokens with different scope.

I support your requirement and would like to discuss it in the WG.

regards,
Torsten.

Am 31.10.2012 21:29, schrieb Lewis Adam-CAL022:

Hi Dick,

 

Totally agree about keeping things simple :)

 

I’ll be the first to admit that many of my use cases are edge cases, but I was sort of hoping that “this one” might find some common mindshare within the community.  Maybe it is just Google using refresh tokens today on the social web, but I think we all know that OAuth is going to have life well beyond the social web.  Whether that’s good or bad has of course been the foundation of so much of the recent “entertainment” in the OAuth blogsphere :)

 

If I can’t find anybody else in the community to agree that what I propose is useful, then I’ll cry uncle and let it rest.

 

Btw, in response to your question “why not have 3 different calls to the AS so that there are separate refresh tokens for each RS? ” … it all comes down to end user experience / latency. 

 

 

-adam

 

From: Dick Hardt [mailto:dick.hardt@gmail.com]
Sent: Wednesday, October 31, 2012 3:11 PM
To: Lewis Adam-CAL022
Cc: Dick Hardt; oauth@ietf.org
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes

 

Hi Adam

 

Give your clarification, why not have 3 different calls to the AS so that there are separate refresh tokens for each RS? 

 

If you don't want to do that, then you will need to make the second call. I'm not too keen on making the protocol more complicated for an edge case.

 

btw: the only AS I know that uses refresh tokens in the social web is Google. All others have long lived access tokens IF the user granted long lived access.

 

-- Dick

 

On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:



Hi Dick,

 

I guess one thing that didn’t quite come out in my first explanation is that the scopes could belong to different resource servers.  So I’d rather not hand RS1 an access token that can be used to access protected resources on RS2 or RS3.  That is too much power for any RS to have :)

 

Granted if I were using a holder of key profile of OAuth (something I am also very interested in) that could prevent such a thing from happening.  But even with that in place, it seems ugly to send a set of scopes to an RS that only supports a subset of those scopes (though I know it’s done that way today). 

 

I know a lot of my use cases are a bit atypical for the wg, but It still seems to me to be in line with the OAuth spirit to keep the access token as restricted as possible (both in terms of lifetime and in terms of scope).

 

adam

 

 

From: Dick Hardt [mailto:dick.hardt@gmail.com] 
Sent: Wednesday, October 31, 2012 12:19 PM
To: Lewis Adam-CAL022
Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes

 

If the latency is important, you can deal with the latency by making the first call to the RS with the original access token while you are waiting for the stricter scoped access token to come back. Once you have a stricter scope access token, you can replace the original access token. 

 

In practice, I don't think the latency is going to be an issue, and myself, I would be making a call to get a new access token just before I was going to do some work since the access token is very short lived.

 

-- Dick

 

On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolasolutions.com> wrote:




I have a use case where I would like to request both an access token and a refresh token, but I would like the access token to have a scope less than that of the refresh token.  It is standard OAuth behavior for using the refresh token to request additional access tokens (of equal or lesser scope) but the first access token that comes back always has the “master scope” of the refresh token. 

 

For various security concerns, I always want my access tokens to be of a stricter scope that the refresh token.  For example, consider the scenario of a structured (JWT) access token that does not require the RS to call back to the AS introspection endpoint.  Following typical OAuth guidance, it is best practice to use short lived access tokens with long lived refresh tokens.  But I’d rather a compromised access token not compromise access to ALL my resource servers.

 

Using the existing standard I could simply destroy the first access token when it is received and then request another of lesser scope using the refresh token, but now I’ve just wasted a round trip over the air, consuming bandwidth and adding latency to the end user experience.

 

Is there anybody in the working group that feels this would be valuable?

 

 

adam

 

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

 



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

--------------050700000907070405080508--
Eve

On = 10 Oct 2012, at 5:40 PM, zhou.sujing@zte.com.cn = wrote:


Hi, Eve,
   The requester you = described corresponds to Client in OAuth, so it is still client initiated = delegation, not what Prabath wants.



Eve Maler = <eve@xmlgrrl.com>

2012-10-11 06:54

=CA=D5=BC=FE=C8=CB
Prabath Siriwardena <prabath@wso2.com>
=B3=AD=CB=CD
zhou.sujing@zte.com.cn, "oauth@ietf.org WG" <oauth@ietf.org>
=D6=F7=CC=E2
Re: [OAUTH-WG] Resource = owner initiated OAuth delegation





Sure. We'll ultimately be = publishing some case studies that will hopefully make this clearer, but the key = place to start in the spec is here:

http://docs.kantarainitiative.org/uma/draft-uma-cor= e.html#r-h-attempt-access

".... The requester typically = attempts to access the desired resource at the host directly (for example, when a human operator of the requester software clicks on a thumbnail = representation of the resource). The requester is expected to discover, or be = provisioned or configured with, knowledge of the protected resource and its location out of band. Further, the requester is expected to acquire its own = knowledge about the application-specific methods made available by the host for = operating on this protected resource (such as viewing it with a GET method, or = transforming it with some complex API call) and the possible scopes of = access."

So the requester can initiate = the request, with the following preconditions:

- The host (RS) has registered = this resource as protected with the authorization manager (AS).
- The requester = (client)/requesting party has learned the location and applicable API details of the = resource out of band.

The interactions among the host = (RS), AM (AS), and requester (client -- potentially operated by a third party who is not the RO) are protected with various tokens. This is = illustrated in the introduction with ASCII art...

http://docs.kantarainitiative.org/uma/draft-uma-cor= e.html#introduction

The actual protected resource = requires a "requester permission token" (RPT) associated with suitable authorization data. This is an UMA-specific construct -- admittedly not a true OAuth flow, though inspired by it! The AM presents a protection API to the host for registering protected resources; the API is = protected by a plain-vanilla OAuth token called a protection API token (PAT). The AM also presents an authorization API to the requester, which is = protected by a plain-vanilla OAuth token called an authorization API token (AAT). We're counting on dynamic client registration to be in place wherever = deployers want true loose coupling.

When the requester initiates a = request, if it has no token at all, the host directs it to the AM to get first an AAT (which conveys Bob's authorization to use it and the AM in conveying identity claims to win authorization), and ultimately an RPT (which = convey's Alice's authorization for Bob and this requester app to access the = resource with specific scopes). Of course we're talking about an UMA-enabled = requester here, but it can literally initiate an access request with zero tokens and ultimately get somewhere.

We'll be demoing this whole = thing next Wednesday in the webinar, including the dynamic client reg, the PAT, = AAT, and RPT, the UX for the various parties interacting with systems, and = even interesting app-level enhancements like notifying Alice that Bob has = made an access attempt and inviting her to set up policies that let him = in.

Eve

On 10 Oct 2012, at 3:35 PM, = Prabath Siriwardena <prabath@wso2.com> wrote:

Hi Eve,

I have gone through UMA spec = but failed to find any case which covers this scenario - in a resource owner = initiated manner..

Can you please give some = pointers..?

Thanks & regards,
-Prabath

On Wed, Oct 10, 2012 at 3:20 = PM, Eve Maler <eve@xmlgrrl.com> wrote:
There are a number of implicit = actions happening here that ideally should be accounted for. If Alice is the RO and Bob is operating the client, then when Bob accesses the protected = resource it may not just be "on Alice's behalf" -- think of how people share calendar read/write access with other people today. Those with = delegated access act on their own behalf, with the RO's permission. So the tuple represented by the access token is actually quite a bit bigger than = usual.

Since OAuth makes a simplifying = assumption that gets it entirely out of this sort of business, the process of = trying to shoehorn this use case into a single plain OAuth flow may end badly. Better would be an explicit recognition of the symmetry of Alice (with her user agent) on one side, and bob with his client on the other side. Not to sound like a broken record, but the UMA model takes this fully = into account and has even gone a fair way down the path of considering the = contractual and legal implications of such authorization.

Since the client (along with = its operator) has to register on the AS side anyway, having a clean model where it can do that without the RO's synchronous presence would be ideal. Otherwise I suspect it's impractical in normal use.

Eve

On 9 Oct 2012, at 6:49 PM, = zhou.sujing@zte.com.cn wrote:


Hi=A3=ACPrabath

Prabath = Siriwardena <prabath@wso2.com>

2012-10-09 = 20:35


=CA=D5=BC=FE=C8=CB
zhou.sujing@zte.com.cn
=B3=AD=CB=CD
Eve Maler <eve@xmlgrrl.com>, oauth@ietf.org, oauth-bounces@ietf.org
=D6=F7=CC=E2
Re: Re: Re: Re: [OAUTH-WG] = Resource owner initiated OAuth delegation









On Mon, Oct 8, 2012 at 6:24 PM, <zhou.sujing@zte.com.cn> wrote:

Hi=A3=AC Prabath

My question is since client-id is public, then it is a waste to get it by granting an access-token.
And in step 2."Resource Owner grants access to a selected Client", RO  logins in to select clients to be delegated,
and RS redirects RO to AS to grant access token to client, to my = understanding, in this process RO needs to authenticate to RS and then authenticate =
to AS, it is a bit complicated.

In fact I did not want to disturb normal OAuth flow.. BTW yes.. it adds some overhead.. So - I would like to modify it - where the Resource = Server sends the resource_owner_initiated as the scope - and based on the scope AS returns back client_id together with the access_token it self.
 

I wonder if the following two processes could satisfy your case:

Process One:
1. Resource Owner registers to-be-delegated clients and corresponding = RSs at AS, i.e., a long term delegation contract is stored at AS

2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token
3. Client accesses the protected resource on behalf of the Resource = Owner.

Process Two:
1. RO registers to-be-delegated clients at RS, i.e., a long term = delegation contract is stored at RS
2. When Resource Owner requests Client to access its resource at RS, = Client is directed by RS to AS to obtain access-token,AS may request RO to = authenticate and confirm the
access-token request
3. Client accesses the protected resource on behalf of the Resource = Owner.  


There needs to be an step to facilitate client registration. =
Client could have registered at AS.
RO just select clients from available clients list.
This facilitating step still needed?

Thanks & regards,
-Prabath
 


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756   =                       http://www.twitter.com/xmlgrrl




--
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732

http://blog.facilelogin.com
http://RampartFAQ.com



Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl



Eve Maler       =                     =        http://www.xmlgrrl.com/blog
+1= 425 345 6756                 =         http://www.twitter.com/xmlgrrl=


On Mon, Oct 8, 2012 at 6:24 PM, <= zhou.sujing@zte.com.cn> wrote:

Hi=A3=AC Prabath
 
  My question is since client-id is public, then it is a waste to get it by granting an access-token.
  And in step 2.= "Resource Owner grants access to a selected Client&q= uot;, RO  logins in to select clients to be delegated,
 and RS redirects RO to AS to grant access token to client, to my understanding, in this process RO needs to authenticate to RS and then authenticate
to AS, it is a bit complicated.

In fact I did not want to disturb norm= al OAuth flow.. BTW yes.. it adds some overhead.. So - I would like to modi= fy it - where the Resource Server sends the resource_owner_initiated a= s the scope - and based on the scope AS returns back client_id together wit= h the access_token it self.
 

  I wonder if the following two processes could satisfy your case:

Process One:
1. Resource Owner registers to-be-delegated clients and corresponding RSs at AS, i.e., a long term delegation contract is stored at AS

2. When Resource Owner requests Client to access its resource at RS, Client is directed by RS to AS to obtain access-token
3. Client accesses the protected resource on behalf of the Resource Owner.

Process Two:
1. RO registers to-be-delegated clients at RS, i.e., a long term delegation contract is stored at RS
2. When Resource Owner requests Client to access its resource at RS, Client is directed by RS to AS to obtain access-token,AS may request RO to authenticate and confirm the
access-token request
3. Client accesses the protected resource on behalf of the Resource Owner.  


There needs to be an step to facilitat= e client registration.

Thanks & regards,<= /div>
-Prabath
 


Prabath Siriwarde= na <prabath@wso2.c= om>

2012-10-08 12:00

=CA=D5=BC=FE=C8= =CB
zhou.sujing@zte.com.cn
=B3=AD=CB=CD
Eve Maler &= lt;eve@xmlgrrl.com= >, oauth@ietf.org, oauth-bounces@i= etf.org
=D6=F7=CC=E2
Re: Re: Re: [OAUTH-WG] Resour= ce owner initiated OAuth delegation





Hi Zhou,

Even though client_id= is public that needs to be passed from the Authorization Server to the Resource Serve= r. This does not happen in the normal OAuth flow. It only returns back the access_token.

Please let me know if= you need any further clarifications...

Thanks & regards,=
-Prabath

On Sun, Oct 7, 2012 at 8:03 PM, &l= t;zhou.sujing@zte.com.cn= > wrote:

Hi,Prabath<= font size=3D"3" face=3D"sans-serif">

I have read your proposal, and have some questions:

 why RS needs to get access token in client register stage;
 and why RS needs to get client-id from AS by exchanging access token (isn't client-id public?)
 

Prabath Siriwarde= na <prabath@wso2.com= >

2012-10-08 09:50


=CA=D5=BC=FE=C8= =CB
zhou.sujing@= zte.com.cn
=B3=AD=CB=CD
Eve Maler <eve@xmlgrrl.com>, oauth@ietf.org, oauth-bounces@ietf.org
=D6=F7=CC=E2
Re: Re: [OAUTH-WG] Resource o= wner initiated OAuth delegation







Hi Zhou,

Nice to see some common interest on this. Sure I will go through your propo= sal.

Please find my proposal here [1]. I've added there the complete token f= low, introducing a new grant type. <= br>
[1]: http://blog.facilelogin.com/2012/10/proposal-resource-o= wner-initiated.html

Thanks & regards,
-Prabath

On Sun, Oct 7, 2012 at 6:24 PM, <zhou.sujing@zte.com.cn> wrote:

Hi,  Praba

I am also thinking on this subject, and published a draft on it.
http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt
I'd like to have your opinion.

Prabath Siriwarde= na <prabath@wso2.com= >
=B7=A2=BC=FE=C8=CB:  oa= uth-bounces@ietf.org

2012-10-08 08:08


=CA=D5=BC=FE=C8= =CB
Eve Maler <<= /font>eve@xmlgrrl.com>
=B3=AD=CB=CD
oauth@ietf.org
=D6=F7=CC=E2
Re: [OAUTH-WG] Resource owner= initiated OAuth delegation






Hi Eve,

Thanks for pointers.. I've been following the work done in UMA.. Sure.. will join the webinar...

BTW .. I am not quite sure UMA addresses my use case. Even in the case of UMA it's client initiated or requestor initiated...

Please correct me if I am wrong... but in OAuth specification there is no restrictions to identify the 'client' as a person, organization = or as him self..  

In my view - this is an extended grant type..which has two phases..

1. Resource owner grants access to a selected a Client
2. Client requests the already available access token for him from the Authorization Server.[just like passing the refresh_token]

WDYT ?

Thanks & regards,
-Prabath  

On Sun, Oct 7, 2012 at 11:05 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Hi Prabath,

As far as I know, OAuth itself generally isn't used to let one human re= source owner delegate access to a different human resource owner. However, UMA (which leverages OAuth) does strive to solve exactly this use case, among other similar ones; we call this one "person-to-person sharing", and you can read more about it here: http://docs.kantarainitiative= .org/uma/draft-uma-trust.html#anchor1

The UMA flow at run time still ends up being effectively "client-initi= ated" (we would say requesting-party-initiated, using a requester app) because the original resource owner (we call it an authorizing party) is no longer around by then. The authz party would set up policies at some point before going on vacation, and these polices would enable the requesting party to "qualify in" for access at run time, by supplying identity claims that get used in an authorization check by the authz server (authz manager).

We'll be walking through UMA flows and demoing an extensive use case at a webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg

Hope this helps,

      Eve

On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena <prabath@wso2.com> wrote:

> Hi folks,
>
> I would like to know your thoughts on the $subject..
>
> For me it looks like a concrete use case where OAuth conceptually does
> address - but protocol does not well defined..
>
> Please find [1] for further details...
>
> [1]: http://blog.facilelogin.com/2012/10/ationwhat= -oauth-lacks-resource-owner.html
>
> --
> Thanks & Regards,
> Prabath
>
> Mobile : +94 71 809 6732
>
> http://blog.facilelogin.= com
> http://RampartFAQ.com
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<= font size=3D"3" face=3D"sans-serif">
> https://= www.ietf.org/mailman/listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756   &nb= sp;                     http://www.twitter.com/xmlgrrl=





--
Thanks & Regards,
Prabath

Mobile : <= font size=3D"3" color=3D"blue" face=3D"sans-serif">+94 71 809 6732

http://blog.facilelogin.c= om http://RampartFAQ.com
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth




--
Thanks & Regards,
Prabath

Mobile : <= font size=3D"3" color=3D"blue" face=3D"sans-serif">+94 71 809 6732

http://blog.facilelogin.c= om http://RampartFAQ.com




--
Thanks & Regards,
Prabath

Mobile : +94 71 809 6732=

http://blog.facilelogin.c= om http://RampartFAQ.com




-= -
Thanks & Regards,
Prabath


--047d7b6dcaf06792ff04cb9f94d2-- From bcampbell@pingidentity.com Tue Oct 9 07:34:34 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EABE11E8097 for ; Tue, 9 Oct 2012 07:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+03xJY-0tTA for ; Tue, 9 Oct 2012 07:34:33 -0700 (PDT) Received: from na3sys009aog132.obsmtp.com (na3sys009aog132.obsmtp.com [74.125.149.250]) by ietfa.amsl.com (Postfix) with ESMTP id 83D6921F877D for ; Tue, 9 Oct 2012 07:34:32 -0700 (PDT) Received: from mail-vc0-f172.google.com ([209.85.220.172]) (using TLSv1) by na3sys009aob132.postini.com ([74.125.148.12]) with SMTP ID DSNKUHQ1+AJdYnjturucWckhmlsWkDLEfwRY@postini.com; Tue, 09 Oct 2012 07:34:32 PDT Received: by mail-vc0-f172.google.com with SMTP id fl11so7537044vcb.31 for ; Tue, 09 Oct 2012 07:34:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xCgYNoViXLCtcYE0zTcOF/FqXTUw5CAHBGS1pCxIsxI=; b=djAemMqdDBUy6PDs11rs9hTZk/lU2JFX2zQzIferVSvmcpFrlU4xonbxYBkZtFAkFj o0xPsmHCubqFZqlwrLxSzMraUt34FOF4DiHGN/pnAVdAcAYAC4UV70L4/EMx1NftU1E8 fbgUJQIRktU2bjnfarR6Amyir9QL/jaZrm5J0E0uQ1cfC9KmPnUrG46LPloqcXQeO88R kygKynMWB+jH+QCcwx8DgewQv1EkrRQNdkmHlAlTaEXNjn9cb01crIPa4HlTCKMu2+95 sdB74sHShFJ9fCyqCowY/JXH8vKHB6Ca0L4aVkH/x6ZUC8fbAvHAOgU0rGMHhqKszNsB 6vSA== Received: by 10.220.150.16 with SMTP id w16mr11682661vcv.65.1349793271305; Tue, 09 Oct 2012 07:34:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.151.240 with HTTP; Tue, 9 Oct 2012 07:34:01 -0700 (PDT) In-Reply-To: <9F69CF75-53B5-4376-8430-E4289FFA625E@salesforce.com> References: <999913AB42CC9341B05A99BBF358718D01EF152F@FIESEXC035.nsn-intra.net> <4E1F6AAD24975D4BA5B16804296739436682A26D@TK5EX14MBXC284.redmond.corp.microsoft.com> <9F69CF75-53B5-4376-8430-E4289FFA625E@salesforce.com> From: Brian Campbell Date: Tue, 9 Oct 2012 08:34:01 -0600 Message-ID: To: Chuck Mortimore , Hannes Tschofenig Content-Type: multipart/alternative; boundary=f46d0438909574d7b104cba13ceb X-Gm-Message-State: ALoCoQmRsihmU+RRk6Jef4CEMOAo+YF9CtJ+c0XkuQj1Nbuu08zqUEf6xGyh5vD8MaInOPQgNixr Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] draft-ietf-oauth-assertions-06 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 14:34:34 -0000 --f46d0438909574d7b104cba13ceb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a vendor we can't really share deployment particulars of our customers. But we've had product support for the SAML authorization grant for some time now. So I can point to some online documentation for the support we provide in our PingFederate product as an AS, http://documentation.pingidentity.com/display/PF610/Configuring+an+OAuth+SA= ML+Grant+IdP+Connectionand http://documentation.pingidentity.com/display/PF610/Grant+Types#GrantTypes-= 1218708as well client side support for obtaining suitable SAML tokens via WS-Trust or brokering the OAuth request directly to the AS, http://documentation.pingidentity.com/display/PF610/STS+OAuth+Integration Off hand I also remember that Google released some support for JWT grants in March. My colleague, the venerable John Fontana, wrote about that on ZDnet, http://www.zdnet.com/blog/identity/google-dumps-keys-passwords-secures-serv= ices-with-standards-certs/342 On Mon, Oct 8, 2012 at 6:14 PM, Chuck Mortimore wrote: > Our use-cases are pretty straightforward - customers want to perform > server to server integration tasks without passwords. > > We use the SAML and JWT assertion profiles to enable them to authenticate > to our system without having a password for the service principal they're > trying to act as. Sometimes this is for security purposes ( customer > doesn't want to use passwords ), and sometimes it's for scale purposes ( > customer is building some sort of hub-spoke integration architecture wher= e > passwords and their associated distribution and maintenance simple won't > scale ) > > While SAML is predominantly used for Web SSO today, it is used and quite > applicable in these types of scenarios. The easy way to picture what > we're doing is deploying a Security Token Service similar to WS-Trust, bu= t > without all the baggage of WS-Trust....you can simply post Assertions to > our Token Endpoint and we can exchange that for oauth access tokens. > > -cmort > > > On Oct 8, 2012, at 5:05 PM, Mike Jones wrote: > > Yes, OpenID Connect uses the Assertions spec and the JWT Assertion > Profile. See uses of [OAuth.JWT] in > http://openid.net/specs/openid-connect-messages-1_0.html. It is used > for both client_secret_jwt and private_key_jwt client authentication. Pe= r > http://osis.idcommons.net/wiki/Category:OC4_Solution, there are a dozen > publicly declared OpenID Connect implementations (admittedly some > incomplete), and substantial interop testing is under way, per > http://osis.idcommons.net/wiki/OC4:OpenID_Connect_Interop_4.**** > ** ** > Brian Campbell and Chuck Mortimore may be able to provide similar data fo= r > use of the SAML Profile.**** > ** ** > -- Mike**= * > * > ** ** > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On > Behalf Of *Tschofenig, Hannes (NSN - FI/Espoo) > *Sent:* Monday, October 08, 2012 5:13 AM > *To:* oauth@ietf.org > *Subject:* [OAUTH-WG] draft-ietf-oauth-assertions-06**** > ** ** > > Hi all,**** > > I took a look at version -06 of the assertions draft to see whether some > of the discussions had been reflected in this recent draft update.**** > > I was hoping that there is a bit more explanation of the use case that > motivates the work. Unfortunately, the update does not contain anything > along these lines.**** > > For example, the use cases could clarify the following aspects:**** > > =B7 Why we need these new client authentication mechanisms? This is > not necessarily a way in which SAML is used (at least not to my knowledge= ). > If I understood it correctly then the new client authentication > mechanism is only used between the client and the authorization server bu= t > not with the resource server. Did I correctly read the document? **** > > =B7 Then, there is the assertion usage for authorization grants. > There, one could argue that the use case is to interwork with existing SA= ML > infrastructure. The sameargument does not apply for the JSON based format > since there is no transition need (IMHO at least).**** > > Ciao > Hannes**** > > PS: For the shepherd write-up I have to attach information about the > implementation and deployment experience. Is there anything I could > mention? Has this specification been part of the OpenID Connect interop > tests? If so, what specifically had been tested?**** > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --f46d0438909574d7b104cba13ceb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a vendor we can't really share deployment particulars of our custome= rs. But we've had product support for the SAML authorization grant for = some time now. So I can point to some online documentation for the support = we provide in our PingFederate product as an AS, http://documentation.pingidentity.com/display/PF610/Configuring+a= n+OAuth+SAML+Grant+IdP+Connection and http://docume= ntation.pingidentity.com/display/PF610/Grant+Types#GrantTypes-1218708 a= s well client side support for obtaining suitable SAML tokens via WS-Trust = or brokering the OAuth request directly to the AS, http://docume= ntation.pingidentity.com/display/PF610/STS+OAuth+Integration

Off hand I also remember that Google released some support for JWT gran= ts in March. My colleague, the venerable John Fontana, wrote about that on = ZDnet, http://www.zdnet.com/blog/= identity/google-dumps-keys-passwords-secures-services-with-standards-certs/= 342


On Mon, Oct 8, 2012 at 6:14 PM, Chuck Mo= rtimore <cmortimore@salesforce.com> wrote:
Our use-cases are pretty straightf= orward - customers want to perform server to server integration tasks witho= ut passwords. =A0

We use the SAML and JWT assertio= n profiles to enable them to authenticate to our system without having a pa= ssword for the service principal they're trying to act as. =A0 Sometime= s this is for security purposes ( customer doesn't want to use password= s ), and sometimes it's for scale purposes ( customer is building some = sort of hub-spoke integration architecture where passwords and their associ= ated distribution and maintenance simple won't scale )=A0

While SAML is predominantly used for Web SSO today, it = is used and quite applicable in these types of scenarios. =A0 The easy way = to picture what we're doing is deploying a Security Token Service simil= ar to WS-Trust, but without all the baggage of WS-Trust....you can simply p= ost Assertions to our Token Endpoint and we can exchange that for oauth acc= ess tokens.

-cmort


<= div>On Oct 8, 2012, at 5:05 PM, Mike Jones wrote:

Yes, OpenID Connect uses the Assertions spec and th= e JWT Assertion Profile.=A0 See uses of [OAuth.JWT] in=A0http://o= penid.net/specs/openid-connect-messages-1_0.html.=A0 =A0It is used for = both client_secret_jwt and private_key_jwt client authentication.=A0 Per=A0http://= osis.idcommons.net/wiki/Category:OC4_Solution, there are a dozen public= ly declared OpenID Connect implementations (admittedly some incomplete), an= d substantial interop testing is under way, per=A0http://osis.idcommons.net= /wiki/OC4:OpenID_Connect_Interop_4.
=A0
Brian Campbell and Chuck Mortimore may be able to provide similar data for= use of the SAML Profile.
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
=A0
From:= =A0oauth-bounces@ietf.org=A0[mailto:oauth-= bounces@ietf.org]=A0On Behalf Of=A0Tsc= hofenig, Hannes (NSN - FI/Espoo)
Sent:=A0Monday, October 08, 2012 5:13 AM
To:<= span>=A0oauth@ietf.org
Subject:=A0[OAUTH-WG] draft-ietf-oauth-assertions-06
=A0

Hi all,=

I took a look at version -06 of the assertions draft to see whether s= ome of the discussions had been reflected in this recent draft update.

I was hoping that there is a bit more=A0explanation of the use case that motiva= tes the work. Unfortunately, the update does not contain anything along the= se lines.

For example, the use cases could clarify the following aspects:=

=B7= =A0=A0=A0=A0=A0=A0= =A0Why we need = these=A0= new client authentication mechanisms?=A0This is not necessarily a way in which SAML= is used (at least not to my knowledge).=A0If I understood it correctly then the n= ew client authentication mechanism is only used between the client and the = authorization server but not with the resource server.=A0Did I correctly read the d= ocument?=A0

=B7<= /span>=A0=A0=A0=A0=A0=A0<= /span>=A0Then, = there is=A0the assertion usage for authorization grants. There, one could argue tha= t the use case is to interwork with existing SAML infrastructure. The same<= /span>argument does not appl= y for the JSON based format since there is no transition need (IMHO at leas= t).

Ciao
Hannes

PS: For the shepherd<= span>=A0write-up I ha= ve to attach information about the implementation and deployment experience= . Is there anything I could mention? Has this specification been part of th= e OpenID Connect interop tests? If so, what=A0specifically had been tested?<= u>

_______________________________________________
OAuth mailin= g list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= br>


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


--f46d0438909574d7b104cba13ceb-- From jricher@mitre.org Tue Oct 9 12:54:52 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFD11F040A for ; Tue, 9 Oct 2012 12:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jo2wkLRVp9x for ; Tue, 9 Oct 2012 12:54:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 18DCB21F8543 for ; Tue, 9 Oct 2012 12:54:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 568C01F070E; Tue, 9 Oct 2012 15:54:51 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 415591F0705; Tue, 9 Oct 2012 15:54:51 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.44]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.001; Tue, 9 Oct 2012 15:54:50 -0400 From: "Richer, Justin P." To: "Zeltsan, Zachary (Zachary)" Thread-Topic: [OAUTH-WG] Agenda for Atlanta Meeting Thread-Index: AQHNos/0R5eCCH1cbkSmVf7KyytBnJesx4uAgAAdowCAAWRRAIADY9EA Date: Tue, 9 Oct 2012 19:54:50 +0000 Message-ID: References: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> <5070654D.40007@lodderstedt.net> <97A330AD-C451-4472-B38C-EF59034EC810@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.54.77] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 19:54:52 -0000 Good for me, AS LONG AS we make absolutely SURE that we leave plenty of tim= e for #8 on the agenda, to the point of cutting off and tabling other discu= ssions ahead of time. There are a lot of ancillary documents in various sta= tes of use/neglect that shouldn't be left aside by the WG, and this is a go= od venue for all of that. -- Justin On Oct 7, 2012, at 12:08 PM, Zeltsan, Zachary (Zachary) wrote: > +1 >=20 > Zachary >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of= Phil Hunt > Sent: Saturday, October 06, 2012 2:54 PM > To: Torsten Lodderstedt > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting >=20 > +1 >=20 > Phil >=20 > On 2012-10-06, at 10:07, Torsten Lodderstedt wr= ote: >=20 >> fine for me >>=20 >> Am 05.10.2012 10:03, schrieb Hannes Tschofenig: >>> Hi all, >>>=20 >>> here is an agenda proposal for the Atlanta IETF meeting: >>> (The indicated names are proposals.) >>>=20 >>> ------ >>> Agenda: >>>=20 >>> 1. Status Update, Agenda Bashing (Chairs) >>> 2. Token Revocation (Thorsten) >>> 3. Assertions (Brian + Mike) >>> 4. OAuth Use Cases (Zachary) >>> 5. JWT (Mike) >>> 6. Security (Phil) >>> 7. Dynamic Client Registration (Thomas) >>> 8. Roadmap >>> ------ >>>=20 >>> In the last item we would like to discuss the bigger picture of how to = get OAuth 2.0 deployment improved. There are at least 2 parts to this, name= ly (a) what other specifications do we need to work on, and (b) how do we i= mprove interoperability. >>>=20 >>> Let us know whether you think that this fits your needs. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>> PS: I am hoping to see daft updates of the WG items soon. >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From zhou.sujing@zte.com.cn Tue Oct 9 18:50:11 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0661F0C5C; Tue, 9 Oct 2012 18:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.158 X-Spam-Level: X-Spam-Status: No, score=-96.158 tagged_above=-999 required=5 tests=[AWL=1.431, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZnnpm8dSs-B; Tue, 9 Oct 2012 18:50:09 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 825601F0C4C; Tue, 9 Oct 2012 18:50:08 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 14C58125B9CB; Wed, 10 Oct 2012 09:42:02 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 9319EDF61F7; Wed, 10 Oct 2012 09:46:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q9A1nuee047102; Wed, 10 Oct 2012 09:49:56 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Prabath Siriwardena MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Wed, 10 Oct 2012 09:49:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-10-10 09:49:52, Serialize complete at 2012-10-10 09:49:52 Content-Type: multipart/alternative; boundary="=_alternative 000A23FE48257A93_=" X-MAIL: mse01.zte.com.cn q9A1nuee047102 Cc: oauth@ietf.org, oauth-bounces@ietf.org Subject: Re: [OAUTH-WG] Resource owner initiated OAuth delegation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 01:50:11 -0000 This is a multipart message in MIME format. --=_alternative 000A23FE48257A93_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrFByYWJhdGgNCg0KDQoNClByYWJhdGggU2lyaXdhcmRlbmEgPHByYWJhdGhAd3NvMi5jb20+ IA0KMjAxMi0xMC0wOSAyMDozNQ0KDQrK1bz+yMsNCnpob3Uuc3VqaW5nQHp0ZS5jb20uY24NCrOt y80NCkV2ZSBNYWxlciA8ZXZlQHhtbGdycmwuY29tPiwgb2F1dGhAaWV0Zi5vcmcsIG9hdXRoLWJv dW5jZXNAaWV0Zi5vcmcNCtb3zOINClJlOiBSZTogUmU6IFJlOiBbT0FVVEgtV0ddIFJlc291cmNl IG93bmVyIGluaXRpYXRlZCBPQXV0aCBkZWxlZ2F0aW9uDQoNCg0KDQoNCg0KDQoNCg0KT24gTW9u LCBPY3QgOCwgMjAxMiBhdCA2OjI0IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbj4gd3JvdGU6 DQoNCkhpo6wgUHJhYmF0aCANCiANCiAgTXkgcXVlc3Rpb24gaXMgc2luY2UgY2xpZW50LWlkIGlz IHB1YmxpYywgdGhlbiBpdCBpcyBhIHdhc3RlIHRvIGdldCBpdCANCmJ5IGdyYW50aW5nIGFuIGFj Y2Vzcy10b2tlbi4gDQogIEFuZCBpbiBzdGVwIDIuIlJlc291cmNlIE93bmVyIGdyYW50cyBhY2Nl c3MgdG8gYSBzZWxlY3RlZCBDbGllbnQiLCBSTyANCmxvZ2lucyBpbiB0byBzZWxlY3QgY2xpZW50 cyB0byBiZSBkZWxlZ2F0ZWQsIA0KIGFuZCBSUyByZWRpcmVjdHMgUk8gdG8gQVMgdG8gZ3JhbnQg YWNjZXNzIHRva2VuIHRvIGNsaWVudCwgdG8gbXkgDQp1bmRlcnN0YW5kaW5nLCBpbiB0aGlzIHBy b2Nlc3MgUk8gbmVlZHMgdG8gYXV0aGVudGljYXRlIHRvIFJTIGFuZCB0aGVuIA0KYXV0aGVudGlj YXRlIA0KdG8gQVMsIGl0IGlzIGEgYml0IGNvbXBsaWNhdGVkLiANCg0KSW4gZmFjdCBJIGRpZCBu b3Qgd2FudCB0byBkaXN0dXJiIG5vcm1hbCBPQXV0aCBmbG93Li4gQlRXIHllcy4uIGl0IGFkZHMg DQpzb21lIG92ZXJoZWFkLi4gU28gLSBJIHdvdWxkIGxpa2UgdG8gbW9kaWZ5IGl0IC0gd2hlcmUg dGhlIFJlc291cmNlIFNlcnZlciANCnNlbmRzIHRoZSByZXNvdXJjZV9vd25lcl9pbml0aWF0ZWQg YXMgdGhlIHNjb3BlIC0gYW5kIGJhc2VkIG9uIHRoZSBzY29wZSANCkFTIHJldHVybnMgYmFjayBj bGllbnRfaWQgdG9nZXRoZXIgd2l0aCB0aGUgYWNjZXNzX3Rva2VuIGl0IHNlbGYuDQogDQoNCiAg SSB3b25kZXIgaWYgdGhlIGZvbGxvd2luZyB0d28gcHJvY2Vzc2VzIGNvdWxkIHNhdGlzZnkgeW91 ciBjYXNlOiANCg0KUHJvY2VzcyBPbmU6IA0KMS4gUmVzb3VyY2UgT3duZXIgcmVnaXN0ZXJzIHRv LWJlLWRlbGVnYXRlZCBjbGllbnRzIGFuZCBjb3JyZXNwb25kaW5nIFJTcyANCmF0IEFTLCBpLmUu LCBhIGxvbmcgdGVybSBkZWxlZ2F0aW9uIGNvbnRyYWN0IGlzIHN0b3JlZCBhdCBBUyANCg0KMi4g V2hlbiBSZXNvdXJjZSBPd25lciByZXF1ZXN0cyBDbGllbnQgdG8gYWNjZXNzIGl0cyByZXNvdXJj ZSBhdCBSUywgDQpDbGllbnQgaXMgZGlyZWN0ZWQgYnkgUlMgdG8gQVMgdG8gb2J0YWluIGFjY2Vz cy10b2tlbiANCjMuIENsaWVudCBhY2Nlc3NlcyB0aGUgcHJvdGVjdGVkIHJlc291cmNlIG9uIGJl aGFsZiBvZiB0aGUgUmVzb3VyY2UgT3duZXIuIA0KDQoNClByb2Nlc3MgVHdvOiANCjEuIFJPIHJl Z2lzdGVycyB0by1iZS1kZWxlZ2F0ZWQgY2xpZW50cyBhdCBSUywgaS5lLiwgYSBsb25nIHRlcm0g DQpkZWxlZ2F0aW9uIGNvbnRyYWN0IGlzIHN0b3JlZCBhdCBSUyANCjIuIFdoZW4gUmVzb3VyY2Ug T3duZXIgcmVxdWVzdHMgQ2xpZW50IHRvIGFjY2VzcyBpdHMgcmVzb3VyY2UgYXQgUlMsIA0KQ2xp ZW50IGlzIGRpcmVjdGVkIGJ5IFJTIHRvIEFTIHRvIG9idGFpbiBhY2Nlc3MtdG9rZW4sQVMgbWF5 IHJlcXVlc3QgUk8gdG8gDQphdXRoZW50aWNhdGUgYW5kIGNvbmZpcm0gdGhlIA0KYWNjZXNzLXRv a2VuIHJlcXVlc3QgDQozLiBDbGllbnQgYWNjZXNzZXMgdGhlIHByb3RlY3RlZCByZXNvdXJjZSBv biBiZWhhbGYgb2YgdGhlIFJlc291cmNlIE93bmVyLiANCiANCg0KDQpUaGVyZSBuZWVkcyB0byBi ZSBhbiBzdGVwIHRvIGZhY2lsaXRhdGUgY2xpZW50IHJlZ2lzdHJhdGlvbi4NCkNsaWVudCBjb3Vs ZCBoYXZlIHJlZ2lzdGVyZWQgYXQgQVMuDQpSTyBqdXN0IHNlbGVjdCBjbGllbnRzIGZyb20gYXZh aWxhYmxlIGNsaWVudHMgbGlzdC4gDQpUaGlzIGZhY2lsaXRhdGluZyBzdGVwIHN0aWxsIG5lZWRl ZD8NCg0KVGhhbmtzICYgcmVnYXJkcywNCi1QcmFiYXRoDQogDQoNCg0KDQpQcmFiYXRoIFNpcml3 YXJkZW5hIDxwcmFiYXRoQHdzbzIuY29tPiANCjIwMTItMTAtMDggMTI6MDAgDQoNCg0KytW8/sjL DQp6aG91LnN1amluZ0B6dGUuY29tLmNuIA0Ks63LzQ0KRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5j b20+LCBvYXV0aEBpZXRmLm9yZywgb2F1dGgtYm91bmNlc0BpZXRmLm9yZyANCtb3zOINClJlOiBS ZTogUmU6IFtPQVVUSC1XR10gUmVzb3VyY2Ugb3duZXIgaW5pdGlhdGVkIE9BdXRoIGRlbGVnYXRp b24NCg0KDQoNCg0KDQoNCg0KDQpIaSBaaG91LCANCg0KRXZlbiB0aG91Z2ggY2xpZW50X2lkIGlz IHB1YmxpYyB0aGF0IG5lZWRzIHRvIGJlIHBhc3NlZCBmcm9tIHRoZSANCkF1dGhvcml6YXRpb24g U2VydmVyIHRvIHRoZSBSZXNvdXJjZSBTZXJ2ZXIuIFRoaXMgZG9lcyBub3QgaGFwcGVuIGluIHRo ZSANCm5vcm1hbCBPQXV0aCBmbG93LiBJdCBvbmx5IHJldHVybnMgYmFjayB0aGUgYWNjZXNzX3Rv a2VuLiANCg0KUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBuZWVkIGFueSBmdXJ0aGVyIGNsYXJp ZmljYXRpb25zLi4uIA0KDQpUaGFua3MgJiByZWdhcmRzLCANCi1QcmFiYXRoIA0KDQpPbiBTdW4s IE9jdCA3LCAyMDEyIGF0IDg6MDMgUE0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPiB3cm90ZTog DQoNCkhpLFByYWJhdGggDQoNCkkgaGF2ZSByZWFkIHlvdXIgcHJvcG9zYWwsIGFuZCBoYXZlIHNv bWUgcXVlc3Rpb25zOiANCg0KIHdoeSBSUyBuZWVkcyB0byBnZXQgYWNjZXNzIHRva2VuIGluIGNs aWVudCByZWdpc3RlciBzdGFnZTsgDQogYW5kIHdoeSBSUyBuZWVkcyB0byBnZXQgY2xpZW50LWlk IGZyb20gQVMgYnkgZXhjaGFuZ2luZyBhY2Nlc3MgdG9rZW4gDQooaXNuJ3QgY2xpZW50LWlkIHB1 YmxpYz8pIA0KIA0KDQoNClByYWJhdGggU2lyaXdhcmRlbmEgPHByYWJhdGhAd3NvMi5jb20+IA0K MjAxMi0xMC0wOCAwOTo1MCANCg0KDQrK1bz+yMsNCnpob3Uuc3VqaW5nQHp0ZS5jb20uY24gDQqz rcvNDQpFdmUgTWFsZXIgPGV2ZUB4bWxncnJsLmNvbT4sIG9hdXRoQGlldGYub3JnLCBvYXV0aC1i b3VuY2VzQGlldGYub3JnIA0K1vfM4g0KUmU6IFJlOiBbT0FVVEgtV0ddIFJlc291cmNlIG93bmVy IGluaXRpYXRlZCBPQXV0aCBkZWxlZ2F0aW9uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhpIFpob3Us IA0KDQpOaWNlIHRvIHNlZSBzb21lIGNvbW1vbiBpbnRlcmVzdCBvbiB0aGlzLiBTdXJlIEkgd2ls bCBnbyB0aHJvdWdoIHlvdXIgDQpwcm9wb3NhbC4gDQoNClBsZWFzZSBmaW5kIG15IHByb3Bvc2Fs IGhlcmUgWzFdLiBJJ3ZlIGFkZGVkIHRoZXJlIHRoZSBjb21wbGV0ZSB0b2tlbiANCmZsb3csIGlu dHJvZHVjaW5nIGEgbmV3IGdyYW50IHR5cGUuIA0KDQpbMV06IA0KaHR0cDovL2Jsb2cuZmFjaWxl bG9naW4uY29tLzIwMTIvMTAvcHJvcG9zYWwtcmVzb3VyY2Utb3duZXItaW5pdGlhdGVkLmh0bWwg DQoNCg0KVGhhbmtzICYgcmVnYXJkcywgDQotUHJhYmF0aCANCg0KT24gU3VuLCBPY3QgNywgMjAx MiBhdCA2OjI0IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbj4gd3JvdGU6IA0KDQpIaSwgIFBy YWJhIA0KDQpJIGFtIGFsc28gdGhpbmtpbmcgb24gdGhpcyBzdWJqZWN0LCBhbmQgcHVibGlzaGVk IGEgZHJhZnQgb24gaXQuIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXpob3Utb2F1 dGgtb3duZXItYXV0aC0wMC50eHQgDQpJJ2QgbGlrZSB0byBoYXZlIHlvdXIgb3Bpbmlvbi4gDQoN Cg0KUHJhYmF0aCBTaXJpd2FyZGVuYSA8cHJhYmF0aEB3c28yLmNvbT4gDQq3orz+yMs6ICBvYXV0 aC1ib3VuY2VzQGlldGYub3JnIA0KMjAxMi0xMC0wOCAwODowOCANCg0KDQrK1bz+yMsNCkV2ZSBN YWxlciA8ZXZlQHhtbGdycmwuY29tPiANCrOty80NCm9hdXRoQGlldGYub3JnIA0K1vfM4g0KUmU6 IFtPQVVUSC1XR10gUmVzb3VyY2Ugb3duZXIgaW5pdGlhdGVkIE9BdXRoIGRlbGVnYXRpb24NCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCkhpIEV2ZSwgDQoNClRoYW5rcyBmb3IgcG9pbnRlcnMuLiBJ J3ZlIGJlZW4gZm9sbG93aW5nIHRoZSB3b3JrIGRvbmUgaW4gVU1BLi4gU3VyZS4uIA0Kd2lsbCBq b2luIHRoZSB3ZWJpbmFyLi4uIA0KDQpCVFcgLi4gSSBhbSBub3QgcXVpdGUgc3VyZSBVTUEgYWRk cmVzc2VzIG15IHVzZSBjYXNlLiBFdmVuIGluIHRoZSBjYXNlIG9mIA0KVU1BIGl0J3MgY2xpZW50 IGluaXRpYXRlZCBvciByZXF1ZXN0b3IgaW5pdGlhdGVkLi4uIA0KDQpQbGVhc2UgY29ycmVjdCBt ZSBpZiBJIGFtIHdyb25nLi4uIGJ1dCBpbiBPQXV0aCBzcGVjaWZpY2F0aW9uIHRoZXJlIGlzIG5v IA0KcmVzdHJpY3Rpb25zIHRvIGlkZW50aWZ5IHRoZSAnY2xpZW50JyBhcyBhIHBlcnNvbiwgb3Jn YW5pemF0aW9uIG9yIGFzIGhpbSANCnNlbGYuLiANCg0KSW4gbXkgdmlldyAtIHRoaXMgaXMgYW4g ZXh0ZW5kZWQgZ3JhbnQgdHlwZS4ud2hpY2ggaGFzIHR3byBwaGFzZXMuLiANCg0KMS4gUmVzb3Vy Y2Ugb3duZXIgZ3JhbnRzIGFjY2VzcyB0byBhIHNlbGVjdGVkIGEgQ2xpZW50IA0KMi4gQ2xpZW50 IHJlcXVlc3RzIHRoZSBhbHJlYWR5IGF2YWlsYWJsZSBhY2Nlc3MgdG9rZW4gZm9yIGhpbSBmcm9t IHRoZSANCkF1dGhvcml6YXRpb24gU2VydmVyLltqdXN0IGxpa2UgcGFzc2luZyB0aGUgcmVmcmVz aF90b2tlbl0gDQoNCldEWVQgPyANCg0KVGhhbmtzICYgcmVnYXJkcywgDQotUHJhYmF0aCANCg0K T24gU3VuLCBPY3QgNywgMjAxMiBhdCAxMTowNSBBTSwgRXZlIE1hbGVyIDxldmVAeG1sZ3JybC5j b20+IHdyb3RlOiANCkhpIFByYWJhdGgsDQoNCkFzIGZhciBhcyBJIGtub3csIE9BdXRoIGl0c2Vs ZiBnZW5lcmFsbHkgaXNuJ3QgdXNlZCB0byBsZXQgb25lIGh1bWFuIA0KcmVzb3VyY2Ugb3duZXIg ZGVsZWdhdGUgYWNjZXNzIHRvIGEgZGlmZmVyZW50IGh1bWFuIHJlc291cmNlIG93bmVyLiANCkhv d2V2ZXIsIFVNQSAod2hpY2ggbGV2ZXJhZ2VzIE9BdXRoKSBkb2VzIHN0cml2ZSB0byBzb2x2ZSBl eGFjdGx5IHRoaXMgdXNlIA0KY2FzZSwgYW1vbmcgb3RoZXIgc2ltaWxhciBvbmVzOyB3ZSBjYWxs IHRoaXMgb25lICJwZXJzb24tdG8tcGVyc29uIA0Kc2hhcmluZyIsIGFuZCB5b3UgY2FuIHJlYWQg bW9yZSBhYm91dCBpdCBoZXJlOiANCmh0dHA6Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91 bWEvZHJhZnQtdW1hLXRydXN0Lmh0bWwjYW5jaG9yMQ0KDQpUaGUgVU1BIGZsb3cgYXQgcnVuIHRp bWUgc3RpbGwgZW5kcyB1cCBiZWluZyBlZmZlY3RpdmVseSANCiJjbGllbnQtaW5pdGlhdGVkIiAo d2Ugd291bGQgc2F5IHJlcXVlc3RpbmctcGFydHktaW5pdGlhdGVkLCB1c2luZyBhIA0KcmVxdWVz dGVyIGFwcCkgYmVjYXVzZSB0aGUgb3JpZ2luYWwgcmVzb3VyY2Ugb3duZXIgKHdlIGNhbGwgaXQg YW4gDQphdXRob3JpemluZyBwYXJ0eSkgaXMgbm8gbG9uZ2VyIGFyb3VuZCBieSB0aGVuLiBUaGUg YXV0aHogcGFydHkgd291bGQgc2V0IA0KdXAgcG9saWNpZXMgYXQgc29tZSBwb2ludCBiZWZvcmUg Z29pbmcgb24gdmFjYXRpb24sIGFuZCB0aGVzZSBwb2xpY2VzIA0Kd291bGQgZW5hYmxlIHRoZSBy ZXF1ZXN0aW5nIHBhcnR5IHRvICJxdWFsaWZ5IGluIiBmb3IgYWNjZXNzIGF0IHJ1biB0aW1lLCAN CmJ5IHN1cHBseWluZyBpZGVudGl0eSBjbGFpbXMgdGhhdCBnZXQgdXNlZCBpbiBhbiBhdXRob3Jp emF0aW9uIGNoZWNrIGJ5IA0KdGhlIGF1dGh6IHNlcnZlciAoYXV0aHogbWFuYWdlcikuDQoNCldl J2xsIGJlIHdhbGtpbmcgdGhyb3VnaCBVTUEgZmxvd3MgYW5kIGRlbW9pbmcgYW4gZXh0ZW5zaXZl IHVzZSBjYXNlIGF0IGEgDQp3ZWJpbmFyIG9uIFdlZCwgT2N0IDE3LiBNb3JlIGluZm8gaXMgaGVy ZTogaHR0cDovL3Rpbnl1cmwuY29tL3VtYXdnDQoNCkhvcGUgdGhpcyBoZWxwcywNCg0KICAgICAg RXZlIA0KDQpPbiA2IE9jdCAyMDEyLCBhdCAxMDoyOSBBTSwgUHJhYmF0aCBTaXJpd2FyZGVuYSA8 cHJhYmF0aEB3c28yLmNvbT4gd3JvdGU6DQoNCj4gSGkgZm9sa3MsDQo+DQo+IEkgd291bGQgbGlr ZSB0byBrbm93IHlvdXIgdGhvdWdodHMgb24gdGhlICRzdWJqZWN0Li4NCj4NCj4gRm9yIG1lIGl0 IGxvb2tzIGxpa2UgYSBjb25jcmV0ZSB1c2UgY2FzZSB3aGVyZSBPQXV0aCBjb25jZXB0dWFsbHkg ZG9lcw0KPiBhZGRyZXNzIC0gYnV0IHByb3RvY29sIGRvZXMgbm90IHdlbGwgZGVmaW5lZC4uDQo+ DQo+IFBsZWFzZSBmaW5kIFsxXSBmb3IgZnVydGhlciBkZXRhaWxzLi4uDQo+DQo+IFsxXTogDQpo dHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20vMjAxMi8xMC9hdGlvbndoYXQtb2F1dGgtbGFja3Mt cmVzb3VyY2Utb3duZXIuaHRtbA0KDQo+DQo+IC0tDQo+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+IFBy YWJhdGgNCj4NCj4gTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyDQo+DQo+IGh0dHA6Ly9ibG9nLmZh Y2lsZWxvZ2luLmNvbQ0KPiBodHRwOi8vUmFtcGFydEZBUS5jb20gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0K PiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQoNCg0KRXZlIE1hbGVyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0 dHA6Ly93d3cueG1sZ3JybC5jb20vYmxvZw0KKzEgNDI1IDM0NSA2NzU2ICAgICAgICAgICAgICAg ICAgICAgICAgIGh0dHA6Ly93d3cudHdpdHRlci5jb20veG1sZ3JybA0KDQoNCg0KDQoNCi0tIA0K VGhhbmtzICYgUmVnYXJkcywNClByYWJhdGggDQoNCk1vYmlsZSA6ICs5NCA3MSA4MDkgNjczMiAN Cg0KaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tDQpodHRwOi8vUmFtcGFydEZBUS5jb20gDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQoNCg0KDQotLSANClRoYW5rcyAmIFJlZ2FyZHMsDQpQcmFiYXRoIA0K DQpNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQoNCmh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNv bQ0KaHR0cDovL1JhbXBhcnRGQVEuY29tIA0KDQoNCg0KLS0gDQpUaGFua3MgJiBSZWdhcmRzLA0K UHJhYmF0aCANCg0KTW9iaWxlIDogKzk0IDcxIDgwOSA2NzMyIA0KDQpodHRwOi8vYmxvZy5mYWNp bGVsb2dpbi5jb20NCmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbSANCg0KDQoNCg0KLS0gDQpUaGFua3Mg JiBSZWdhcmRzLA0KUHJhYmF0aA0KDQpNb2JpbGUgOiArOTQgNzEgODA5IDY3MzIgDQoNCmh0dHA6 Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbQ0KaHR0cDovL1JhbXBhcnRGQVEuY29tDQoNCg0K --=_alternative 000A23FE48257A93_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6xQcmFiYXRoPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlByYWJhdGggU2ly aXdhcmRlbmEgJmx0O3ByYWJhdGhAd3NvMi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMTAtMDkgMjA6MzU8L2ZvbnQ+DQo8dGQgd2lk dGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+emhvdS5zdWppbmdAenRl LmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+RXZlIE1hbGVyICZsdDtldmVAeG1sZ3JybC5jb20m Z3Q7LCBvYXV0aEBpZXRmLm9yZywNCm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlJlOiBSZTogUmU6IFJlOiBbT0FVVEgtV0ddIFJlc291cmNlDQpvd25lciBpbml0aWF0 ZWQgT0F1dGggZGVsZWdhdGlvbjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPk9uIE1vbiwgT2N0IDgsIDIwMTIgYXQgNjoyNCBQ TSwgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIHRhcmdl dD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhv dS5zdWppbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt c2VyaWYiPjxicj4NCkhpo6wgUHJhYmF0aCA8YnI+DQogJm5ic3A7PGJyPg0KICZuYnNwO015IHF1 ZXN0aW9uIGlzIHNpbmNlIGNsaWVudC1pZCBpcyBwdWJsaWMsIHRoZW4gaXQgaXMgYSB3YXN0ZSB0 bw0KZ2V0IGl0IGJ5IGdyYW50aW5nIGFuIGFjY2Vzcy10b2tlbi4gPGJyPg0KICZuYnNwO0FuZCBp biBzdGVwIDIuJnF1b3Q7UmVzb3VyY2UgT3duZXIgZ3JhbnRzIGFjY2VzcyB0byBhIHNlbGVjdGVk IENsaWVudCZxdW90OywNClJPICZuYnNwO2xvZ2lucyBpbiB0byBzZWxlY3QgY2xpZW50cyB0byBi ZSBkZWxlZ2F0ZWQsIDxicj4NCiBhbmQgUlMgcmVkaXJlY3RzIFJPIHRvIEFTIHRvIGdyYW50IGFj Y2VzcyB0b2tlbiB0byBjbGllbnQsIHRvIG15IHVuZGVyc3RhbmRpbmcsDQppbiB0aGlzIHByb2Nl c3MgUk8gbmVlZHMgdG8gYXV0aGVudGljYXRlIHRvIFJTIGFuZCB0aGVuIGF1dGhlbnRpY2F0ZSA8 YnI+DQp0byBBUywgaXQgaXMgYSBiaXQgY29tcGxpY2F0ZWQuIDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+SW4gZmFjdCBJIGRpZCBub3Qgd2FudCB0byBk aXN0dXJiIG5vcm1hbA0KT0F1dGggZmxvdy4uIEJUVyB5ZXMuLiBpdCBhZGRzIHNvbWUgb3Zlcmhl YWQuLiBTbyAtIEkgd291bGQgbGlrZSB0byBtb2RpZnkNCml0IC0gd2hlcmUgdGhlIFJlc291cmNl IFNlcnZlciBzZW5kcyB0aGUgcmVzb3VyY2Vfb3duZXJfaW5pdGlhdGVkIGFzIHRoZQ0Kc2NvcGUg LSBhbmQgYmFzZWQgb24gdGhlIHNjb3BlIEFTIHJldHVybnMgYmFjayBjbGllbnRfaWQgdG9nZXRo ZXIgd2l0aA0KdGhlIGFjY2Vzc190b2tlbiBpdCBzZWxmLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj48YnI+DQogJm5ic3A7SSB3b25kZXIgaWYgdGhlIGZvbGxvd2luZyB0d28g cHJvY2Vzc2VzIGNvdWxkIHNhdGlzZnkgeW91ciBjYXNlOg0KPGJyPg0KPGJyPg0KUHJvY2VzcyBP bmU6IDxicj4NCjEuIFJlc291cmNlIE93bmVyIHJlZ2lzdGVycyB0by1iZS1kZWxlZ2F0ZWQgY2xp ZW50cyBhbmQgY29ycmVzcG9uZGluZyBSU3MNCmF0IEFTLCBpLmUuLCBhIGxvbmcgdGVybSBkZWxl Z2F0aW9uIGNvbnRyYWN0IGlzIHN0b3JlZCBhdCBBUyA8YnI+DQo8YnI+DQoyLiBXaGVuIFJlc291 cmNlIE93bmVyIHJlcXVlc3RzIENsaWVudCB0byBhY2Nlc3MgaXRzIHJlc291cmNlIGF0IFJTLCBD bGllbnQNCmlzIGRpcmVjdGVkIGJ5IFJTIHRvIEFTIHRvIG9idGFpbiBhY2Nlc3MtdG9rZW4gPGJy Pg0KMy4gQ2xpZW50IGFjY2Vzc2VzIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2Ugb24gYmVoYWxmIG9m IHRoZSBSZXNvdXJjZSBPd25lci4NCjxicj4NCjxicj4NClByb2Nlc3MgVHdvOiA8YnI+DQoxLiBS TyByZWdpc3RlcnMgdG8tYmUtZGVsZWdhdGVkIGNsaWVudHMgYXQgUlMsIGkuZS4sIGEgbG9uZyB0 ZXJtIGRlbGVnYXRpb24NCmNvbnRyYWN0IGlzIHN0b3JlZCBhdCBSUyA8YnI+DQoyLiBXaGVuIFJl c291cmNlIE93bmVyIHJlcXVlc3RzIENsaWVudCB0byBhY2Nlc3MgaXRzIHJlc291cmNlIGF0IFJT LCBDbGllbnQNCmlzIGRpcmVjdGVkIGJ5IFJTIHRvIEFTIHRvIG9idGFpbiBhY2Nlc3MtdG9rZW4s QVMgbWF5IHJlcXVlc3QgUk8gdG8gYXV0aGVudGljYXRlDQphbmQgY29uZmlybSB0aGUgPGJyPg0K YWNjZXNzLXRva2VuIHJlcXVlc3QgPGJyPg0KMy4gQ2xpZW50IGFjY2Vzc2VzIHRoZSBwcm90ZWN0 ZWQgcmVzb3VyY2Ugb24gYmVoYWxmIG9mIHRoZSBSZXNvdXJjZSBPd25lci4NCiZuYnNwOyA8YnI+ DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoZXJl IG5lZWRzIHRvIGJlIGFuIHN0ZXAgdG8gZmFjaWxpdGF0ZQ0KY2xpZW50IHJlZ2lzdHJhdGlvbi48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+Q2xp ZW50IGNvdWxkIGhhdmUgcmVnaXN0ZXJlZA0KYXQgQVMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlJPIGp1c3Qgc2VsZWN0IGNsaWVudHMgZnJv bQ0KYXZhaWxhYmxlIGNsaWVudHMgbGlzdC4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPlRoaXMgZmFjaWxpdGF0aW5nIHN0ZXAgc3RpbGwNCm5l ZWRlZD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRo YW5rcyAmYW1wOyByZWdhcmRzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+LVByYWJhdGg8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K PC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTM3JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+UHJhYmF0aCBTaXJpd2Fy ZGVuYSAmbHQ7PC9iPjwvZm9udD48YSBocmVmPW1haWx0bzpwcmFiYXRoQHdzbzIuY29tIHRhcmdl dD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PHU+ cHJhYmF0aEB3c28yLmNvbTwvdT48L2I+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDEyLTEwLTA4IDEyOjAwPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl cmlmIj4NCjwvZm9udD4NCjx0ZCB3aWR0aD02MiU+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTglPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTkx JT48YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZv bnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhvdS5zdWppbmdAenRl LmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+RXZlIE1hbGVyICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZXZl QHhtbGdycmwuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+PHU+ZXZlQHhtbGdycmwuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPiZndDssDQo8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86b2F1dGhAaWV0 Zi5vcmcgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48dT5vYXV0aEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj4sDQo8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJp ZiI+PHU+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFJlOiBSZTogW09BVVRI LVdHXSBSZXNvdXJjZSBvd25lcg0KaW5pdGlhdGVkIE9BdXRoIGRlbGVnYXRpb248L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQgd2lkdGg9NTAlPg0KPHRkIHdpZHRoPTUwJT48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48Zm9udCBz aXplPTMgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+PGJyPg0KSGkgWmhvdSwgPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNv bG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPjxicj4NCkV2ZW4gdGhvdWdoIGNsaWVudF9pZCBpcyBw dWJsaWMgdGhhdCBuZWVkcyB0byBiZSBwYXNzZWQgZnJvbSB0aGUgQXV0aG9yaXphdGlvbg0KU2Vy dmVyIHRvIHRoZSBSZXNvdXJjZSBTZXJ2ZXIuIFRoaXMgZG9lcyBub3QgaGFwcGVuIGluIHRoZSBu b3JtYWwgT0F1dGgNCmZsb3cuIEl0IG9ubHkgcmV0dXJucyBiYWNrIHRoZSBhY2Nlc3NfdG9rZW4u PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9u dCBzaXplPTMgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+PGJyPg0KUGxlYXNlIGxldCBtZSBr bm93IGlmIHlvdSBuZWVkIGFueSBmdXJ0aGVyIGNsYXJpZmljYXRpb25zLi4uPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTMgY29s b3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+PGJyPg0KVGhhbmtzICZhbXA7IHJlZ2FyZHMsPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MyBjb2xv cj0jMjIyMjIyIGZhY2U9IkFyaWFsIj48YnI+DQotUHJhYmF0aDwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCk9uIFN1biwgT2N0IDcsIDIwMTIgYXQgODow MyBQTSwgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIHRh cmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ emhvdS5zdWppbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTogPGJyPg0KPGJyPg0KSGksPC9mb250Pjxmb250IHNpemU9 MyBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFsIj5QcmFiYXRoPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjxicj4NCkkgaGF2ZSByZWFkIHlvdXIgcHJvcG9zYWws IGFuZCBoYXZlIHNvbWUgcXVlc3Rpb25zOiA8YnI+DQo8YnI+DQogd2h5IFJTIG5lZWRzIHRvIGdl dCBhY2Nlc3MgdG9rZW4gaW4gY2xpZW50IHJlZ2lzdGVyIHN0YWdlOyA8YnI+DQogYW5kIHdoeSBS UyBuZWVkcyB0byBnZXQgY2xpZW50LWlkIGZyb20gQVMgYnkgZXhjaGFuZ2luZyBhY2Nlc3MgdG9r ZW4gKGlzbid0DQpjbGllbnQtaWQgcHVibGljPykgPGJyPg0KIDxicj4NCjwvZm9udD4NCjxwPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNyU+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlByYWJhdGggU2lyaXdhcmRlbmEgJmx0OzwvYj48 L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cHJhYmF0aEB3c28yLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjxiPjx1PnByYWJhdGhAd3NvMi5j b208L3U+PC9iPjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPiZn dDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0x MC0wOCAwOTo1MDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+ DQo8dGQgd2lkdGg9NjIlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZCB3aWR0aD04JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MSU+PGEgaHJlZj1tYWls dG86emhvdS5zdWppbmdAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xv cj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPkV2ZSBNYWxlciAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmV2ZUB4bWxncnJsLmNvbSB0 YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1 PmV2ZUB4bWxncnJsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4mZ3Q7LA0KPC9mb250PjxhIGhyZWY9bWFpbHRvOm9hdXRoQGlldGYub3JnIHRhcmdldD1f Ymxhbms+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+b2F1dGhA aWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+LA0K PC9mb250PjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2Js YW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBSZTogW09BVVRILVdHXSBSZXNvdXJjZSBvd25l ciBpbml0aWF0ZWQNCk9BdXRoIGRlbGVnYXRpb248L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFs Ij48YnI+DQo8YnI+DQpIaSBaaG91LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+PGJyPg0K PGJyPg0KTmljZSB0byBzZWUgc29tZSBjb21tb24gaW50ZXJlc3Qgb24gdGhpcy4gU3VyZSBJIHdp bGwgZ28gdGhyb3VnaCB5b3VyIHByb3Bvc2FsLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwi Pjxicj4NCjxicj4NClBsZWFzZSBmaW5kIG15IHByb3Bvc2FsIGhlcmUgWzFdLiBJJ3ZlIGFkZGVk IHRoZXJlIHRoZSBjb21wbGV0ZSB0b2tlbiBmbG93LA0KaW50cm9kdWNpbmcgYSBuZXcgZ3JhbnQg dHlwZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NClsxXTogPC9mb250 PjxhIGhyZWY9Imh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbS8yMDEyLzEwL3Byb3Bvc2FsLXJl c291cmNlLW93bmVyLWluaXRpYXRlZC5odG1sIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBj b2xvcj0jMTE1NWNjIGZhY2U9IkFyaWFsIj48dT5odHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb20v MjAxMi8xMC9wcm9wb3NhbC1yZXNvdXJjZS1vd25lci1pbml0aWF0ZWQuaHRtbDwvdT48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTMg Y29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+PGJyPg0KPGJyPg0KVGhhbmtzICZhbXA7IHJlZ2Fy ZHMsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNp emU9MyBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFsIj48YnI+DQotUHJhYmF0aDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjxicj4NCk9uIFN1biwgT2N0IDcsIDIw MTIgYXQgNjoyNCBQTSwgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUu Y29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1z ZXJpZiI+PHU+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTogPGJyPg0KPGJyPg0KSGksICZuYnNwO1By YWJhIDxicj4NCjxicj4NCkkgYW0gYWxzbyB0aGlua2luZyBvbiB0aGlzIHN1YmplY3QsIGFuZCBw dWJsaXNoZWQgYSBkcmFmdCBvbiBpdC4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2lkL2RyYWZ0LXpob3Utb2F1dGgtb3duZXItYXV0aC0wMC50eHQiIHRhcmdldD1f Ymxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDov L3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXpob3Utb2F1dGgtb3duZXItYXV0aC0wMC50eHQ8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQpJJ2QgbGlr ZSB0byBoYXZlIHlvdXIgb3Bpbmlvbi4gPGJyPg0KPC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9 MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTQyJT48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+PGI+UHJhYmF0aCBTaXJpd2FyZGVuYSAmbHQ7PC9iPjwvZm9udD48YSBocmVm PW1haWx0bzpwcmFiYXRoQHdzbzIuY29tIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0xIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PGI+PHU+cHJhYmF0aEB3c28yLmNvbTwvdT48L2I+PC9m b250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Jmd0OzwvYj4NCjxicj4N CreivP7IyzogJm5ic3A7PC9mb250PjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1Pm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMg ZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+MjAxMi0xMC0wOCAwODowODwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NTclPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD05JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0aD05MCU+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkV2ZSBNYWxlciAmbHQ7PC9mb250PjxhIGhy ZWY9bWFpbHRvOmV2ZUB4bWxncnJsLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xv cj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PmV2ZUB4bWxncnJsLmNvbTwvdT48L2ZvbnQ+PC9h Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7PC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rp dj4NCjx0ZD48YSBocmVmPW1haWx0bzpvYXV0aEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pm9hdXRoQGlldGYub3JnPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5SZTogW09BVVRILVdHXSBSZXNvdXJjZSBvd25lciBpbml0aWF0ZWQNCk9BdXRoIGRl bGVnYXRpb248L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KSGkgRXZlLCA8YnI+DQo8YnI+DQpUaGFua3MgZm9yIHBvaW50ZXJzLi4g SSd2ZSBiZWVuIGZvbGxvd2luZyB0aGUgd29yayBkb25lIGluIFVNQS4uIFN1cmUuLg0Kd2lsbCBq b2luIHRoZSB3ZWJpbmFyLi4uIDxicj4NCjxicj4NCkJUVyAuLiBJIGFtIG5vdCBxdWl0ZSBzdXJl IFVNQSBhZGRyZXNzZXMgbXkgdXNlIGNhc2UuIEV2ZW4gaW4gdGhlIGNhc2UNCm9mIFVNQSBpdCdz IGNsaWVudCBpbml0aWF0ZWQgb3IgcmVxdWVzdG9yIGluaXRpYXRlZC4uLiA8YnI+DQo8YnI+DQpQ bGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLi4uIGJ1dCBpbiBPQXV0aCBzcGVjaWZpY2F0 aW9uIHRoZXJlIGlzDQpubyByZXN0cmljdGlvbnMgdG8gaWRlbnRpZnkgdGhlICdjbGllbnQnIGFz IGEgcGVyc29uLCBvcmdhbml6YXRpb24gb3IgYXMNCmhpbSBzZWxmLi4gJm5ic3A7PGJyPg0KPGJy Pg0KSW4gbXkgdmlldyAtIHRoaXMgaXMgYW4gZXh0ZW5kZWQgZ3JhbnQgdHlwZS4ud2hpY2ggaGFz IHR3byBwaGFzZXMuLiA8YnI+DQo8YnI+DQoxLiBSZXNvdXJjZSBvd25lciBncmFudHMgYWNjZXNz IHRvIGEgc2VsZWN0ZWQgYSBDbGllbnQgPGJyPg0KMi4gQ2xpZW50IHJlcXVlc3RzIHRoZSBhbHJl YWR5IGF2YWlsYWJsZSBhY2Nlc3MgdG9rZW4gZm9yIGhpbSBmcm9tIHRoZQ0KQXV0aG9yaXphdGlv biBTZXJ2ZXIuW2p1c3QgbGlrZSBwYXNzaW5nIHRoZSByZWZyZXNoX3Rva2VuXSA8YnI+DQo8YnI+ DQpXRFlUID8gPGJyPg0KPGJyPg0KVGhhbmtzICZhbXA7IHJlZ2FyZHMsIDxicj4NCi1QcmFiYXRo ICZuYnNwOzxicj4NCjxicj4NCk9uIFN1biwgT2N0IDcsIDIwMTIgYXQgMTE6MDUgQU0sIEV2ZSBN YWxlciAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOmV2ZUB4bWxncnJsLmNvbSB0YXJnZXQ9X2Js YW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PmV2ZUB4bWxn cnJsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7 DQp3cm90ZTogPGJyPg0KSGkgUHJhYmF0aCw8YnI+DQo8YnI+DQpBcyBmYXIgYXMgSSBrbm93LCBP QXV0aCBpdHNlbGYgZ2VuZXJhbGx5IGlzbid0IHVzZWQgdG8gbGV0IG9uZSBodW1hbiByZXNvdXJj ZQ0Kb3duZXIgZGVsZWdhdGUgYWNjZXNzIHRvIGEgZGlmZmVyZW50IGh1bWFuIHJlc291cmNlIG93 bmVyLiBIb3dldmVyLCBVTUENCih3aGljaCBsZXZlcmFnZXMgT0F1dGgpIGRvZXMgc3RyaXZlIHRv IHNvbHZlIGV4YWN0bHkgdGhpcyB1c2UgY2FzZSwgYW1vbmcNCm90aGVyIHNpbWlsYXIgb25lczsg d2UgY2FsbCB0aGlzIG9uZSAmcXVvdDtwZXJzb24tdG8tcGVyc29uIHNoYXJpbmcmcXVvdDssDQph bmQgeW91IGNhbiByZWFkIG1vcmUgYWJvdXQgaXQgaGVyZTogPC9mb250PjxhIGhyZWY9Imh0dHA6 Ly9kb2NzLmthbnRhcmFpbml0aWF0aXZlLm9yZy91bWEvZHJhZnQtdW1hLXRydXN0Lmh0bWwjYW5j aG9yMSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNl cmlmIj48dT5odHRwOi8vZG9jcy5rYW50YXJhaW5pdGlhdGl2ZS5vcmcvdW1hL2RyYWZ0LXVtYS10 cnVzdC5odG1sI2FuY2hvcjE8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KPGJyPg0KVGhlIFVNQSBmbG93IGF0IHJ1biB0aW1lIHN0aWxsIGVuZHMgdXAg YmVpbmcgZWZmZWN0aXZlbHkgJnF1b3Q7Y2xpZW50LWluaXRpYXRlZCZxdW90Ow0KKHdlIHdvdWxk IHNheSByZXF1ZXN0aW5nLXBhcnR5LWluaXRpYXRlZCwgdXNpbmcgYSByZXF1ZXN0ZXIgYXBwKSBi ZWNhdXNlDQp0aGUgb3JpZ2luYWwgcmVzb3VyY2Ugb3duZXIgKHdlIGNhbGwgaXQgYW4gYXV0aG9y aXppbmcgcGFydHkpIGlzIG5vIGxvbmdlcg0KYXJvdW5kIGJ5IHRoZW4uIFRoZSBhdXRoeiBwYXJ0 eSB3b3VsZCBzZXQgdXAgcG9saWNpZXMgYXQgc29tZSBwb2ludCBiZWZvcmUNCmdvaW5nIG9uIHZh Y2F0aW9uLCBhbmQgdGhlc2UgcG9saWNlcyB3b3VsZCBlbmFibGUgdGhlIHJlcXVlc3RpbmcgcGFy dHkNCnRvICZxdW90O3F1YWxpZnkgaW4mcXVvdDsgZm9yIGFjY2VzcyBhdCBydW4gdGltZSwgYnkg c3VwcGx5aW5nIGlkZW50aXR5DQpjbGFpbXMgdGhhdCBnZXQgdXNlZCBpbiBhbiBhdXRob3JpemF0 aW9uIGNoZWNrIGJ5IHRoZSBhdXRoeiBzZXJ2ZXIgKGF1dGh6DQptYW5hZ2VyKS48YnI+DQo8YnI+ DQpXZSdsbCBiZSB3YWxraW5nIHRocm91Z2ggVU1BIGZsb3dzIGFuZCBkZW1vaW5nIGFuIGV4dGVu c2l2ZSB1c2UgY2FzZSBhdA0KYSB3ZWJpbmFyIG9uIFdlZCwgT2N0IDE3LiBNb3JlIGluZm8gaXMg aGVyZTogPC9mb250PjxhIGhyZWY9aHR0cDovL3Rpbnl1cmwuY29tL3VtYXdnIHRhcmdldD1fYmxh bms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL3Rp bnl1cmwuY29tL3VtYXdnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjxicj4NCkhvcGUgdGhpcyBoZWxwcyw8YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDtFdmUgPGJyPg0KPGJyPg0KT24gNiBPY3QgMjAxMiwgYXQgMTA6MjkgQU0sIFByYWJh dGggU2lyaXdhcmRlbmEgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzpwcmFiYXRoQHdzbzIuY29t IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+ PHU+cHJhYmF0aEB3c28yLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4mZ3Q7DQp3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEhpIGZvbGtzLDxicj4NCiZndDs8 YnI+DQomZ3Q7IEkgd291bGQgbGlrZSB0byBrbm93IHlvdXIgdGhvdWdodHMgb24gdGhlICRzdWJq ZWN0Li48YnI+DQomZ3Q7PGJyPg0KJmd0OyBGb3IgbWUgaXQgbG9va3MgbGlrZSBhIGNvbmNyZXRl IHVzZSBjYXNlIHdoZXJlIE9BdXRoIGNvbmNlcHR1YWxseQ0KZG9lczxicj4NCiZndDsgYWRkcmVz cyAtIGJ1dCBwcm90b2NvbCBkb2VzIG5vdCB3ZWxsIGRlZmluZWQuLjxicj4NCiZndDs8YnI+DQom Z3Q7IFBsZWFzZSBmaW5kIFsxXSBmb3IgZnVydGhlciBkZXRhaWxzLi4uPGJyPg0KJmd0Ozxicj4N CiZndDsgWzFdOiA8L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tLzIw MTIvMTAvYXRpb253aGF0LW9hdXRoLWxhY2tzLXJlc291cmNlLW93bmVyLmh0bWwiIHRhcmdldD1f Ymxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDov L2Jsb2cuZmFjaWxlbG9naW4uY29tLzIwMTIvMTAvYXRpb253aGF0LW9hdXRoLWxhY2tzLXJlc291 cmNlLW93bmVyLmh0bWw8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IFRoYW5rcyAmYW1wOyBSZWdhcmRz LDxicj4NCiZndDsgUHJhYmF0aDxicj4NCiZndDs8YnI+DQomZ3Q7IE1vYmlsZSA6IDwvZm9udD48 YSBocmVmPXRlbDolMkI5NCUyMDcxJTIwODA5JTIwNjczMiB0YXJnZXQ9X2JsYW5rPjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pis5NA0KNzEgODA5IDY3MzI8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KJmd0Ozxicj4N CiZndDsgPC9mb250PjxhIGhyZWY9aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tLyB0YXJnZXQ9 X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6 Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQomZ3Q7IDwvZm9udD48YSBocmVmPWh0dHA6Ly9yYW1wYXJ0ZmFxLmNv bS8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48dT5odHRwOi8vUmFtcGFydEZBUS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7 IDwvZm9udD48YSBocmVmPW1haWx0bzpPQXV0aEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjxmb250 IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pk9BdXRoQGlldGYub3JnPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiZndDsgPC9m b250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCB0 YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1 Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KRXZlIE1h bGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PC9mb250PjxhIGhyZWY9aHR0cDovL3d3dy54bWxncnJsLmNvbS9ibG9nIHRhcmdl dD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0 cDovL3d3dy54bWxncnJsLmNvbS9ibG9nPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPXRlbDol MkIxJTIwNDI1JTIwMzQ1JTIwNjc1NiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1PisxDQo0MjUgMzQ1IDY3NTY8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8L2ZvbnQ+PGEgaHJlZj1odHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmwgdGFyZ2V0PV9i bGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8v d3d3LnR3aXR0ZXIuY29tL3htbGdycmw8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0gPGJyPg0K VGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KUHJhYmF0aCA8YnI+DQo8YnI+DQpNb2JpbGUgOiA8 L2ZvbnQ+PGEgaHJlZj10ZWw6JTJCOTQlMjA3MSUyMDgwOSUyMDY3MzIgdGFyZ2V0PV9ibGFuaz48 Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT4rOTQNCjcxIDgwOSA2 NzMyPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPGJyPg0K PC91PjwvZm9udD48YSBocmVmPWh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbS8gdGFyZ2V0PV9i bGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8v YmxvZy5mYWNpbGVsb2dpbi5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cDovL3Jh bXBhcnRmYXEuY29tLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9 InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0zPjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPW1haWx0bzpPQXV0aEBpZXRm Lm9yZyB0YXJnZXQ9X2JsYW5rPjx0dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5PQXV0aEBp ZXRmLm9yZzwvdT48L2ZvbnQ+PC90dD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0i c2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGggdGFyZ2V0PV9ibGFuaz48dHQ+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aDwvdT48L2ZvbnQ+PC90dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tIDxicj4NClRoYW5rcyAmYW1wOyBSZWdhcmRzLDxi cj4NClByYWJhdGggPGJyPg0KPGJyPg0KTW9iaWxlIDogPC9mb250PjxhIGhyZWY9dGVsOiUyQjk0 JTIwNzElMjA4MDklMjA2NzMyIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUg ZmFjZT0ic2Fucy1zZXJpZiI+PHU+Kzk0DQo3MSA4MDkgNjczMjwvdT48L2ZvbnQ+PC9hPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRw Oi8vYmxvZy5mYWNpbGVsb2dpbi5jb20vIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9y PWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cDovL2Jsb2cuZmFjaWxlbG9naW4uY29tPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHA6Ly9yYW1wYXJ0ZmFxLmNvbS8gdGFyZ2V0PV9i bGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8v UmFtcGFydEZBUS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPGJy Pg0KPGJyPg0KLS0gPGJyPg0KVGhhbmtzICZhbXA7IFJlZ2FyZHMsPGJyPg0KUHJhYmF0aCA8YnI+ DQo8YnI+DQpNb2JpbGUgOiA8L2ZvbnQ+PGEgaHJlZj10ZWw6JTJCOTQlMjA3MSUyMDgwOSUyMDY3 MzIgdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48dT4rOTQNCjcxIDgwOSA2NzMyPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9InNh bnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJp ZiI+PHU+PGJyPg0KPGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHA6Ly9ibG9nLmZhY2lsZWxv Z2luLmNvbS8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48dT5odHRwOi8vYmxvZy5mYWNpbGVsb2dpbi5jb208L3U+PC9mb250PjwvYT48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250 PjxhIGhyZWY9aHR0cDovL3JhbXBhcnRmYXEuY29tLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbTwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9u dD4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi0tIDxicj4NClRoYW5rcyAmYW1w OyBSZWdhcmRzLDxicj4NClByYWJhdGg8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPk1vYmlsZSA6ICs5NCA3MSA4MDkgNjczMiA8YnI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+PGJyPg0KPC91PjwvZm9u dD48YSBocmVmPWh0dHA6Ly9ibG9nLmZhY2lsZWxvZ2luLmNvbS8gdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vYmxvZy5mYWNp bGVsb2dpbi5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJz YW5zLXNlcmlmIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cDovL3JhbXBhcnRmYXEu Y29tLyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy aWYiPjx1Pmh0dHA6Ly9SYW1wYXJ0RkFRLmNvbTwvdT48L2ZvbnQ+PC9hPg0KPGJyPg0KPGJyPg0K --=_alternative 000A23FE48257A93_=-- From torsten@lodderstedt.net Tue Oct 9 22:09:58 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AD021F86C9 for ; Tue, 9 Oct 2012 22:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+0+RsrcJcVT for ; Tue, 9 Oct 2012 22:09:56 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by ietfa.amsl.com (Postfix) with ESMTP id 76B1021F86CA for ; Tue, 9 Oct 2012 22:09:54 -0700 (PDT) Received: from [79.253.28.173] (helo=[192.168.71.108]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1TLoYJ-0002w7-9I; Wed, 10 Oct 2012 07:09:51 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> <5070654D.40007@lodderstedt.net> <97A330AD-C451-4472-B38C-EF59034EC810@oracle.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----97OXP89OOK5FCPJX6F6QYN0LLOH5F6" From: Torsten Lodderstedt Date: Wed, 10 Oct 2012 07:09:47 +0200 To: "Richer, Justin P." , "Zeltsan, Zachary (Zachary)" Message-ID: X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 05:09:58 -0000 ------97OXP89OOK5FCPJX6F6QYN0LLOH5F6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit +1 "Richer, Justin P." schrieb: >Good for me, AS LONG AS we make absolutely SURE that we leave plenty of >time for #8 on the agenda, to the point of cutting off and tabling >other discussions ahead of time. There are a lot of ancillary documents >in various states of use/neglect that shouldn't be left aside by the >WG, and this is a good venue for all of that. > > -- Justin > >On Oct 7, 2012, at 12:08 PM, Zeltsan, Zachary (Zachary) wrote: > >> +1 >> >> Zachary >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >Behalf Of Phil Hunt >> Sent: Saturday, October 06, 2012 2:54 PM >> To: Torsten Lodderstedt >> Cc: oauth@ietf.org WG >> Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting >> >> +1 >> >> Phil >> >> On 2012-10-06, at 10:07, Torsten Lodderstedt > wrote: >> >>> fine for me >>> >>> Am 05.10.2012 10:03, schrieb Hannes Tschofenig: >>>> Hi all, >>>> >>>> here is an agenda proposal for the Atlanta IETF meeting: >>>> (The indicated names are proposals.) >>>> >>>> ------ >>>> Agenda: >>>> >>>> 1. Status Update, Agenda Bashing (Chairs) >>>> 2. Token Revocation (Thorsten) >>>> 3. Assertions (Brian + Mike) >>>> 4. OAuth Use Cases (Zachary) >>>> 5. JWT (Mike) >>>> 6. Security (Phil) >>>> 7. Dynamic Client Registration (Thomas) >>>> 8. Roadmap >>>> ------ >>>> >>>> In the last item we would like to discuss the bigger picture of how >to get OAuth 2.0 deployment improved. There are at least 2 parts to >this, namely (a) what other specifications do we need to work on, and >(b) how do we improve interoperability. >>>> >>>> Let us know whether you think that this fits your needs. >>>> >>>> Ciao >>>> Hannes & Derek >>>> >>>> PS: I am hoping to see daft updates of the WG items soon. >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth ------97OXP89OOK5FCPJX6F6QYN0LLOH5F6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1



"Richer, Justin P." <jricher@mitre.org> schrieb:
Good for me, AS LONG AS we make absolutely SURE that we leave plenty of time for #8 on the agenda, to the point of cutting off and tabling other discussions ahead of time. There are a lot of ancillary documents in various states of use/neglect that shouldn't be left aside by the WG, and this is a good venue for all of that.

-- Justin

On Oct 7, 2012, at 12:08 PM, Zeltsan, Zachary (Zachary) wrote:

+1

Zachary

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Saturday, October 06, 2012 2:54 PM
To: Torsten Lodderstedt
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting

+1

Phil

On 2012-10-06, at 10:07, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

fine for me

Am 05.10.2012 10:03, schrieb Hannes Tschofenig:
Hi all,

here is an agenda proposal for the Atlanta IETF meeting:
(The indicated names are proposals.)

------
Agenda:

1. Status Update, Agenda Bashing (Chairs)
2. Token Revocation (Thorsten)
3. Assertions (Brian + Mike)
4. OAuth Use Cases (Zachary)
5. JWT (Mike)
6. Security (Phil)
7. Dynamic Client Registration (Thomas)
8. Roadmap
------

In the last item we would like to discuss the bigger picture of how to get OAuth 2.0 deployment improved. There are at least 2 parts to this, namely
  (a)
what other specifications do we need to work on, and (b) how do we improve interoperability.

Let us know whether you think that this fits your needs.

Ciao
Hannes & Derek

PS: I am hoping to see daft updates of the WG items soon.


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


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

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

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

------97OXP89OOK5FCPJX6F6QYN0LLOH5F6-- From hannes.tschofenig@gmx.net Wed Oct 10 01:53:03 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C3A21F86F5 for ; Wed, 10 Oct 2012 01:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r18s0vsjsPld for ; Wed, 10 Oct 2012 01:53:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5BDBA21F8585 for ; Wed, 10 Oct 2012 01:53:00 -0700 (PDT) Received: (qmail invoked by alias); 10 Oct 2012 08:52:59 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.216.191] by mail.gmx.net (mp072) with SMTP; 10 Oct 2012 10:52:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/V8dsIhurVLYF9bzgFJAtQKaxBEzv1whhWhvQlnX 3KzH/e219WM7Cf Message-ID: <50753768.5020900@gmx.net> Date: Wed, 10 Oct 2012 11:52:56 +0300 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Torsten Lodderstedt , "Richer, Justin P." References: <3772E566-803D-4EEF-B853-BEE405D0814E@gmx.net> <5070654D.40007@lodderstedt.net> <97A330AD-C451-4472-B38C-EF59034EC810@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 08:53:03 -0000 Hi Justin, Hi Torsten, We will take care of appropriate time management and agenda topics that have not seen enough presentation on the list will be postponed. In fact, I am concerned about the progress with the use cases document and the dynamic client registration work. I have notified the authors of my concerns privately already. Ciao Hannes On 10/10/2012 08:09 AM, Torsten Lodderstedt wrote: > +1 > > > > "Richer, Justin P." schrieb: > > Good for me, AS LONG AS we make absolutely SURE that we leave plenty of time for #8 on the agenda, to the point of cutting off and tabling other discussions ahead of time. There are a lot of ancillary documents in various states of use/neglect that shouldn't be left aside by the WG, and this is a good venue for all of that. > > -- Justin > > On Oct 7, 2012, at 12:08 PM, Zeltsan, Zachary (Zachary) wrote: > > +1 > > Zachary > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of Phil Hunt > Sent: Saturday, October 06, 2012 2:54 PM > To: Torsten Lodderstedt > Cc: oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Agenda for Atlanta Meeting > > +1 > > Phil > > On 2012-10-06, at 10:07, Torsten Lodderstedt > wrote: > > fine for me > > Am 05.10.2012 10:03, schrieb Hannes Tschofenig: > > Hi all, > > here is an agenda proposal for the Atlanta IETF meeting: > (The indicated names are proposals.) > > ------ > Agenda: > > 1. Status Update, Agenda Bashing (Chairs) > 2. Token Revocation (Thorsten) > 3. Assertions (Brian + Mike) > 4. OAuth Use Cases (Zachary) > 5. JWT (Mike) > 6. Security (Phil) > 7. Dynamic Client Registration (Thomas) > 8. Roadmap > ------ > > In the last item we would like to discuss the bigger > picture of how to get OAuth 2.0 deployment improved. > There are at least 2 parts to this, namely (a) what > other specifications do we need to work on, and (b) how > do we improve interoperability. > > Let us know whether you think that this fits your needs. > > Ciao > Hannes & Derek > > PS: I am hoping to see daft updates of the WG items soon. > > ------------------------------------------------------------------------ > > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------------------------------------------------ > > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > ------------------------------------------------------------------------ > > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > ------------------------------------------------------------------------ > > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From pmhsfelix@gmail.com Wed Oct 10 07:25:48 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593EF21F8782 for ; Wed, 10 Oct 2012 07:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDGQExP3ram0 for ; Wed, 10 Oct 2012 07:25:47 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 902C021F8758 for ; Wed, 10 Oct 2012 07:25:47 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so492444lam.31 for ; Wed, 10 Oct 2012 07:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OhZqggRrje2s7TkK282OQIhXMu86jIMPcStxSnS5WD0=; b=aaGCX0lTqtrUXh5EnzC71PZjQ+HMW3fqokGWQsFMKzZfUxxxF0ofG0wrk97Ys1cdiY sGWM4UAgfo56jpnTkZ8bMBkrLJNWzkO/VbnAr8pia/iCQZCznRNDU0RvDtm7fQF88NHM eYUCYrDPjIctoF5398nuvSbY7MrFX0Pw9CbKn8ajpyaNn1iK+VTdHMa7pjZ+Y8ueE4eu VIvy4yxg1vvAzNo7FlEvBIf0jGUDZRXE10GzOSSvN++tPRsUTGEKGHNmW2uZI34Rd0fM nU4oCNlaFYPvmwJNOO87QAspl900yf+IPOrcHSmuBl/wMNcLR35KKvimHjs+fMmKiusu hZAg== MIME-Version: 1.0 Received: by 10.112.102.198 with SMTP id fq6mr9396734lbb.135.1349879146489; Wed, 10 Oct 2012 07:25:46 -0700 (PDT) Received: by 10.112.61.5 with HTTP; Wed, 10 Oct 2012 07:25:46 -0700 (PDT) Date: Wed, 10 Oct 2012 15:25:46 +0100 Message-ID: From: Pedro Felix To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f46d0401fa290429ce04cbb53b5d Subject: [OAUTH-WG] Out-of-band code delivery and alternate redirect_uri schemes X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Oct 2012 14:25:48 -0000 --f46d0401fa290429ce04cbb53b5d Content-Type: text/plain; charset=ISO-8859-1 1) Out-of-band code transmission Currently Google OAuth2 implementation uses the special "urn:ietf:wg:oauth:2.0:oob" to signal the Authorization Endpoint to return an HTML page with the code, instead of a redirect. At first sight, it seems a good idea, however it isn't in the OAuth 2 RFC. a) What is the reason for the absence in the spec? b) Is there any security problem associated with this usage? 2) Alternative "redirect_uri" schemes I'm also considering the use of alternative schemes on the "redirect_uri". For instance, a client app could use the "mailto:" scheme to instruct the Authorization Endpoint to send the code via email. I know that a naive implementation can be subject to fixation attacks, however a) Weren't these scenarios considered by the working group? b) Is there a major security flaw on this usage? Thanks Pedro --f46d0401fa290429ce04cbb53b5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 1) Out-of-band code transmission

Currently Google OAuth2= implementation uses the special "urn:ietf:wg:oauth:2.0:oob" to s= ignal the Authorization Endpoint to return an HTML page with the code, inst= ead of a redirect.=A0At first sight, it seems a good idea, however it isn&#= 39;t in the OAuth 2 RFC.=A0
=A0 a) What is the reason for the absence in the spec?=A0
= =A0 b) Is there any security problem associated with this usage?
=
2) Alternative "redirect_uri" schemes
I'm also considering the use of alternative schemes on the "r= edirect_uri". For instance, a client app could use the "mailto:&q= uot; scheme to instruct the Authorization Endpoint to send the code via ema= il. I know that a naive implementation can be subject to fixation attacks, = however
=A0 a) Weren't=A0these scenarios considered by the working group?= =A0
=A0 b) Is there a major security flaw on this usage?